2018-12-01 01:10:09 <clandmeter> heh
2018-12-01 01:10:47 <clandmeter> so go finally got a build in dep manager
2018-12-01 01:49:56 <clandmeter> SpaceToast, did you have a working apkbuild for hugo?
2018-12-01 01:51:34 <SpaceToast> clandmeter: yes, over at https://github.com/5paceToast/aports/blob/master/toast/hugo/APKBUILD
2018-12-01 01:51:52 <SpaceToast> not everything in that repo (that included) is ready for a submission as a patch though, but feel free to grab it and fix it up further if you'd like :)
2018-12-01 01:52:09 <SpaceToast> (that applies to anything there, mind you)
2018-12-01 18:40:54 <danieli> it's been quiet here today
2018-12-01 18:56:02 <_ikke_> yes
2018-12-01 19:25:44 <bleb> a sound of sheer silence
2018-12-01 19:28:27 <_ikke_> Heh, just listening to the sound of silence :D
2018-12-01 19:41:33 <bleb> u ever watch that old black and white clip of them playing it live
2018-12-01 19:41:39 <bleb> that ones good
2018-12-01 19:41:46 <_ikke_> Hmm, no
2018-12-01 19:42:51 <_ikke_> This one? https://youtu.be/QoOM_p3UE-A
2018-12-01 19:47:42 <bleb> yeah thats it
2018-12-01 19:52:17 <bleb> this one of for emily is also amazing https://www.youtube.com/watch?v=Li0-PXsrRHs
2018-12-01 19:59:16 <_ikke_> Sound quality could be better though :)
2018-12-01 20:14:28 <bleb> yeah
2018-12-02 17:28:47 <SpaceToast> Just noticed https://alpinelinux.org/about/ still says we have an unofficial grsec/pax port. Might make sense to update it?
2018-12-02 17:29:00 <_ikke_> nod
2018-12-02 19:41:37 <clandmeter> SpaceToast, pushed fix
2018-12-02 19:42:44 <clandmeter> thx for the reminder :)
2018-12-02 19:42:47 <_ikke_> clandmeter: nice
2018-12-03 11:59:50 <ncopa> i wonder if boot.alpinelinux.org is broke?
2018-12-03 11:59:53 <ncopa> ncopa-desktop:~$ qemu-system-x86_64 --enable-kvm -m 1024 -cdrom https://boot.alpinelinux.org/alpine-ipxe/x86_64/ipxe.iso
2018-12-03 11:59:53 <ncopa> qemu-system-x86_64: -cdrom https://boot.alpinelinux.org/alpine-ipxe/x86_64/ipxe.iso: CURL: Error opening file: Server does not support 'range' (byte ranges).
2018-12-03 12:01:26 <ncopa> maybe its qemu thats broken
2018-12-03 12:01:33 <danieli> might be, have you ran that command before, and it worked?
2018-12-03 12:02:05 <clandmeter> ncopa, i moved the container, maybe i broke something.
2018-12-03 12:02:16 <jwh> looks ok from here
2018-12-03 12:02:29 <danieli> jwh: did you actually test with the range header?
2018-12-03 12:02:38 <jwh> [jwh@pyxis ~]$ curl -s --head -C10 https://boot.alpinelinux.org/alpine-ipxe/x86_64/ipxe.iso | grep range
2018-12-03 12:02:41 <jwh> accept-ranges: bytes
2018-12-03 12:02:41 <jwh> content-range: bytes 10-1048575/1048576
2018-12-03 12:03:04 <danieli> -r 0-500 works for me
2018-12-03 12:03:08 <clandmeter> he is probably using a different httpd :)
2018-12-03 12:03:09 <danieli> must be broken qemu
2018-12-03 12:04:23 <clandmeter> ncopa, what does boot.a.o resolve to?
2018-12-03 12:05:47 <jwh> nld3 here, fwiw
2018-12-03 12:05:50 <danieli> same
2018-12-03 12:06:22 <clandmeter> he is probably using an infra container
2018-12-03 12:06:24 <clandmeter> it uses local dns
2018-12-03 12:07:22 <jwh> ah
2018-12-03 12:07:36 <clandmeter> ncopa, i updated unbound
2018-12-03 12:07:50 <clandmeter> should now resolve to the proxy instead of the container directly.
2018-12-03 13:25:55 <ncopa> no, i think its qemu or curl that is broken
2018-12-03 13:28:12 <mps> what is your qemu version?
2018-12-03 13:28:24 <mps> I've got 'qemu-system-x86_64: -cdrom https://boot.alpinelinux.org/alpine-ipxe/x86_64/ipxe.iso: Unknown protocol 'https''
2018-12-03 13:28:46 <mps> QEMU emulator version 2.12.0
2018-12-03 13:28:56 <ncopa> qemu-2.12.1-r2
2018-12-03 13:29:11 <mps> aha, from edge
2018-12-03 13:30:11 <ncopa> boots with http instead of https
2018-12-03 13:32:59 <mps> could be gnutls problem, but I'm not sure i.e. didn't test that
2018-12-03 13:38:32 <clandmeter> ncopa, you are not using it on your infra container?
2018-12-03 13:38:33 <mps> btw, qemu upstream stable is 3.0 while AL in edge is 2.12
2018-12-03 13:40:08 <clandmeter> mps, its not ;-)
2018-12-03 13:40:23 <clandmeter> http://dup.pw/aports/d5172d82
2018-12-03 13:42:21 <mps> heh, need to 'git pull' local aports
2018-12-03 13:43:51 <mps> maybe put cron job to pull it wvery few hours :)
2018-12-03 13:44:26 <clandmeter> you can also listen on mqtt and pull when needed.
2018-12-03 13:44:48 <clandmeter> apk add mqtt-exec
2018-12-03 13:45:00 <danieli> i just git pull whenever i'm working with it
2018-12-03 13:45:44 <clandmeter> automatic pulling a work repo is maybe a bad idea when you have local changes.
2018-12-03 13:46:39 <_ikke_> i'm with danieli
2018-12-03 13:47:21 <mps> you noticed ':)' at the end of my post ;)
2018-12-03 13:48:39 <mps> looked at mqtt-exec but didn't tried, yet
2018-12-03 16:59:00 <SpaceToast> ncopa: sure
2018-12-03 16:59:20 <SpaceToast> tl;dr http://lists.gnu.org/archive/html/bug-grub/2018-11/msg00015.html - 10_linux has a hardcoded list of "acceptable initramfs filenames"
2018-12-03 16:59:33 <SpaceToast> mkinitfs generates initramfs-${version}, which is not in the hardcoded list
2018-12-03 17:00:21 <SpaceToast> this causes some funny issues (e.g with btrfs multidevice) where you end up with a \n in root=
2018-12-03 17:00:30 <SpaceToast> but in general, we probably want our initrd to be detected "normally"
2018-12-03 17:00:54 <SpaceToast> the fix is relatively simple, just add "initramfs-${version}" and "initramfs-${alt_version}" to that list
2018-12-03 17:01:14 <ncopa> i think we can carry patch for that in our grub package
2018-12-03 17:01:18 <SpaceToast> (it also demands udev be present to use UUIDs, which (from what I know isn't required), but that should be separate)
2018-12-03 17:01:30 <SpaceToast> okay, I'll re-poke here if/when it gets patched upstream :)
2018-12-03 20:41:17 <clandmeter> hmm, we don't have a py3 mysql driver in aports?
2018-12-03 22:09:48 <nmeum> clandmeter: just a heads up: the common name of the tpaste.us TLS certificate is wrong
2018-12-03 22:19:28 <_ikke_> nmeum: right, it just uses a common certificate. Need to create a specific one
2018-12-03 22:42:26 <geosmin> trying to get alpine working on two new rpi3 A+ boards. currently doesn't boot, assume it'll need extra firmware or even a newer kernel
2018-12-03 22:43:30 <geosmin> done for the day and will be starting in about ~15 hours, but any pointers between now and then appreciated
2018-12-04 07:24:05 <danieli> morning ncopa
2018-12-04 07:29:38 <danieli> anyone figure out aarch64 gdb yet?
2018-12-04 07:29:54 <danieli> linux-headers / musl-dev header conflict
2018-12-04 08:35:50 <ncopa> morning
2018-12-04 08:36:00 <ncopa> danieli: yes its a problem in linux-headers
2018-12-04 08:36:20 <ncopa> nsz in #musl said he knew someone that had a patch for it
2018-12-04 08:36:44 <danieli> for gdb?
2018-12-04 08:36:51 <danieli> i fixed it in another package, but i practically monkey patched it
2018-12-04 08:37:56 <ncopa> yes, it should solve gdb
2018-12-04 08:38:20 <danieli> lemme test, 1 sec
2018-12-04 09:24:55 <AinNero> ncopa: could you make a new mkinitfs release, so the changes i did break in edge and not in 3.9.0 ?
2018-12-04 09:39:47 <ncopa> AinNero: yeah. should do that before 3.9.0_rc1
2018-12-04 10:14:13 <TBB> speaking of mkinitfs
2018-12-04 10:15:17 <TBB> noticed the other day that specifying -i on the command line is overridden by init= in the .conf. should this work this way or should the commandline override the config?
2018-12-04 10:44:44 <ncopa> I guess we want the command line override the config
2018-12-04 11:21:36 <AinNero> who is work on it?
2018-12-04 11:21:40 <AinNero> s/is/will/
2018-12-04 11:24:06 <ncopa> patches are welcome. im not going to work on that anytime soon
2018-12-04 12:13:15 <danieli> ncopa: hm, how come gdb fails on aarch64 but not any other arch?
2018-12-04 12:13:17 <danieli> seems a bit odd
2018-12-04 14:22:03 <AinNero> TBB: if you do not intend to work on the mkinitfs issue, could you create a ticket and assign it to me?
2018-12-04 14:39:30 <ncopa> danieli: because the linux headers are arch specific
2018-12-04 14:39:36 <danieli> aha
2018-12-04 14:40:23 <danieli> seems odd for sigcontext to be different though?
2018-12-04 14:50:57 <TBB> AinNero: I'll see what I can do; I'll most probably assign a ticket to you since I'm awkward with the Alpine contribution process
2018-12-04 15:20:21 <AinNero> same actually, my position is only special because i have a huge kink for initramfs and early userspace in general
2018-12-04 15:21:02 <TBB> I've had similar urges recently; I'd like to at some point modularize how initramfs-init is constructed
2018-12-04 15:27:31 <AinNero> i had two approaches for that in mind, but since both of them increase complexity, i try to stay off it as long as possible
2018-12-04 15:28:32 <AinNero> maybe someone could provide a docker image or so to automatically build custom initramfs, so its easier for people to build it themselves
2018-12-04 15:28:46 <AinNero> instead of trying to get it merged into our own build processes
2018-12-04 15:30:36 <TBB> yeah; I've been doing stuff with lxd for a while now so I could have a look
2018-12-04 15:39:37 <SpaceToast> lxd is quite nice :)
2018-12-04 15:40:08 <SpaceToast> my main issue with mkinitfs is nlplug-findfs and order of operations that make some things complicated, but now that I'm busy writing docs it might be a very long time before I can poke around
2018-12-04 15:43:15 <TBB> I'll have to read ncopa's comments about nlplug-findfs from the scrollback at some point to get a better idea of it
2018-12-04 15:43:51 <SpaceToast> TBB: my understanding is that it registers itself as the hotplug manager with the kernel, enforces sequencing, and coldplugs using mdev
2018-12-04 15:44:04 <SpaceToast> (and then, still inside of it, tries to mount what it coldplugged, and looks for apkovl)
2018-12-04 15:44:29 <SpaceToast> issues arise when, for example, you have btrfs multidevice, which requires a scan between coldplugging and mounting; as well as any other such "special case"
2018-12-04 15:46:38 <AinNero> im not satisfied with the lot of 'magic' that nlplug-findfs contains, but at least it has some sort of manpage now
2018-12-04 15:47:29 <SpaceToast> yeah, that's another part of why I dislike it
2018-12-04 15:47:43 <SpaceToast> I suspect it would be possible to have a shell-based "hook" system for use with mdev, which now supports sequencing
2018-12-04 15:48:02 <SpaceToast> I was told it'd be really hard to set up, but as it turns out that's just because most of my development time is used on something else now :)
2018-12-04 20:55:20 <HRio> can somebody with commit rights to main look at this https://github.com/alpinelinux/aports/pull/5591 ?
2018-12-05 05:06:59 <danieli> HRio: try during daytime in europe, you'll probably have better luck then
2018-12-05 05:07:17 <danieli> also, lots of "ping" / "bump" in the issue comments isn't really productive
2018-12-05 05:33:15 <_ikke_> danieli: sadly it's sometimes necessary
2018-12-05 05:33:36 <danieli> heh.
2018-12-05 08:59:42 <ncopa> i think it would be nice if someone could help me look over the PRs and mark which one should be prioritized for v3.9
2018-12-05 09:15:46 <AinNero> ncopa: "mark" as in, approve it?
2018-12-05 09:16:06 <danieli> I'm guessing to label them
2018-12-05 09:17:49 <ncopa> yeah, we should probably label them with v3.9 or similar
2018-12-05 09:34:57 <mps> ncopa: do you have url for these PRs? will look but I'm not promising anything
2018-12-05 09:36:10 <mps> although noticed on $alpine-commits some which repeatedly fails to build
2018-12-05 09:36:31 <mps> s/$/#/
2018-12-05 09:42:13 <tboerger[m]> i would like to fix the apache2 package, but i'm not sure how to handle that... https://pkgs.alpinelinux.org/contents?file=top.html&path=&name=&branch=edge this directory should be part of apache2-error like https://pkgs.alpinelinux.org/contents?file=HTTP_BAD_GATEWAY.html.var&path=&name=&branch=edge instead of part of apache2-dev, otherwise the default apache error pages are broken if the apache2-dev package is not
2018-12-05 09:42:13 <tboerger[m]> installed.
2018-12-05 09:42:29 <mps> never mind, found PRs on github
2018-12-05 10:04:40 <user234342> hello, what are your mail server recommendations? thanks
2018-12-05 10:05:57 <milliardo> opensmtpd
2018-12-05 10:06:45 <user234342> milliardo: ok, what about imap?
2018-12-05 10:07:03 <milliardo> I don't use it.
2018-12-05 10:07:18 <user234342> milliardo: how to retrieve mail then? what do you use?
2018-12-05 10:07:30 <milliardo> ssh
2018-12-05 10:07:58 <user234342> okay, we have other requirements here, thanks for your answers
2018-12-05 10:09:44 <milliardo> that doesn't means you can't use imap. You just asked me what I use. Also it would be more effective to ask all your questions in the same line, which would have saved you from receiving my answer
2018-12-05 10:10:28 <danieli> #alpine-linux perhaps?
2018-12-05 10:10:33 <milliardo> finally, I don't see how this is related to alpine development. Maybe you should make such questions in #alpine-linjx instead
2018-12-05 10:10:34 <clandmeter> Please move this conversation
2018-12-05 10:10:39 <clandmeter> what danieli said :)
2018-12-05 10:12:36 <user234342> sorry
2018-12-05 11:03:06 <tboerger[m]> clandmeter: can you tell me how to fix the apache package? :P /usr/share/apache2/error/include/* should be part of apache2-error, not part of apache2-dev
2018-12-05 11:03:46 <clandmeter> tboerger[m], hi
2018-12-05 11:04:36 <tboerger[m]> lo :)
2018-12-05 11:04:51 <clandmeter> you can override the dev function if you dont agree with it.
2018-12-05 11:05:26 <clandmeter> you could do default_dev and then move it back to $pkgdir
2018-12-05 11:06:59 <tboerger[m]> https://git.alpinelinux.org/cgit/aports/tree/main/apache2/APKBUILD#n200 i can't even see where the include dir gets moved into the dev package. maybe some kind of default rule that adds include directories into dev packages?
2018-12-05 11:07:34 <clandmeter> you can grep aports for "^dev() {"
2018-12-05 11:08:04 <clandmeter> tboerger[m], abuild has a default_dev function defined.
2018-12-05 11:08:22 <tboerger[m]> ok, thanks... will try to find more out on that way.
2018-12-05 11:08:24 <clandmeter> it does some logic we thing is logical. but it doesnt always do whats needed.
2018-12-05 11:08:44 <clandmeter> it gets called by the dev function
2018-12-05 11:09:13 <clandmeter> do if you define it in your apkbuild it will not run the global dev function but yours, that way you can override it and append  your own magic.
2018-12-05 11:09:22 <clandmeter> *so
2018-12-05 11:11:27 <tboerger[m]> ok cool
2018-12-05 14:07:43 <andypost> ncopa, about 3.9 would be great to accept https://github.com/alpinelinux/aports/pull/5569
2018-12-05 14:29:59 <ncopa> ok
2018-12-05 14:30:28 <ncopa> i wonder what we do with edge users?
2018-12-05 14:30:35 <ncopa> when they start complain
2018-12-05 14:31:55 <danieli> ncopa: edge users? complain about PHP 5?
2018-12-05 14:32:01 <SpaceToast> I don't know about edge users in general, but being one (and being in favor of rolling releases in general) the expectation is usually to have the latest version of everything
2018-12-05 14:32:07 <danieli> ^^^
2018-12-05 14:32:17 <SpaceToast> things that are EOL are unlikely to be complained about by this demographic, at least unless I'm wrong
2018-12-05 14:32:33 <danieli> security support for 5.6 is over the 31st
2018-12-05 14:32:55 <danieli> if people are ridiculous enough to depend on php god damn 5.x, edge really isn't the best choice
2018-12-05 14:33:04 <danieli> you might as well go for RHEL or ancient debian
2018-12-05 14:33:47 <SpaceToast> at $dayjob we still have one project that hasn't been moved (the usual "write something no one else can understand to avoid being fired, but then leave" situation)
2018-12-05 14:34:00 <SpaceToast> that project is isolated to an alpine release specifically because of that
2018-12-05 14:34:53 <danieli> a rolling release (distro|branch) doesn't sound like a good choice for legacy software like that
2018-12-05 14:35:32 <SpaceToast> yeah precisely
2018-12-05 14:37:04 <danieli> ncopa: reminds me, you should upgrade jenkins in 3.8 to 2.121.3 (from .1)
2018-12-05 14:37:08 <danieli> https://jenkins.io/security/advisory/2018-12-05/
2018-12-05 14:37:23 <danieli> (...) As these naming conventions closely match common code patterns in Java, accessing crafted URLs could invoke methods never intended to be invoked this way.
2018-12-05 14:48:19 <danieli> some new releases will be pushed pretty quickly i think
2018-12-05 14:59:21 <geosmin> alright, make some progress getting the A+ to boot
2018-12-05 15:00:07 <geosmin> updated bootcode.bin which get us a bit further. bootloader's UART reports it gets as far as on previous boards
2018-12-05 15:00:24 <geosmin> however i can't seem to get any UART output past the bootloader
2018-12-05 15:00:55 <geosmin> verified console serial output is set up correctly as the same sd card is working fine on the B+ board
2018-12-05 15:33:23 <geosmin> made a bit more progress: http://ix.io/1viH
2018-12-05 19:35:32 <danieli> why is `sane` only built for x86 and x86_64? the APKBUILD says nothing about it?
2018-12-05 19:35:58 <danieli> also, why does its $license not make sense at all? someone half-assed SPDX
2018-12-05 19:41:39 <clandmeter> Because licensing has only recently been taken seriously
2018-12-05 19:42:07 <clandmeter> With help of spdx
2018-12-05 20:41:53 <SpaceToast> danieli: sure, I was done though :)
2018-12-05 20:45:13 <danieli> http over tls (https) could be an extra layer of security, and would have prevented issues like that apk vuln that got released a short while ago, where apk simply misbehaves
2018-12-05 20:45:35 <SpaceToast> yes, iirc that was mostly affecting docker
2018-12-05 20:47:11 <danieli> considering a lot of third party mirrors are beyond our control, it may give some people a false sense of security (plus the whole 'padlock means secure and safe!'), and consistency
2018-12-05 20:50:02 <SpaceToast> third-party mirrors that are beyond our control are exactly that - beyond our control; we cannot control whether or not they put the padlock on or not
2018-12-05 20:50:11 <SpaceToast> what we do have control over is our own mirrors
2018-12-05 20:50:29 <SpaceToast> and purposefully avoiding putting encryption on them because bad people might do so as well seems silly to me
2018-12-05 20:50:34 <danieli> that argument is more or less just consistency and the false sense of security it can give naive people
2018-12-05 20:51:30 <SpaceToast> further, let's consider the same type of naive person - who might see the official repositories not have the padlock, and some third-party repository having one, and thus choosing the third-party repository, even if it might not actually be safe
2018-12-05 20:51:50 <SpaceToast> basically, I don't see how purposefully *not* making *our* repos as good as possible actually helps, in this scenario
2018-12-05 20:51:50 <danieli> signatures :)
2018-12-05 20:52:11 <SpaceToast> sure, but what do signatures have to do with the argument being applied?
2018-12-05 20:52:22 <SpaceToast> those will exist whether or not we have tls
2018-12-05 20:52:32 <danieli> mirrors aren't insecure, either they are or aren't
2018-12-05 20:52:50 <SpaceToast> yes, which makes the whole "false sense of security" argument all the more silly, imo
2018-12-05 20:52:50 <danieli> if you consciously install someone else's public key into your /etc/apk/keys, that's on you
2018-12-05 20:52:57 <SpaceToast> most people don't look at their mirror list to begin with
2018-12-05 20:53:00 <danieli> it's more about https in general
2018-12-05 20:53:29 <SpaceToast> the argument is still "we shouldn't use encryption, because people might realize that we use encryption and think that that is better than not using encryption"
2018-12-05 20:54:12 <SpaceToast> alternative, if the inconsistency you introduce is that we have less desireable things - is that good?
2018-12-05 20:54:27 <danieli> we shouldn't make it a blocking priority issue because some people falsely believe https is more secure than http because of a green padlock
2018-12-05 20:54:38 <SpaceToast> I never said it's a blocking priority issue
2018-12-05 20:54:45 <SpaceToast> I said it's something that would be desireable to have
2018-12-05 20:54:52 <SpaceToast> very different, statement, isn't it?
2018-12-05 20:55:09 <danieli> I'm elaborating on the argument, a detail I missed
2018-12-05 20:56:11 <SpaceToast> if the cost is "people might think they're safer when they use our mirrors", I really don't see that as much of a downside
2018-12-05 20:56:25 <GrantM11235> Wouldn't https make it harder to use something like squid for caching?
2018-12-05 20:56:42 <GrantM11235> (I'm not sure if anyone does that though)
2018-12-05 20:56:59 <danieli> fastly does cache, iirc the origin server for fastly is dl-5 or dl-4
2018-12-05 20:57:02 <danieli> and some mirrors cache
2018-12-05 20:57:09 <SpaceToast> GrantM11235: I don't think anyone does that, and squid has a mode for https proxying
2018-12-05 20:57:45 <danieli> anyway, for caching, it'd have to terminate ssl and re-encrypt towards the origin server
2018-12-05 20:57:58 <danieli> you could use a CONNECT tunnel but squid won't touch the contents
2018-12-05 21:03:32 <GrantM11235> https://whydoesaptnotusehttps.com/
2018-12-05 21:04:04 <danieli> good one!
2018-12-05 21:04:29 <SpaceToast> GrantM11235: the "Why not provide HTTPS anyway?" section (which is the important one in this case) is simply outdated
2018-12-05 21:04:43 <SpaceToast> "providing a huge worldwide mirror network available over SSL is not only a complicated engineering task" - it no longer is
2018-12-05 21:05:02 <SpaceToast> further, I don't believe we control a "huge worldwide mirror network" (I may be wrong in that regard, of course)
2018-12-05 21:05:19 <danieli> we have a large amount of worldwide mirrors, but we don't control them
2018-12-05 21:05:38 <SpaceToast> and since we don't control them, we cannot control whether they use tls, and thus shouldn't worry about them ;)
2018-12-05 21:05:43 <SpaceToast> as such, the "why not provide https anyway?" answer becomes "it implies a misleading level of security and privacy to end-users"
2018-12-05 21:05:47 <danieli> *optional* https would be nice for alpine mirrors
2018-12-05 21:05:55 <SpaceToast> to which I say... so what if users feel safe when using your (controlled) mirror?
2018-12-05 21:06:16 <SpaceToast> this is under the assumption that such users even look at mirrors in detail to begin with
2018-12-05 21:09:21 <SpaceToast> and I don't mind it being optional, sure :)
2018-12-05 21:10:02 <SpaceToast> I'm personally of the opinion that, ideally, *all* http connections should be encrypted, and I am also not a fan of the X.509 infrastructure system (the CA part in particular), but that's not really relevant to making TLS available (and, ideally default)
2018-12-05 21:10:51 <danieli> the point is that it's a lot of extra work for little to no gain, especially with a large amount of mirrors
2018-12-05 21:11:08 <SpaceToast> I don't see it as much extra work, at least with LE-equipped systems
2018-12-05 21:11:23 <SpaceToast> (in fact, my webserver of choice (caddy) defaults to having https enabled, and can synchronize accross clusters)
2018-12-05 21:11:42 <SpaceToast> so my PoV is more that it has a very low cost, and no real disadvantages
2018-12-05 21:12:13 <danieli> we don't run caddy, and consistently deploying / maintaining LE (for little or no gain) is extra work
2018-12-05 21:13:05 <SpaceToast> with a sufficiently large amount of mirrors, there likely is (or at least should be) automation in place
2018-12-05 21:13:15 <SpaceToast> in which case the cost is one-time, to set up said extra automation bit
2018-12-05 21:13:30 <SpaceToast> with a lower amount of mirrors (where it's all done by hand), the cost is similarly lower
2018-12-05 21:13:39 <danieli> we're working on the automation part, most is manual now
2018-12-05 21:13:43 <SpaceToast> but my point isn't "everyone start running and deploying TLS!"
2018-12-05 21:13:57 <SpaceToast> my point is "it is good to have it be available, if that is feasible"
2018-12-05 21:14:09 <SpaceToast> (and it's feasible most of the time, so the above boils down to "it is good to have it be available")
2018-12-06 21:41:59 <geosmin> ncopa: that bug was assigned to you /very/ fast, i'm hoping that wasn't done by me during submission accidentally
2018-12-07 01:14:37 <SpaceToast> clandmeter: should I send in that patch to abuild from the other day to the alpine-devel ML? (the one for clean() fix + default_cleanup_srcdir, though I'll need to touch it up a bit (I was in a hurry when I originally wrote it))
2018-12-07 01:14:42 <SpaceToast> (or did we come up with a different solution)
2018-12-07 06:11:13 <ncopa> geosmin: i think that issue category is automatically assigned to me, so its ok
2018-12-07 07:27:35 <clandmeter> SpaceToast, i talked to ncopa, i think he wanted a different approach.
2018-12-07 07:31:36 <clandmeter> he was thinking about having a $workdir and redirect $HOME  to it.  And adding some special option like chmod-clean to fix go modules.
2018-12-07 08:00:44 <ncopa> i think you should post it on alpine-devel and we can discuss it there
2018-12-07 08:31:04 <ncopa> i need to go out for a few hours
2018-12-07 08:31:20 <ncopa> would be good if we could try fix the v3.9 builds
2018-12-07 09:03:00 <danieli> ncopa: got a list of them?
2018-12-07 09:03:10 <danieli> ugh, nevermind, I don't even have a 3.9 system to test on
2018-12-07 09:12:17 <clandmeter> danieli, 3.9 is same as edge
2018-12-07 09:12:22 <danieli> fair enough
2018-12-07 09:12:24 <danieli> thanks clandmeter
2018-12-07 09:12:32 <danieli> got a list of broken stuff?
2018-12-07 09:12:55 <danieli> I'll have a look at elixir for sure, and I'll have another look at mercury and swi-prolog (two packages I'm working on)
2018-12-07 09:13:02 <clandmeter> i cannot access the x86 builders
2018-12-07 09:13:36 <clandmeter> _ikke_, could maybe provide those.
2018-12-07 09:14:13 <clandmeter> i can give you the list of armv7, but thats probably a mix of different cases.
2018-12-07 09:14:43 <danieli> indeed, there are some arm-only edge cases in there too
2018-12-07 09:14:57 <clandmeter> and you dont have an arm builder :)
2018-12-07 09:15:01 <clandmeter> but that can be fixed
2018-12-07 09:15:11 <danieli> I only have x86_64
2018-12-07 09:15:30 <clandmeter> we can set one up. but not right now.
2018-12-07 09:19:44 <mps> clandmeter: I noticed one or two failed builds on armv7 for which I have fix
2018-12-07 09:20:19 <mps> to post these fixes to alpine-devel
2018-12-07 09:20:22 <mps> ?
2018-12-07 09:23:22 <clandmeter> mps, you can also send them to alpine-aports
2018-12-07 09:23:34 <clandmeter> if they are aports diffs
2018-12-07 09:24:04 <clandmeter> or just tpaste them here
2018-12-07 09:24:10 <clandmeter> whatever you prefer
2018-12-07 09:26:03 <_ikke_> danieli: http://tpaste.us/ba4e
2018-12-07 09:26:19 <danieli> _ikke_: .. context?
2018-12-07 09:26:21 <mps> it would be easier to paste it somewhere and post url here. I'll 'page' you when I come to work place where I can look fixes
2018-12-07 09:26:44 <_ikke_> list of x86 builders
2018-12-07 09:27:03 <danieli> but why are you passing it to me?
2018-12-07 09:27:36 <_ikke_> Not sure, thought it was a request from you
2018-12-07 09:27:39 <_ikke_> (through clandmeter)
2018-12-07 09:27:46 <danieli> I'm really confused
2018-12-07 09:30:20 <_ikke_> ok, feel free to ignore then
2018-12-07 09:31:52 <clandmeter> haha
2018-12-07 09:32:06 <clandmeter> _ikke_, i was meaning build errors of v3.9
2018-12-07 09:32:12 <_ikke_> ah, sorry :-/
2018-12-07 09:32:16 <clandmeter> np
2018-12-07 09:33:09 <clandmeter> _ikke_, in the aports dir of v3.9 please ls the src dirs
2018-12-07 09:33:25 <clandmeter> if build fails it should keep the src dir available.
2018-12-07 09:33:55 <_ikke_> ok
2018-12-07 09:35:02 <_ikke_> for elixir or swi-prolog?
2018-12-07 09:35:23 <danieli> _ikke_: swi-prolog and mercury aren't in alpine
2018-12-07 09:35:28 <danieli> elixir is, and it's an *example* of a broken package
2018-12-07 09:37:11 <_ikke_> ok
2018-12-07 09:57:48 <mps> clandmeter: for community/monkey changes are: remove jemalloc-dev from makedepends and add '--malloc-libc' to build()
2018-12-07 09:58:36 <_ikke_> clandmeter: there is no src directory in the elixir aports dir
2018-12-07 09:59:16 <mps> anyway, I will try to setup git-sendmail to armv7 dev machine to send fixes to aports@a.o from it
2018-12-07 10:04:13 <danieli> aports@lists.a.o actually
2018-12-07 10:04:25 <danieli> er
2018-12-07 10:04:29 <danieli> alpine-aports@lists.a.o
2018-12-07 10:06:59 <mps> danieli: ok, have it written somewhere but not in head
2018-12-07 10:12:15 <mps> clandmeter: just 'git pull'-ed  aports and look like community/monkey is already fixed, there is no jemalloc-dev in makedepends
2018-12-07 10:13:47 <mps> now remember that we talked here about removing jemalloc from some packages
2018-12-07 10:13:53 <mps> sory for noise
2018-12-07 14:28:01 <geosmin> ncopa: hi, unless i'm mistaken i think localhost needs to be in quotes in your fix, else it'll try to call a second variable that won't exist
2018-12-07 14:35:28 <geosmin> ncopa: scratch that it works just fine :)
2018-12-07 14:41:54 <ncopa> geosmin: good! thank you for a good bug report
2018-12-07 15:23:45 <andypost> ncopa, yesterday php has 4 security releases but CVEs not filed yet, I prepared PRs
2018-12-07 15:24:11 <andypost> how to schedule backports?
2018-12-07 15:24:38 <andypost> another problem is https://github.com/alpinelinux/aports/pull/4843
2018-12-07 15:24:51 <andypost> on 3.7 we have tests enabled and they fail
2018-12-07 15:26:27 <andypost> should I disable them? because different tests fail on differenrent arches
2018-12-07 15:37:54 <ncopa> hum... i think the intl and time related testa can be disabled
2018-12-07 15:38:02 <ncopa> they likely has some GNU specific test
2018-12-07 15:38:14 <ncopa> would be good to confirm though
2018-12-07 15:38:22 <ncopa> the otherone is more worrisome
2018-12-07 15:38:34 <ncopa> posix_getpwuid
2018-12-07 15:38:48 <ncopa> i dont see any reason to why that would fail
2018-12-07 15:39:17 <ncopa> andypost: in general, it would be good to investigate why the tests fail
2018-12-07 15:41:28 <mps> intel-ucode fails to build on aarch64, is it needed for that arch
2018-12-07 15:46:49 <andypost> ncopa, intl & time yes, they always flux, the rest will dig
2018-12-07 15:49:12 <ncopa> thanks
2018-12-07 15:49:38 <ncopa> mps: really?
2018-12-07 15:49:42 <ncopa> ok, I'll enable it
2018-12-07 15:49:54 <ncopa> i thought intel-ucode was an intel only thing
2018-12-07 15:50:55 <mps> I think so, imo it should be disabled for aarch64
2018-12-07 15:52:32 <ncopa> mps: sorry, i read your wrong. i read "it is needed forthat arch"
2018-12-07 15:52:44 <ncopa> i have already disabled it
2018-12-07 15:53:35 <mps> ok, maybe I wasn't clear enough, language barrier
2018-12-07 16:05:07 <ncopa> andypost: re https://github.com/alpinelinux/aports/pull/4843 if you really want support that old alpine releases, then I think we should move php to main
2018-12-07 16:05:49 <ncopa> we only provide security fixes for community for latest stable (currently v3.8)
2018-12-07 16:06:43 <andypost> ah... then it much easy!
2018-12-07 16:08:39 <andypost> it means only 3.5 needs update & 5770 + 5771 PRs)
2018-12-07 16:09:39 <andypost> so I will rework https://github.com/alpinelinux/aports/pull/5487
2018-12-07 16:11:40 <mps> how long it takes for patch posted to alpine-aports to appear on patchwork.a.o
2018-12-07 16:12:06 <ncopa> andypost: i can push https://github.com/alpinelinux/aports/pull/4843 since you done the work already
2018-12-07 16:12:41 <ncopa> sorry
2018-12-07 16:12:45 <ncopa> i meant the one for v3.5
2018-12-07 16:13:06 <andypost> ncopa, let me update it to latest release
2018-12-07 16:13:13 <ncopa> this one: https://github.com/alpinelinux/aports/pull/5163
2018-12-07 16:13:31 <ncopa> im ready to push PR 5163
2018-12-07 16:13:44 <andypost> yep, this fine
2018-12-07 16:13:55 <ncopa> done
2018-12-07 16:13:56 <andypost> 3.5 nbackport I will prepare soon
2018-12-07 16:24:43 <andypost> ncopa, merge error in https://github.com/alpinelinux/aports/commit/d7284ad8b85e17a80a84f29d6c297c71391c4dd4
2018-12-07 16:24:57 <ncopa> ugh...
2018-12-07 16:25:02 <ncopa> i need a weekend...
2018-12-07 16:25:15 <andypost> also https://github.com/alpinelinux/aports/pull/5770 this need to be ported to 3.8 as well
2018-12-07 16:26:57 <ncopa> it says in comment that https://github.com/alpinelinux/aports/pull/5487 is the backport?
2018-12-07 16:27:00 <andypost> 5.6.38 => 5.6.39
2018-12-07 16:27:05 <ncopa> which I merged
2018-12-07 16:27:17 <ncopa> oh, ok
2018-12-07 16:27:25 <andypost> you pushed faster then I rebased changes)
2018-12-07 16:27:57 <andypost> lucky is that it was last php5 and 7.0 upgrades!
2018-12-07 16:29:04 <ncopa> im working on php5-5.6.39 for v3.8
2018-12-07 16:29:15 <ncopa> will just run a test build and then I'll push
2018-12-07 16:31:18 <andypost> on my side trying to get how to emable testing
2018-12-07 16:31:46 <andypost> it runs too long so we disbled it for travis
2018-12-07 16:32:39 <andypost> but posix_getpwuid is really strange failure
2018-12-07 16:33:48 <ncopa> which branch was it that got the test failure?
2018-12-07 16:34:41 <andypost> 3.7
2018-12-07 16:44:09 <ncopa> problem does not appear on edge?
2018-12-07 16:45:10 <andypost> yep, because we disabled a lot of tests to allow fit then in travis run
2018-12-07 16:46:14 <andypost> in 3.6 & 3.7 we used mostly whole test suite
2018-12-07 16:46:31 <ncopa> SKIP_SLOW_TESTS=1 SKIP_ONLINE_TESTS=1
2018-12-07 16:47:09 <ncopa> i think its reasonablei think those are reasonable
2018-12-07 16:49:42 <andypost> yes, online ones fails randomly
2018-12-07 16:52:06 <ncopa> i also think it would be a good idea if developer/maintainer runs full test locally, and we only run quick tests on the builders
2018-12-07 16:52:25 <ncopa> maybe travis also should run full tests
2018-12-07 16:52:36 <danieli> i'm not sure that's such a good idea ncopa
2018-12-07 16:52:38 <andypost> that's what I planned for this weekend) cos https://github.com/alpinelinux/aports/blob/master/community/php7/APKBUILD#L177
2018-12-07 16:52:44 <danieli> many packages have tests that fail only on certain architectures
2018-12-07 16:53:02 <danieli> and those packages can get royally f*cked on those architectures
2018-12-07 16:53:06 <ncopa> hum
2018-12-07 16:53:12 <ncopa> right, thats a good point
2018-12-07 16:53:52 <ncopa> oh... we dont run tests at all currently for x86_64
2018-12-07 16:54:08 <ncopa> and we allow test failures on some other arches
2018-12-07 16:54:21 <danieli> but they're explicitly allowed to fail, are they not?
2018-12-07 16:54:36 <andypost> sadly yes, we allow them fail
2018-12-07 16:54:54 <ncopa> i think they were allowed to fail due to lack of resources to fix those
2018-12-07 16:55:53 <danieli> well, shit.. that's not a good sign
2018-12-07 16:56:04 <andypost> last time I run partial test suite (with exclude of disabled tests) it takes more then hour on laptop
2018-12-07 16:56:26 <danieli> if you have a list of packages, i could spend a few weeks focusing on either fixing or figuring it out
2018-12-07 16:56:43 <ncopa> grep FIXME ....
2018-12-07 16:57:08 <andypost> 125
2018-12-07 16:57:14 <danieli> andypost: that's not as bad as I expected
2018-12-07 16:57:27 <danieli> thing is, I won't be able to do anything about anything else than x86_^4
2018-12-07 16:57:34 <danieli> s/^4/64/
2018-12-07 16:57:45 <ncopa> oh there is grep XXX too
2018-12-07 16:58:02 <andypost> I got scaleway arm8 so will check on it
2018-12-07 16:58:08 <danieli> FIXME, XXX, HACK, TODO, OPTIMIZE
2018-12-07 16:58:11 <danieli> common ones
2018-12-07 16:58:24 <danieli> some times also WTF
2018-12-07 16:59:04 <ncopa> we have a few TODO
2018-12-07 16:59:58 <ncopa> and yes, i think we are in a not too bad shape
2018-12-07 17:00:03 <ncopa> i think s390x is the worst
2018-12-07 17:00:16 <danieli> do we even have anyone working on s390x anymore?
2018-12-07 17:00:21 <ncopa> no
2018-12-07 17:00:26 <danieli> what do we do about it?
2018-12-07 17:00:35 <danieli> do we have access to administrate the actual VM?
2018-12-07 17:00:35 <ncopa> i havent heard from tmh1999 for ages
2018-12-07 17:00:38 <ncopa> yes
2018-12-07 17:00:39 <danieli> iirc no, because z/VM
2018-12-07 17:00:50 <ncopa> well, thats true
2018-12-07 17:00:55 <ncopa> we cannot admin the vm itself
2018-12-07 17:01:08 <andypost> I used to try chroot with s390 but it mostly not working
2018-12-07 17:01:38 <danieli> i found this, from june https://www.openmainframeproject.org/blog/i-am-a-mainframer/2018/06/28/tuan-hoang-i-am-a-mainframer
2018-12-07 17:01:49 <danieli> as far as i understand, he was in the open mainframe project internship program
2018-12-07 17:01:53 <danieli> and those usually aren't permanent
2018-12-07 17:02:09 <danieli> it's odd he went completely MIA
2018-12-07 17:02:34 <danieli> do we even have any heavy alpine s390x users?
2018-12-07 17:05:34 <ncopa> ibm wanted alpine on s390x because docker told them they needed it to run docker
2018-12-07 17:05:52 <ncopa> that was my understanding at least
2018-12-07 17:05:59 <danieli> right, yeah, alpine is the basis for moby too iirc
2018-12-07 17:06:06 <ncopa> correct
2018-12-07 17:06:07 <danieli> docker on various platforms use 'moby vm'
2018-12-07 17:06:20 <danieli> i'm just vaguely-ish familiar with it
2018-12-07 17:06:58 <ncopa> but i dont think there are any users on s390x that runs anything without commercial contract
2018-12-07 17:07:06 <danieli> well, it's IBM, that part is fairly obvious
2018-12-07 17:07:08 <danieli> either way, if IBM wants us to continue supporting s390x, shouldn't they provide some resources to help out with that? or at the very least appoint a super user and/or establish a point of contact?
2018-12-07 17:07:26 <ncopa> s390x is basically banks and insurance companies
2018-12-07 17:07:58 <danieli> yup, I've done mainframe hacking (security work)
2018-12-07 17:08:26 <ncopa> danieli: i completely agree, and I have tried tell them that
2018-12-07 17:08:36 <ncopa> i have met some of the IBM people
2018-12-07 17:08:47 <ncopa> ppc64le is a different story
2018-12-07 17:08:53 <danieli> that's unicamp, isn't it?
2018-12-07 17:09:28 <ncopa> yes, i think so
2018-12-07 17:09:33 <danieli> unicamp br, yeah
2018-12-07 17:09:33 <danieli> it is
2018-12-07 17:09:44 <danieli> is there a tangible reason why we support ppc64le?
2018-12-07 17:09:57 <ncopa> same. ibm wanted docker
2018-12-07 17:10:04 <danieli> ah, all right, same reason
2018-12-07 17:10:15 <danieli> strange they haven't been able to get musl to utilize power9 properly yet
2018-12-07 17:10:17 <ncopa> but ppc64le users are different. its more x86 like
2018-12-07 17:10:27 <danieli> yeah, s390x cpus are quite different
2018-12-07 17:10:37 <ncopa> more normal people runs ppc
2018-12-07 17:10:58 <ncopa> you buy the machine and run whatever you want on it
2018-12-07 17:11:19 <danieli> yeah, it's more commodity hardware
2018-12-07 17:11:26 <danieli> *more* commodity anyway
2018-12-07 17:11:33 <ncopa> yeah
2018-12-07 17:11:57 <danieli> we could "threaten" to drop support for s390x if they don't make it manageable and maintainable in some way, shape or form
2018-12-07 17:12:12 <danieli> but then again, you're probably the only contact point ibm has with us
2018-12-07 17:12:23 <ncopa> yes
2018-12-07 17:12:25 <danieli> you're the BDFL
2018-12-07 17:12:34 <danieli> or at least that's the implicit role
2018-12-07 18:00:55 <mps> is there problem with patchwork.alpinelinux.org? I posted fix for wirinigpi but it isn't on the list there
2018-12-07 18:02:21 <_ikke_> clandmeter: ^
2018-12-07 18:03:12 <danieli> well, you did say email on it was screwy clandmeter
2018-12-07 18:17:00 <SpaceToast> mps: I haven't received your patch on the ML
2018-12-07 18:17:12 <SpaceToast> did you maybe send it while l.a.o was down or buggy?
2018-12-07 18:17:28 <danieli> some changes were made to patchwork
2018-12-07 18:17:33 <SpaceToast> aha
2018-12-07 18:17:41 <danieli> or so i believe, anyway
2018-12-07 18:18:58 <mps> SpaceToast: I've got reply from the alpine-aports ML
2018-12-07 18:19:21 <mps> not reply actually, but resent message
2018-12-07 18:20:00 <SpaceToast> searching for "wiri" in my Alpine/Aports folder has no results
2018-12-07 18:20:05 <SpaceToast> again I'm not saying *you*'re at fault
2018-12-07 18:20:13 <SpaceToast> I'm saying that this may have happened during a period of instability
2018-12-07 18:21:12 <mps> no problem, I didn't thought that you say I'm at fault.
2018-12-07 18:23:11 <ncopa> mps: i'll commit it, but it needs to bump pkgrel i think
2018-12-07 18:23:17 <ncopa> i'll fix that
2018-12-07 18:23:48 <mps> yes, right, forgot bump
2018-12-07 18:24:17 <ncopa> i am slightly in doubt if it is strictly needed
2018-12-07 18:25:05 <ncopa> and commit message needs to be prefixed with community/wiringpi
2018-12-07 18:25:29 <mps> maybe not, because it works fine is on armhf without that fix
2018-12-07 18:25:50 <ncopa> the question is if the built binary is modified by the change or not
2018-12-07 18:26:00 <ncopa> i bumped it, just in case
2018-12-07 18:26:18 <mps> ok, tnx
2018-12-07 18:26:53 <mps> only change is added '-fpic' to make
2018-12-07 18:28:22 <mps> btw, it works with that fix about two weeks on armv7 without problem
2018-12-07 18:38:00 <kpcyrd> is there any prior work to add support for full disk encryption to the alpine installer? would alpine accept a patch to make this less painful?
2018-12-07 18:40:06 <ncopa> kpcyrd: i am not aware of any prior work for full encryption support to the alpine installer
2018-12-07 18:40:24 <danieli> if we're opinionated about FDE, we have to make sure it's technically correct and waterproof
2018-12-07 18:42:29 <ncopa> i would also want it to be implemented without any extra questions (unless you actually want encryption)
2018-12-07 18:43:22 <ncopa> so we dont want a question like: "Do you want enable encryption? (y/n) [n]"
2018-12-07 18:43:32 <kpcyrd> danieli: so that would the cipher, the hash and the number of iterations. everything else should be obvious, like changes needed for mkinitramfs
2018-12-07 18:44:22 <clandmeter> mps, if it doesn't pop up on the list then it's not pw issue
2018-12-07 18:44:24 <SpaceToast> kpcyrd: I don't think "obvious" is a term that applies to our initramfs, especially considering we support diskless installs (and thus likely need to support data-on-disk FDE)
2018-12-07 18:44:59 <ncopa> i'm ok to only support FDE for "sys" install initially
2018-12-07 18:45:10 <kpcyrd> ncopa: maybe as an additional option during the disk setup? that should be possible without breaking existing answerfiles
2018-12-07 18:45:12 <danieli> ncopa: +1
2018-12-07 18:45:27 <mps> I'd like to upgrade crystal lang to 0.27 for the next stable. I've built it on current stable, but is built with libressl. for next stable it should be built with openssl. so, do I need to setup build system with edge and then make APKBUILD for testing it before sending patches
2018-12-07 18:45:50 <danieli> mps: if you have an apkbuild that works on edge and uses openssl, i can test it out
2018-12-07 18:46:19 <mps> no, i've upgraded it on stable
2018-12-07 18:46:40 <ncopa> im thinking: How would you like to use <disk>? ('sys', 'data', 'lvm', 'crypt' or '?' for help) [?]
2018-12-07 18:46:49 <danieli> if you can make it work on edge, it'll pretty much work on 3.9
2018-12-07 18:47:02 <kpcyrd> ncopa: that's what I had in mind, yes
2018-12-07 18:47:19 <mps> danieli: understand that, but have to setup edge build localy
2018-12-07 18:47:30 <danieli> that is true, shouldn't take long though
2018-12-07 18:47:44 <danieli> assuming you're somewhat used to setting up build environments
2018-12-07 18:48:10 <mps> last time it was chroot for aarch64
2018-12-07 18:48:16 <ncopa> mps: or you can test it in docker
2018-12-07 18:48:21 <danieli> ^
2018-12-07 18:48:23 <danieli> that's what i do locally
2018-12-07 18:48:45 <mps> don't have experience with docker :(
2018-12-07 18:48:50 <ncopa> and bind mount the dir where you have the aports tree
2018-12-07 18:48:57 <danieli> doesn't have to be docker though, it was just an example
2018-12-07 18:49:27 <mps> chroot is what used to, and sometimes lxc
2018-12-07 18:49:38 <kpcyrd> ncopa: after the user has selected crypt, should we still avoid additional questions or is something like `Which cipher should be used? [aes-xts-plain64]` ok?
2018-12-07 18:50:05 <kpcyrd> that would allow us to provide sane defaults without enforcing them and existing answerfiles are guaranteed not to hit those questions
2018-12-07 18:50:11 <ncopa> mps: apk add docker && rc-service docker start && docker run --rm -it -v/path/to/aports:/aports alpine:edge
2018-12-07 18:50:56 <mps> ncopa: ok, will try. it is time for me to learn about docker :)
2018-12-07 18:51:32 <ncopa> you should have a prompt and empty edge system, so from the prompt: apk upgrade -U -a && apk add abuild build-base && adduser mps && addgroup mps abuild && cd /aports
2018-12-07 18:52:10 <ncopa> when you exit the shell it will destroy your container
2018-12-07 18:52:18 <mps> will try this night
2018-12-07 18:52:40 <ncopa> the above also mounted /path/to/aports on the host to /aports in the container
2018-12-07 18:52:50 <ncopa> so whatever you store there is preserved
2018-12-07 18:53:02 <mps> uff. destroy? there is no way to use it another time without all that setups
2018-12-07 18:53:16 <ncopa> you can build your own docker image
2018-12-07 18:53:28 <danieli> it's the --rm flag to `docker run`, removes it when the entrypoint process ends
2018-12-07 18:53:37 <ncopa> yeah
2018-12-07 18:54:07 <ncopa> but i sort of would recommend to create a Dockerfile if you dont want do all the setup every time
2018-12-07 18:54:19 <ncopa> there is tons of good docks on docker
2018-12-07 18:54:22 <mps> would be nice to have persistent build system
2018-12-07 18:54:32 <ncopa> then you skip the --rm
2018-12-07 18:54:40 <mps> aha, ok
2018-12-07 18:54:48 <danieli> I just have a docker container running, without rm
2018-12-07 18:54:56 <danieli> you can have long lived docker containers
2018-12-07 18:55:14 <mps> that's what i like to have
2018-12-07 18:55:54 <mps> btw, that works for all archs
2018-12-07 18:55:57 <mps> ?
2018-12-07 18:56:07 <danieli> i don't see how this is arch specific?
2018-12-07 18:56:11 <danieli> we're talking about docker here
2018-12-07 18:56:18 <danieli> docker is docker
2018-12-07 18:56:51 <mps> nice, then I could have it for aarch64 and armv7
2018-12-07 18:57:09 <danieli> if you have a docker host running on aarch64 and armv7 hosts, then sure
2018-12-07 18:57:12 <danieli> er
2018-12-07 18:57:12 <ncopa> yes
2018-12-07 18:57:19 <danieli> s/docker host/docker instance/
2018-12-07 18:57:32 <ncopa> maybe there is no official armv7 image yet
2018-12-07 18:57:42 <ncopa> but aarch64 should work at least
2018-12-07 18:57:46 <danieli> anyway, try `docker run -dit --name some_name alpine:edge` then `docker exec -it some_name sh`
2018-12-07 18:58:23 <danieli> Supported architectures: amd64, arm32v6, arm64v8, i386, ppc64le, s390x
2018-12-07 18:58:25 <mps> I tried docker when it appeared, long time ago, but didn't worked with it anything serious and forgot how to use it
2018-12-07 18:59:07 <danieli> if you don't need it, you might as well not remember how it works, it's not everyone's cup of tea
2018-12-07 18:59:28 <danieli> mps: also, heads up, ncopa works there (docker) :P
2018-12-07 19:00:04 <mps> 'apk search docker' on armv7 'says' that it is not found
2018-12-07 19:00:27 <danieli> ncopa: did we build world on armv7 and offiically release it?
2018-12-07 19:00:39 <mps> nvm, will try it first on x86_64
2018-12-07 19:00:41 <ncopa> danieli: not yet
2018-12-07 19:01:04 <danieli> that's what i thought
2018-12-07 19:01:20 <danieli> how come it's still not working?
2018-12-07 19:03:05 <andypost> ncopa, any idea why edge docker image points to 3.7 repos? https://gist.github.com/andypost/f4c7edc33dcf92eed1a405c2309aa303
2018-12-07 19:03:17 <andypost> I mean arm8 image
2018-12-07 19:03:44 <danieli> ... uh?
2018-12-07 19:03:54 <danieli> what's your /etc/apk/repositories ...?
2018-12-07 19:04:20 <ncopa> andypost: no. sounds like a bug
2018-12-07 19:04:32 <ncopa> we need clean up that
2018-12-07 19:04:35 <andypost> danieli, as apk points http://dl-cdn.alpinelinux.org/alpine/v3.7/main
2018-12-07 19:04:58 <danieli> that didn't really clarify it to me
2018-12-07 19:05:16 <SpaceToast> the edge image is pretty old
2018-12-07 19:05:26 <SpaceToast> probably because we don't publish snapshots very often
2018-12-07 19:05:28 <ncopa> danieli: the edge image has v3.7 in repos
2018-12-07 19:05:42 <danieli> aaah, gotcha
2018-12-07 19:05:46 <danieli> now it makes sense
2018-12-07 19:05:47 <SpaceToast> it should still have edge in repos though :/
2018-12-07 19:05:50 <ncopa> the edge image was probably built using the v3.7 release tarball
2018-12-07 19:05:50 <danieli> why though?
2018-12-07 19:06:01 <andypost> oh I already used to comment on it https://github.com/gliderlabs/docker-alpine/issues/375
2018-12-07 19:06:22 <ncopa> because we don't make release snapshots from edge as we should
2018-12-07 19:06:42 <ncopa> it was one of the reasons i started a releng thread on alpine-devel list recently
2018-12-07 19:07:01 <danieli> who exactly is gliderlabs, and how come that's the alpine 'offical repository'?
2018-12-07 19:07:17 <ncopa> we need make snapshots monthly or so from edge
2018-12-07 19:07:34 <ncopa> gliderlabs is a small company that created alpine docker image early
2018-12-07 19:07:39 <ncopa> and maintained it for long time
2018-12-07 19:07:53 <ncopa> before i got interested in docker
2018-12-07 19:08:02 <danieli> but 'official repository' seems a bit strange?
2018-12-07 19:08:05 <ncopa> so they built the official docker images
2018-12-07 19:08:12 <SpaceToast> danieli: "official" in docker just means that it's under _, it isn't required for an official image to be made by the developers of a given thing
2018-12-07 19:08:18 <SpaceToast> it just requires docker to recognize it
2018-12-07 19:08:29 <danieli> fair enough, i don't really use docker that much anyway
2018-12-07 19:08:33 <ncopa> but they also have my blessing for it
2018-12-07 19:08:39 <ncopa> so i have git push access to the repo
2018-12-07 19:08:45 <danieli> it was more or less just morbid curiosity
2018-12-07 19:08:50 <ncopa> and have been doing the work lately
2018-12-07 19:09:05 <ncopa> but we should move it to alpinelinux org
2018-12-07 19:09:26 <ncopa> we should build the docker images as a part of the release process
2018-12-07 19:09:39 <danieli> considering that's what most alpine users use alpine for, yeah, i'd say so
2018-12-07 19:09:40 <ncopa> eg a job for releng "team" to figure out
2018-12-07 19:09:49 <danieli> i can imagine the majority of the alpine user base use it in docker
2018-12-07 19:09:53 <ncopa> yes
2018-12-07 19:10:27 <ncopa> ok, its weekend
2018-12-07 19:10:37 <danieli> oh well, at least alpine isn't "owned" by docker
2018-12-07 19:10:44 <danieli> lol, have a good one
2018-12-07 19:10:58 <ncopa> i will likely be away most of next week
2018-12-07 19:11:15 <ncopa> will attend the reproducible builds in paris
2018-12-07 19:11:29 <SpaceToast> enjoy :)
2018-12-07 19:11:31 <ncopa> reproducible builds summit
2018-12-07 19:11:37 <ncopa> merci
2018-12-07 19:12:11 <danieli> i'm not sure we have fully deterministic compilation
2018-12-07 19:12:16 <danieli> do we?
2018-12-07 19:12:46 <ncopa> we dont
2018-12-07 19:12:52 <ncopa> not yet
2018-12-07 19:13:13 <ncopa> which is why i though it would be interesting to attend the summit
2018-12-07 19:13:48 <ncopa> have a nice weekend everyone
2018-12-07 19:13:53 <danieli> considering how much control of its own ecosystem alpine lacks, it's gonna be a bumpy ride
2018-12-07 19:15:14 <mps> danieli: ncopa: started build crystal under docker, thank you for help
2018-12-07 19:17:41 <mps> danieli: could be more cpus assigned to docker to have abuild with  -j X (X > 1)
2018-12-07 19:17:50 <danieli> it's just a container
2018-12-07 19:17:52 <danieli> not a VM
2018-12-07 19:19:25 <mps> so, it is enough to set 'export JOBS=4' in /etc/abuild.conf
2018-12-07 19:19:27 <mps> ?
2018-12-07 19:19:35 <danieli> check ncpu
2018-12-07 19:19:36 <SpaceToast> yes, unless you explicitly enabled CPU namespacing
2018-12-07 19:19:40 <danieli> yup
2018-12-07 19:19:42 <mps> in docker image
2018-12-07 19:19:46 <danieli> it just reflects the resources the docker host has
2018-12-07 19:21:53 <mps> changed 'export JOBS=4' but it uses just one cpu
2018-12-07 19:22:53 <danieli> export JOBS=48
2018-12-07 19:22:53 <danieli> export MAKEFLAGS="-j$JOBS -l$JOBS"
2018-12-07 19:24:58 <mps> will remeber, for now just want to see if crystal could be built
2018-12-07 20:58:46 <kh405_tv_> Hey all, i've been refered here cause i'm trying to run deluge and getting this error
2018-12-07 20:59:21 <kh405_tv_> seedbox:/etc$ deluged seedbox:/etc$ [ERROR   ] 15:59:05 main:248 Error relocating /usr/lib/python2.7/site-packages/cryptography/hazmat/bindings/_openssl.so: SSL_CTX_set_psk_client_callback: sym bol not found Traceback (most recent call last):   File "/usr/lib/python2.7/site-packages/deluge/main.py", line 240, in start_daemon     from deluge.core.daemon import Daemon   File "/usr/lib/python2.7/site-packages/deluge/core/daemon
2018-12-07 20:59:27 <kh405_tv_> Sorry for the formating
2018-12-07 21:24:31 <kh405_tv_> Anyone ?
2018-12-07 21:53:35 <mps> ncopa: danieli: built sucessfully crystal lang 0.27 on edge, without libressl, made some tests, looks ok
2018-12-07 21:54:04 <mps> need to fix one of the patches
2018-12-08 00:39:29 <clandmeter> there was/is an error with pkgs.a.o automatic flagging. i worked around the issue so maintainers should receive a bunch of emails.
2018-12-08 00:54:53 <mpmc> clandmeter: Could you take a look at why unit for armhf isn't building please? :)
2018-12-08 03:27:34 <danieli> mpmc: you sent that message at 2 am, better luck next time
2018-12-08 03:28:16 <danieli> anyway, edge/armhf/community/unit seems to have built fine
2018-12-08 03:28:18 <danieli> http://build.alpinelinux.org/buildlogs/build-edge-armhf/community/unit/unit-1.6-r0.log
2018-12-08 09:42:06 <mpmc> danieli: at the time, it wasn't there on pkg. I wasn't expecting it to be solved right away, just wondered if anyone knew why. Not sure what you were getting at with "better luck next time" though, really wasn't needed.
2018-12-08 09:42:47 <danieli> that came off the wrong way, don't know why I said that - I meant better luck when you repost during daytime in Europe
2018-12-08 09:45:37 <mpmc> danieli: I am in Europe, when I sent that it was almost 1am. don't worry about it, maybe you were just cranky from being tired! :)
2018-12-08 09:45:54 <danieli> it really just came off the wrong way, I didn't think the sentence through
2018-12-08 09:47:06 <mpmc> No harm done :)
2018-12-08 09:48:56 <danieli> looks like the last time it was built was uh
2018-12-08 09:48:59 <danieli> Nov 23rd
2018-12-08 09:49:52 <danieli> and the last commit to it was Nov 17th
2018-12-08 10:38:38 <clandmeter> mpmc, i did try to fix it at 2:00 ;-)
2018-12-08 10:38:48 <clandmeter> Not sure i did
2018-12-08 11:03:50 <mpmc> clandmeter: Well as danieli said it's there now, so ty :)
2018-12-08 11:04:32 <danieli> it should've been there already, it hasn't been rebuilt for a while
2018-12-08 11:05:31 <clandmeter> I don't think it was
2018-12-08 11:05:36 <danieli> how come?
2018-12-08 11:05:50 <danieli> seems odd if it's been there for a few weeks already
2018-12-08 11:05:58 <danieli> i mean, if it was built a few weeks ago
2018-12-08 11:05:58 <clandmeter> All pkgs need to be build before sync
2018-12-08 11:06:32 <clandmeter> I had to unblock the builder
2018-12-08 11:06:52 <clandmeter> It also took a long time to upload
2018-12-08 11:07:03 <danieli> aaah, so it doesn't sync unless world is built?
2018-12-08 11:10:48 <brebs> Is fcolista still active? I'm hoping to progress https://patchwork.alpinelinux.org/patch/4135/ from a month ago.
2018-12-08 11:11:05 <clandmeter> It got pushed with some other changes i think of which a later broke the builder.
2018-12-08 11:11:07 <fcolista> here I am brebs
2018-12-08 11:13:03 <brebs> The current mate-screensaver isn't fit for purpose, because it doesn't actually lock the screen with password-protection :(  Is https://patchwork.alpinelinux.org/patch/4135/ OK to apply? It's been working fine for me, for weeks.
2018-12-08 11:13:07 <clandmeter> It's a setting of the build scripts to hold on error. We disable it on new builders when we want to build new world
2018-12-08 11:13:48 <fcolista> ok
2018-12-08 12:12:39 <myhro> mps: I didn't saw your messages last night, but that's the setup I use to build edge packages on Docker: https://github.com/myhro/alpine-builder - could be useful for you.
2018-12-08 12:26:04 <mps> Myhro: thanks, but I installed edge under chroot and build crystal already
2018-12-08 12:27:53 <mps> btw, is jirutka active on any irc AL channel or mailing list
2018-12-08 12:36:38 <Myhro> Oh, OK. I undestood you did that through Docker.
2018-12-08 12:49:18 <danieli> mps: as far as I've understood, he now only maintains packages for personal use
2018-12-08 12:54:02 <mps> Myhro: tried with docker according to ncopa and danieli advices but give up and switched back to chroot because I don't have experience with docker
2018-12-08 12:54:33 <danieli> I have long-running docker containers for building locally, I just treat them as if they were VMs
2018-12-08 12:55:05 <danieli> from a user perspective, they appear *largely* the same way anyway
2018-12-08 12:55:07 <mps> danieli: I have seen some commits from jirutka in a few hours ago, because that asked if he could be reached
2018-12-08 12:55:08 <Myhro> mps: sure, but my impression is that you would like to get used to it. No problem.
2018-12-08 12:55:32 <danieli> mps: aha, well, you can probably find his email pretty easily
2018-12-08 12:56:55 <Myhro> danieli: yes, until you need to test a daemon, then its no use. :-(
2018-12-08 12:57:18 <danieli> good point, that can be painful
2018-12-08 12:57:19 <mps> Myhro: I will try to learn about it, but first need to read more how it works to understand it better. don't like just 'jump in' without understanding technology
2018-12-08 12:57:22 <danieli> consider lxc in that case
2018-12-08 12:57:44 <mps> danieli: I use lxc
2018-12-08 12:58:02 <mps> have one debian running all the time
2018-12-08 12:59:28 <mps> danieli: I see his email address but don't like to bother him on email if he is not active
2018-12-08 12:59:44 <danieli> if it's related to a change he just made to aports, i cannot imagine he minds
2018-12-08 13:00:55 <mps> well, maybe, but in my view it is not polite to contact people if they didn't tpld explicitly we can
2018-12-08 13:01:07 <danieli> i do agree there, unless there's no other choice
2018-12-08 13:01:09 <mps> s/tpld/told/
2018-12-08 13:01:19 <danieli> abdc
2018-12-08 13:01:21 <danieli> s/dc/cd/
2018-12-08 13:01:31 <danieli> alpine-meetbot, where art thou
2018-12-08 13:02:02 <mps> is that a irc channel
2018-12-08 13:05:02 <danieli> it's a bot
2018-12-08 13:05:30 <mps> looks like it is bot but wasn't sure. thanks
2018-12-08 14:24:00 <clandmeter> It's never been here iirc
2018-12-08 14:28:04 <_ikke_> only in alpine-infra and alpine-meetings
2018-12-08 14:28:15 <_ikke_> though, I might have invited it in here once
2018-12-08 14:30:58 <mps> you are talking about jirutka?
2018-12-08 14:31:29 <_ikke_> alpine-meetbot
2018-12-08 14:31:41 <mps> ah, so.
2018-12-08 14:37:52 <_ikke_> .uptime
2018-12-08 14:37:52 <alpine-meetbot> I've been sitting here for 5 days, 3:14:21 and I keep going!
2018-12-08 14:37:56 <_ikke_> :)
2018-12-08 14:51:22 <danieli> i didn't realize #alpine-meetings was a channel
2018-12-08 16:04:19 <andypost> Shiz, looks you patch for rust no longer applicable https://github.com/alpinelinux/aports/pull/5781
2018-12-08 16:09:44 <ddevault> wip https://sr.ht/J5by.png
2018-12-08 16:15:38 <clandmeter> danieli, it was in one of my emails
2018-12-08 16:16:09 <clandmeter> ddevault, nice!
2018-12-08 16:16:19 <ddevault> (running on real RISC-V hardware, not emulated)
2018-12-08 16:16:40 <SpaceToast> ddevault: nice! Can I have one? :D
2018-12-08 16:16:51 <ddevault> if you have a grand to spend on it, sure
2018-12-08 16:17:03 <ddevault> https://www.crowdsupply.com/sifive/hifive-unleashed
2018-12-08 16:17:08 <SpaceToast> :( yeah I saw that one
2018-12-08 16:17:17 <SpaceToast> I want it but I do *not* have a grant to spend on one ^^;;
2018-12-08 16:17:24 <ddevault> the bootstrapping process for a new Alpine port is super smooth
2018-12-08 16:17:50 <ddevault> I'm about 10 hours in
2018-12-08 16:22:07 <danieli> ddevault: nice! I wanted to do that but I couldn't get a hold of hardware very easily
2018-12-08 16:22:28 <ddevault> once I have this working I'm going to make it available to the generic public for CI
2018-12-08 16:22:38 <ddevault> and use that to automate porting the most of Alpine
2018-12-08 16:22:42 <danieli> i have some emails to acquaintances to get some mips hardware
2018-12-08 16:22:45 <danieli> mips and mips64
2018-12-08 16:22:48 <ddevault> so if you want to run some code on it just keep in touch :)
2018-12-08 16:23:12 <danieli> adding it to your build site?
2018-12-08 16:23:14 <ddevault> hifive offered to send me more of these if the demand is high
2018-12-08 16:23:17 <ddevault> yeah
2018-12-08 16:23:19 <ddevault> sifive*
2018-12-08 16:23:32 <danieli> god damn, I want a couple
2018-12-08 16:23:55 <danieli> it'd be really nice to set up a small riscv build farm and get world built
2018-12-08 16:24:10 <ddevault> I'm going to gut one of my 1Us and convert it into a RISC-V farm
2018-12-08 16:24:25 <ddevault> the hard part is my build system is designed for KVM which is not supported on riscv yet
2018-12-08 16:24:45 <danieli> what language did you write the backend for it in? I haven't really looked into the seams
2018-12-08 16:24:50 <ddevault> so I'm going to set up a raspberry pi to do netbooting and nbd and short the reset when your build time is up
2018-12-08 16:24:55 <ddevault> python and Go
2018-12-08 16:25:04 <danieli> neat
2018-12-08 16:25:11 <ddevault> https://git.sr.ht/~sircmpwn/builds.sr.ht
2018-12-08 16:25:57 <danieli> god damn, it'd be nice to get a builder set up on riscv and get world built
2018-12-08 16:26:16 <ddevault> well, that's the plan
2018-12-08 18:01:03 <ddevault> so I've run into a couple of weird issues
2018-12-08 18:01:22 <ddevault> just in case they seem familiar to anyone
2018-12-08 18:02:31 <ddevault> I can't open directories with ls or echo /* (didn't try anything else), strace shows openat returning EINVAL
2018-12-08 18:02:47 <ddevault> ruled out filesystem driver issues, can reproduce from tmpfs and ext4
2018-12-08 18:03:00 <ddevault> glibc busybox on buildroot can ls just fine outside of the chroot
2018-12-08 18:03:29 <ddevault> other issue is that I get ELOOP when the musl loader opens /lib/libz.so.1, which is a symlink but is not a loop
2018-12-08 18:05:36 <ddevault> actually I get the same behavior if libz.so.1 is a regular file
2018-12-08 18:26:24 <SpaceToast> egh, appologies on the extranious -devel email; git-send-email errored out but still sent the email somehow (I'm sure it's PEBCAK, but not quite sure what went wrong exactly)
2018-12-08 18:38:23 <rhencke> hi folks - would this be the right forum for abuild internals-related questions?
2018-12-08 18:38:30 <danieli> I suppose, yeah
2018-12-08 18:42:03 <rhencke> I (crudely) ported apk to Mac OS (darwin) and am investigating using apk/abuild as an alternative to other popular package managers on the platform.  There are some parts of the system that make (understandable) assumptions that the environment will be linux.  For example, in functions.sh.in in abuild, there is arch_to_hostspec/hostspec_to_arch and friends.
2018-12-08 18:42:33 <danieli> well, it isn't really adapted for use on any other system, so there will probably be *a lot* of linux-isms
2018-12-08 18:44:02 <rhencke> Yes - there are.  But it's actually so far pretty smooth - I've got apk and abuild running locally, using dash as a substitute for ash.  Granted, haven't built a package yet, but... it's getting there. :)
2018-12-08 18:44:14 <danieli> hah, neat
2018-12-08 18:44:53 <rhencke> I fell in love with apk - it's so fast.  The most popular alternative option for package management on Mac is, well.. it's not nearly as fast as apk. :)
2018-12-08 18:45:26 <_ikke_> rhencke: There aren't a lot package managers faster than APK
2018-12-08 18:45:47 <danieli> it's pretty much between brew and macports isn't it?
2018-12-08 18:45:57 <clandmeter> And the idea is to make it even faster
2018-12-08 18:46:00 <rhencke> @_ikke_ Amen
2018-12-08 18:46:05 <danieli> shitty meme: sanic.exe
2018-12-08 18:46:46 <rhencke> @danieli Yes, pretty much.  And brew has a lot of wonderful ideas and a large community of maintainers, but... it's honestly just very slow, especially put up against apk.
2018-12-08 18:47:30 <_ikke_> My experience that a lot of applications written in ruby are very slow
2018-12-08 18:47:51 <danieli> is ruby fast yet
2018-12-08 18:47:57 <_ikke_> they are working on it
2018-12-08 18:48:02 <danieli> hah, yeah, it's just a meme
2018-12-08 18:48:22 <danieli> it has become significantly faster, but ruby will comparatively never be fast
2018-12-08 18:48:51 <_ikke_> What I notice mostly is that it takes seconds for tools to even start
2018-12-08 18:49:09 <danieli> yeah, that's a pet peeve of mine, some tools are ridiculously slow
2018-12-08 18:49:16 <rhencke> But, regarding arch_to_hostspec/hostspec_to_arch, for now at least, maybe the best approach is just to sniff the host OS, and use that to influence the result.  I'm still honestly not sure if my work will go anywhere, but... I also just wanted to share and get thoughts, as this is not my area of expertise.
2018-12-08 18:51:04 <rhencke> @_ikke_ Yes, pet peeve of mine as well
2018-12-08 19:35:50 <ddevault> started pushing my work here if anyone wants to follow along: https://git.sr.ht/~sircmpwn/abuild https://git.sr.ht/~sircmpwn/abuild https://git.sr.ht/~sircmpwn/aports
2018-12-08 19:36:39 <_ikke_> 5ddwhat are you working on?
2018-12-08 19:36:48 <ddevault> porting Alpine to riscv64
2018-12-08 19:36:52 <_ikke_> s/5dd/ddevault/
2018-12-08 19:36:52 <alpine-meetbot> _ikke_ meant to say: ddevaultwhat are you working on?
2018-12-08 19:37:01 <_ikke_> ok
2018-12-08 19:37:13 <_ikke_> Why does abuild need to be changed for that?
2018-12-08 19:37:24 <ddevault> https://git.sr.ht/~sircmpwn/abuild/commit/4a9838b9976919453bd530bbd06635fcc89976a9
2018-12-08 19:37:44 <ddevault> I also did this to get it building on edge, unrelated to riscv https://git.sr.ht/~sircmpwn/abuild/commit/f0029d7c98e8481d57099138ae33127be7bf5d14
2018-12-08 19:37:51 <_ikke_> ah, to recognize the arch
2018-12-08 19:38:32 <ddevault> the apk-tools patch is similar
2018-12-08 19:39:05 <ddevault> I'll be putting up a repo once I complete the bootstrapping process
2018-12-08 19:39:19 <ddevault> which should be pretty soon, once I figure out the libc issues
2018-12-08 19:39:31 <rhencke> @ddevault is sr.ht your creation?
2018-12-08 19:39:34 <ddevault> yes
2018-12-08 19:39:39 <rhencke> @ddevault this looks awesome
2018-12-08 19:39:42 <ddevault> thank you!
2018-12-08 20:55:56 <ddevault> fixed the main weird issues :D
2018-12-08 21:51:03 <jwh> 
ACTION coughs

2018-12-08 21:51:06 <jwh> pr #5607
2018-12-08 21:51:07 <jwh> :D
2018-12-08 21:51:48 <jwh> uh, 5706
2018-12-08 21:52:55 <danieli> #5706
2018-12-08 21:53:01 <danieli> oh right, PR, not bug, silly me
2018-12-08 21:53:13 <jwh> aports tooo
2018-12-08 21:53:25 <jwh> haven't woken up yet
2018-12-08 21:53:37 <ddevault> https://github.com/alpinelinux/aports/pull/5706 [?]
2018-12-08 21:53:43 <jwh> ye
2018-12-08 21:54:06 <danieli> would be handy for some people considering how popular docker is in that community
2018-12-08 21:54:14 <jwh> ya
2018-12-08 21:54:28 <jwh> I'm not using docker, but I use it standalone with consul
2018-12-08 21:54:36 <danieli> it's late on a saturday evening, so you should probably repeat it tomorrow roughly during daytime
2018-12-08 21:54:42 <danieli> or monday, even
2018-12-08 21:54:46 <jwh> ye
2018-12-08 21:55:39 <jwh> still haven't got cockroach fixed, but making progress..
2018-12-09 01:20:08 <jwh> hm
2018-12-09 01:20:23 <jwh> should maintainer be me? or do I have to get someone with commit access to volunteer?
2018-12-09 01:24:00 <SpaceToast> maintainer should be you, as far as I'm aware
2018-12-09 01:24:20 <jwh> mmk
2018-12-09 01:24:49 <danieli> it should
2018-12-09 22:15:35 <jwh> hm
2018-12-10 09:41:51 <jwh> hmph, litespeed package doesn't work ootb :(
2018-12-10 09:46:14 <danieli> jwh: what's broken?
2018-12-10 09:46:39 <jwh> php, cgi examples
2018-12-10 09:46:51 <jwh> even though it *looks* like at least php should work
2018-12-10 09:47:04 <jwh> but its just dumping phpinfo.php out
2018-12-10 09:47:34 <jwh> theres also:
2018-12-10 09:47:35 <jwh> 2018-12-10 09:40:04.247148 [INFO] [PlainConf] [virtualHostTemplate:] Failed to RCS checkin conf file /var/lib/litespeed/conf/templates/rails.conf0, ret 32512, error(Invalid argument). Org command is ci -l -q -t-"/var/lib/litespeed/conf/t
2018-12-10 09:47:39 <jwh> emplates/rails.conf0" -mUpdate "/var/lib/litespeed/conf/templates/rails.conf0" >/dev/null 2>&1
2018-12-10 09:47:42 <jwh> not sure how relevant that is
2018-12-10 09:47:57 <jwh> like if thats a rails command or something
2018-12-10 09:48:01 <danieli> hm, I'll test it out soon enough
2018-12-10 09:48:32 <jwh> it should also probably depend on php7-posix, since thats missing and the "compile php" page won't work without it
2018-12-10 12:39:44 <mps> I've got next response from 'abuild -r': ERROR: APKINDEX.tar.gz: UNTRUSTED signature
2018-12-10 12:39:58 <mps> >>> ERROR: crystal: Failed to create index
2018-12-10 12:40:30 <mps> why, because I have set abuild correctly
2018-12-10 12:48:19 <clandmeter> mps, it means abuild wasnt able to sign previously, or it cannot find the correct key now.
2018-12-10 12:50:05 <mps> clandmeter: maybe because I 'bind mounted' my home dir to lxc container with edge where I'm trying to build new crystal version?
2018-12-10 12:51:00 <mps> when build packages on the host I don't had that problem.
2018-12-10 13:08:12 <clandmeter> nmeum, did you mention me recently about something?
2018-12-10 13:10:05 <nmeum> clandmeter: yeah, just wanted to inform you that the common name of the tpaste.us https certificate is incorrect
2018-12-10 13:10:17 <clandmeter> ah ok
2018-12-10 13:11:11 <clandmeter> i never noticed as i never use https on tpaste :)
2018-12-10 13:12:38 <mps> clandmeter: forgot to put me as packager in /etc/abuild.conf on edge lxc. problem solved.
2018-12-10 13:43:42 <fcolista> xen in edge/main is still compiled against libressl
2018-12-10 13:47:01 <mps> is there option in abuild to make build log, or use 'tee'
2018-12-10 13:55:39 <clandmeter> mps, i dont think so
2018-12-10 13:56:46 <mps> ok, then the 'tee' will help. thanks
2018-12-10 13:58:57 <mps> btw, I finished apk crystal for edge with openssl. now trying to build static snapshot which will be needed for bootstraping next version
2018-12-10 14:13:46 <jwh> danieli: theres a few things  up with the pckage
2018-12-10 14:13:48 <jwh> package*
2018-12-10 15:18:46 <fcolista> ah there's a bug open..    https://github.com/alpinelinux/aports/pull/5629
2018-12-10 15:19:58 <fcolista> this is a blocker for libvirt upgrade..
2018-12-10 16:33:19 <ncopa> i looked a bit on it today
2018-12-10 16:33:29 <ncopa> apparently there are more fixes needed for gcc8
2018-12-10 16:33:45 <ncopa> i get: /tmp/ccGDIMOj.s:18289: Error: can't resolve `__table_entries.2720' {.tbl.net_device_configurators.99 section} - `__table_entries.2722' {.tbl.net_device_configurators.00 section}
2018-12-10 16:34:50 <ncopa> oh there is a proposal for a fix on the PR
2018-12-10 16:38:00 <jwh> danieli: https://github.com/alpinelinux/aports/pull/5811
2018-12-10 16:38:06 <jwh> just a quick look....
2018-12-10 16:38:38 <jwh> dunno what happened to the second bit
2018-12-10 16:38:55 <jwh> theres also something going wrong with the chown
2018-12-10 16:42:59 <jwh> there is something pretty wrong with with that package though, the default config *should* work but it dosn't
2018-12-10 16:43:02 <jwh> doesn't*
2018-12-10 19:46:14 <geosmin> ncopa: i'm actually not sure what the right fix is here :)
2018-12-10 20:07:03 <geosmin> ncopa: can't be solved script side, should /etc/hostname be removed from alpine-baselayout?
2018-12-10 20:52:01 <SpaceToast> geosmin: lots of stuff in -baselayout / -conf are outdated
2018-12-10 20:52:08 <SpaceToast> I keep coming accross them as I write our installation docs
2018-12-10 20:52:22 <SpaceToast> I'm planning to talk to ncopa about the majority of them when he comes back from the repeatable build summit or whatever :)
2018-12-10 20:57:39 <mps> I'm finished (I hope) APKBUILD for crystal 0.27.0 but before posting changes to alpine-aports would like if someone is willing to review it
2018-12-10 20:58:17 <_ikke_> mps: I can take a quick look
2018-12-10 20:58:46 <mps> _ikke_: just moment to put it on tpaste
2018-12-10 20:59:51 <mps> _ikke_: http://tpaste.us/9gjK
2018-12-10 21:11:47 <_ikke_> mps: did you adjust an exist APKBUILD?
2018-12-10 21:11:54 <_ikke_> probably
2018-12-10 21:13:04 <_ikke_> Ok, so the changes are minimal
2018-12-10 21:14:42 <mps> yes, but removed libressl patches and added some which is needed to pass 'make spec'
2018-12-10 21:15:22 <mps> and removed paxmark patch, I think it is not needed in edge
2018-12-10 21:16:26 <mps> you can diff with aports/community/crystal/APKBUILD
2018-12-10 21:16:52 <_ikke_> yes, was doing that
2018-12-10 21:17:24 <_ikke_> http://tpaste.us/nMWM
2018-12-10 21:18:20 <mps> yes, right
2018-12-10 21:19:44 <mps> yesterday talked with one of the crystal core developers and he told me that they build on Alpine first to check if it is ok
2018-12-10 21:20:11 <_ikke_> nice
2018-12-10 21:21:04 <_ikke_> What do you use crystal for?
2018-12-10 21:22:20 <mps> I'm relatively new to it, but trying to move some of my software (for my job) from go and perl to crystal
2018-12-10 21:22:29 <geosmin> SpaceToast: is  my assumption wrong that the fix here would be to remove /etc/hostname from -baselayout?
2018-12-10 21:22:47 <geosmin> see bug here: https://bugs.alpinelinux.org/issues/9744
2018-12-10 21:22:53 <_ikke_> Where should it come from then?
2018-12-10 21:23:05 <_ikke_> ah,ok
2018-12-10 21:23:12 <SpaceToast> geosmin: I don't recall specifics and I'm at home right now :)
2018-12-10 21:23:30 <mps> https://crystal-lang.org/
2018-12-10 21:23:33 <SpaceToast> _ikke_: seems to be leftovers from uclibc - also see /etc/TZ, how we handle timezones, and many other similar things
2018-12-10 21:23:46 <_ikke_> mps: yeah, was reading that
2018-12-10 21:24:08 <mps> ok, sorry then
2018-12-10 21:24:13 <geosmin> openrc doesn't require the file, hostname is set at boot by the init.d script, and if desired the user can echo foo > /etc/hostname and lbu commit
2018-12-10 21:37:06 <mps> _ikke_: what you think, is it ok to post it alpine-aports?
2018-12-10 21:37:30 <mps> to alpine-aports
2018-12-10 21:37:34 <_ikke_> yes
2018-12-10 21:38:09 <mps> is it ok to leave maintainer name as it is?
2018-12-10 21:38:39 <_ikke_> mps: Not sure if jirutka is still maintaining it
2018-12-10 21:39:23 <mps> I also don't know. I will left it as it is for now with hope that he will not have objections
2018-12-10 21:39:53 <mps> _ikke_: thank you for the help
2018-12-10 21:40:10 <_ikke_> np
2018-12-10 23:02:42 <KH405_TV> Hey, i've went on #alpine linux and they told me to come here to fix my issue
2018-12-10 23:02:54 <KH405_TV> I'm trying to start Deluged daemon and getting this error
2018-12-10 23:03:05 <KH405_TV> main:248 Error relocating /usr/lib/python2.7/site-packages/cryptography/hazmat/bindings/_openssl.so: SSL_CTX_set_psk_client_callback: symbol not found
2018-12-10 23:03:18 <KH405_TV> Traceback (most recent call last):
2018-12-10 23:03:18 <KH405_TV>   File "/usr/lib/python2.7/site-packages/deluge/main.py", line 240, in start_daemon
2018-12-10 23:03:18 <KH405_TV>     from deluge.core.daemon import Daemon
2018-12-10 23:03:18 <KH405_TV>   File "/usr/lib/python2.7/site-packages/deluge/core/daemon.py", line 47, in <module>
2018-12-10 23:03:18 <KH405_TV>     from deluge.core.rpcserver import RPCServer, export
2018-12-10 23:03:19 <KH405_TV>   File "/usr/lib/python2.7/site-packages/deluge/core/rpcserver.py", line 47, in <module>
2018-12-10 23:03:21 <KH405_TV>     from twisted.internet import ssl, reactor, defer
2018-12-10 23:03:23 <KH405_TV>   File "/usr/lib/python2.7/site-packages/twisted/internet/ssl.py", line 59, in <module>
2018-12-10 23:03:25 <KH405_TV>     from OpenSSL import SSL
2018-12-10 23:03:27 <KH405_TV>   File "/usr/lib/python2.7/site-packages/OpenSSL/__init__.py", line 8, in <module>
2018-12-10 23:03:29 <KH405_TV>     from OpenSSL import crypto, SSL
2018-12-10 23:03:31 <KH405_TV>   File "/usr/lib/python2.7/site-packages/OpenSSL/crypto.py", line 16, in <module>
2018-12-10 23:03:33 <KH405_TV>     from OpenSSL._util import (
2018-12-10 23:03:35 <KH405_TV>   File "/usr/lib/python2.7/site-packages/OpenSSL/_util.py", line 6, in <module>
2018-12-10 23:03:39 <KH405_TV>     from cryptography.hazmat.bindings.openssl.binding import Binding
2018-12-10 23:03:41 <KH405_TV>   File "/usr/lib/python2.7/site-packages/cryptography/hazmat/bindings/openssl/binding.py", line 14, in <module>
2018-12-10 23:03:44 <KH405_TV>     from cryptography.hazmat.bindings._openssl import ffi, lib
2018-12-10 23:03:46 <KH405_TV> ImportError: Error relocating /usr/lib/python2.7/site-packages/cryptography/hazmat/bindings/_openssl.so: SSL_CTX_set_psk_client_callback: symbol not found
2018-12-10 23:03:49 <KH405_TV> ^C
2018-12-10 23:03:51 <KH405_TV> Any clue where I should look for ?
2018-12-10 23:47:17 <KH405_TV> anyone ?
2018-12-11 07:49:33 <danieli> KH405_TV: please don't paste huge text walls in IRC...
2018-12-11 07:49:40 <danieli> it posts one message for each line
2018-12-11 09:11:44 <danieli> ncopa: ouch, why is so much of the alpine code unlicensed?
2018-12-11 09:12:15 <danieli> code without a license is copyrighted and is by default all rights reserved
2018-12-11 09:13:07 <danieli> also, adding a license does not apply retroactively
2018-12-11 09:13:42 <danieli> this is not good
2018-12-11 09:23:49 <[[sroracle]]> abuild is GPL-2.0-only from what i gather
2018-12-11 09:23:55 <[[sroracle]]> it says at the top of abuild.in
2018-12-11 09:24:15 <[[sroracle]]> a separate LICENSE file would be nice too though
2018-12-11 09:25:52 <danieli> it says "GPL-2"
2018-12-11 09:26:02 <danieli> doesn't that apply only to that file though?
2018-12-11 09:26:11 <[[sroracle]]> the other shell files also have similar declarations
2018-12-11 09:26:16 <danieli> abuild-fetch.c is MIT
2018-12-11 09:26:33 <danieli> abuild-gzsplit.c has none
2018-12-11 09:27:33 <danieli> apkbuild-cpan.in has none
2018-12-11 09:27:48 <danieli> apkbuild-gem-resolver.in is copyrighted to kunkku
2018-12-11 09:27:58 <danieli> in 2014-2016 anyway
2018-12-11 09:28:05 <danieli> why is this such a huge clusterf*ck?
2018-12-11 09:28:27 <danieli> functions.sh.in is unlicensed too
2018-12-11 09:29:57 <[[sroracle]]> that is a problem
2018-12-11 09:30:04 <[[sroracle]]> the rest is not so bad
2018-12-11 09:31:46 <danieli> lots of different licenses on the files that are licensed, some unlicensed, some copyrighted to specific people
2018-12-11 09:31:50 <danieli> no LICENSE/COPYING file
2018-12-11 09:32:17 <danieli> and since this was done improperly in the first place, none of what we change will apply retroactively
2018-12-11 09:35:11 <[[sroracle]]> if you gain consent of all copyright holders can you not relicense it?
2018-12-11 09:35:22 <danieli> it does not apply retroactively
2018-12-11 10:23:09 <mort___> not a lawyer but i thought that if the copyright holders could be identified and consent gained, then they could choose to do what they wanted
2018-12-11 10:23:20 <mort___> (somethign similar happened with some code in the OCaml community recently i think)
2018-12-11 11:08:22 <danieli> well, yes, but it does not apply retroactively
2018-12-11 11:15:22 <mort___> i'm not sure what that means. aiui if you are the copyright holder, then you can do what you like with the material to which you hold the copyright. if you licensed that material under some terms that allow you to revoke a license, you can do that. if you licensed that material under some terms that grant a perpetual license or whatever, then you can't revoke that but you can choose to change the license you grant in the future
2018-12-11 11:16:04 <mort___> in the case of the OCaml community, IIRC, it became necessary for people who'd contributed package descriptions to their repository to make an explicit grant of copyright
2018-12-11 11:16:27 <mort___> so there was a github issue setup and the copyright holders in question all responded to it saying that they were fine to transfer copyright
2018-12-11 11:16:33 <mort___> let me find the link ...
2018-12-11 11:17:30 <mort___> https://github.com/ocaml/opam-repository/issues/955
2018-12-11 11:19:06 <mort___> (sorry, it looks like when i said "grant of copyright" above, i meant "license under CC0")
2018-12-11 11:56:01 <mps> ncopa: I posted new APKBUILD for crystal to alpine-aports
2018-12-11 12:03:07 <danieli> he's away most of this week
2018-12-11 12:04:12 <mps> aha, ok. tab complete shows he is here
2018-12-11 12:06:02 <mps> anyone else of core devs are willing to look at patch. it is upgrade to 0.27.0 and rebuild with openssl
2018-12-11 12:37:26 <danieli> he's here but absent
2018-12-11 13:23:41 <TBB> based on the conversation exactly one year ago, yup, the licensing model should've been there from the start. now the only way is to get consent from each contributor, and you're not going to get it
2018-12-11 13:24:16 <TBB> (which was explicitly stated by one contributor with threats of legal action)
2018-12-11 13:24:29 <TBB> <- not a lawyer either tho
2018-12-11 15:42:15 <clandmeter> yangxuan, we use https://release-monitoring.org/ for pkgs.a.o
2018-12-11 15:42:46 <clandmeter> but there are other sites that track pkg versions cross distro
2018-12-11 15:49:52 <yangxuan> clandmeter: you mean linux-amlogic? 4.19 is LTS, and the new PR will upgrade to 4.19.6
2018-12-11 15:52:40 <mps> 4.19.x till 4.19.8 can corrupt ext4 fs
2018-12-11 15:53:32 <_ikke_> wow, for real?4
2018-12-11 15:53:42 <_ikke_> any source?
2018-12-11 15:54:00 <mps>  https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.19-4.20-BLK-MQ-Fix
2018-12-11 15:54:45 <mps> and a lot longer: https://bugzilla.kernel.org/show_bug.cgi?id=201685
2018-12-11 15:55:12 <clandmeter> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ffe81d45322cc3cb140f0db080a4727ea284661e
2018-12-11 15:57:15 <yangxuan> just realize read news about 4.19 ext4 issues somedays ago, maybe I should update to newer version
2018-12-11 15:57:18 <_ikke_> Ok, only if you used blk-mq without i/o scheduler?
2018-12-11 15:58:48 <mps> _ikke_: right, but alpine should build at least 4.19.8 and not 4.19.6
2018-12-11 16:16:59 <SpaceToast> TBB: that's my understanding too, but to me that suggests that something should be done sooner, rather than later, before more contributors threaten/perform legal action
2018-12-11 16:26:42 <danieli> TBB: which contributor, if I may ask?
2018-12-11 16:26:50 <danieli> you can PM if you'd like
2018-12-11 16:29:02 <_ikke_> ~!~.!.
2018-12-11 16:29:06 <_ikke_> ugh, sorry
2018-12-11 17:02:45 <danieli> erlang 21.2 is out
2018-12-11 18:06:53 <gdanko> hi there
2018-12-11 18:07:10 <gdanko> anyone here familiar with building apk packages?
2018-12-11 18:07:43 <_ikke_> gdanko: reasonably familiar
2018-12-11 18:08:56 <danieli> me too
2018-12-11 18:09:23 <gdanko> okay. I am building an "fpm" style utility in Go
2018-12-11 18:09:36 <gdanko> I have a pkginfo with some "depend" lines
2018-12-11 18:09:57 <danieli> pkginfo...?
2018-12-11 18:10:00 <gdanko> when I install the package and I do "apk -a info <pkgname>" the depends are duplicated
2018-12-11 18:10:03 <danieli> this is alpine linux we're talking about, right?
2018-12-11 18:10:05 <gdanko> .PKGINFO file
2018-12-11 18:10:07 <gdanko> yes
2018-12-11 18:10:08 <danieli> aha
2018-12-11 18:10:10 <_ikke_> danieli: metadata in the package
2018-12-11 18:10:24 <danieli> yeah, got it when they said .PKGINFO
2018-12-11 18:10:36 <danieli> gdanko: able to share the apkbuild file?
2018-12-11 18:10:37 <_ikke_> was already typing before they said that :P
2018-12-11 18:10:41 <gdanko> let me put on pastebin :)
2018-12-11 18:10:49 <gdanko> I am not using apkbuild as it is in golang.
2018-12-11 18:11:05 <gdanko> I am constructing the control.tar and removing end of tar headers
2018-12-11 18:11:12 <danieli> aha
2018-12-11 18:11:14 <gdanko> then constructing data.tar and hashing it
2018-12-11 18:11:24 <gdanko> combining the two
2018-12-11 18:11:33 <gdanko> and I can install the package and all
2018-12-11 18:11:39 <gdanko> but info is strange
2018-12-11 18:11:41 <gdanko> one sec
2018-12-11 18:12:04 <gdanko> https://pastebin.com/xbD0vHxk
2018-12-11 18:13:12 <gdanko> This is my .PKGINFO file: https://pastebin.com/w03Gira5
2018-12-11 18:14:11 <_ikke_> So what is strange?
2018-12-11 18:14:18 <gdanko> Another question, when building a redhat rpm you can specify ownership of files. I cannot seem to find a way to do that in alpine.
2018-12-11 18:14:29 <gdanko> In the first link, the depends are duplicated.
2018-12-11 18:14:41 <gdanko> L10-22
2018-12-11 18:15:13 <gdanko> L24-26, provides are duplicated
2018-12-11 18:15:40 <gdanko> maybe apkbuild has some magic that auto-detects dependencies. :)
2018-12-11 18:15:45 <_ikke_> gdanko: You can chown files in $PKGDIR (and making sure that the user/group are defined in the APKBUILD)
2018-12-11 18:15:52 <_ikke_> gdanko: yes, it does
2018-12-11 18:16:09 <gdanko> but
2018-12-11 18:16:24 <SpaceToast> "I am not using apkbuild as it is in golang."
2018-12-11 18:16:29 <gdanko> this is in Go, so that it can be used on any unix like OS
2018-12-11 18:16:39 <SpaceToast> I do not see why your package being written in go should stop you from using the proper package building toolkit
2018-12-11 18:17:06 <gdanko> 1) What if I want to use a non Alpine system to build the package?
2018-12-11 18:17:14 <danieli> you'll have to build against musl either way
2018-12-11 18:17:19 <gdanko> 2) Do not like executing system calls from my OS
2018-12-11 18:17:21 <SpaceToast> why would you build an apk-specific package outside of an apk ecosystem?
2018-12-11 18:17:27 <gdanko> Automation
2018-12-11 18:17:36 <SpaceToast> no but again
2018-12-11 18:17:40 <SpaceToast> apk packages are only relevant
2018-12-11 18:17:43 <SpaceToast> in apk ecosystems
2018-12-11 18:17:54 <gdanko> right
2018-12-11 18:17:56 <SpaceToast> as such if you're building an apk package for an apk ecosystem you might as well use an apk ecosystem to build it
2018-12-11 18:17:59 <_ikke_> SpaceToast: which is not necessarily alpinelinux
2018-12-11 18:18:11 <SpaceToast> _ikke_: sure, but we're talking about avoiding APKBUILD, not avoiding alpine specifically
2018-12-11 18:18:22 <gdanko> I understand what you are saying.
2018-12-11 18:18:37 <SpaceToast> gdanko: when you build an RPM, do you use the rpm building system, or do you throw tarballs together?
2018-12-11 18:18:45 <SpaceToast> when you build deb..
2018-12-11 18:18:49 <_ikke_> SpaceToast: fpm can build rpms
2018-12-11 18:18:55 <gdanko> There is an rpmbuild port for most platforms
2018-12-11 18:19:04 <gdanko> that I have used
2018-12-11 18:19:12 <SpaceToast> yes, and nothing is stopping you from building abuild on non-alpine systems
2018-12-11 18:19:21 <gdanko> but I cannot find an apkbuild for darwin or redhat
2018-12-11 18:19:30 <SpaceToast> you can build it yourself :)
2018-12-11 18:19:35 <SpaceToast> I'm not aware of any extranious dependencies
2018-12-11 18:19:37 <gdanko> ok let me check that
2018-12-11 18:19:43 <gdanko> where is the source?
2018-12-11 18:19:49 <gdanko> sorry, I am new to Alpine.
2018-12-11 18:19:55 <danieli> https://git.alpinelinux.org/cgit/abuild/
2018-12-11 18:19:55 <gdanko> This was put in my lap 2 days ago
2018-12-11 18:19:58 <SpaceToast> https://git.alpinelinux.org/cgit/abuild/
2018-12-11 18:20:08 <danieli> or https://github.com/alpinelinux/abuild
2018-12-11 18:20:44 <gdanko> checking homebrew first
2018-12-11 18:21:00 <gdanko> okay let me try to build it then build a homebrew package :)
2018-12-11 18:21:57 <_ikke_> out of curiosity, why do you want to build apk packages on mac os or rhel?
2018-12-11 18:22:08 <danieli> ^
2018-12-11 18:22:15 <danieli> i don't know of any non-alpine [derivatives] using apk
2018-12-11 18:22:28 <danieli> if you're targeting alpine, you'll have to build against musl libc either way
2018-12-11 18:22:44 <gdanko> the idea is this
2018-12-11 18:22:51 <danieli> and software with musl/alpine-specific patches
2018-12-11 18:23:24 <gdanko> I have a repo in github with specifications about a package (arch, version, release, etc) in yaml files
2018-12-11 18:24:04 <gdanko> I tell my command to build the package --target-type [rpm|apk|deb]
2018-12-11 18:24:35 <_ikke_> I would spin up docker containers to do the actual building then
2018-12-11 18:24:39 <gdanko> I have build scripts that i can specify just the version and release of say nginx
2018-12-11 18:24:42 <gdanko> yes!
2018-12-11 18:25:20 <gdanko> docker run --rm -it builder /usr/bin/build-nginx-rpm 1.14.1 el6.01
2018-12-11 18:25:43 <_ikke_> right, but for apk packages, you would use an alpine image for example
2018-12-11 18:25:44 <gdanko> this script compiles with my config settings, sets permissions, and uploads
2018-12-11 18:25:55 <gdanko> it then creates a sha file
2018-12-11 18:26:08 <gdanko> yep I have an rpm build image and alpine build image
2018-12-11 18:26:24 <gdanko> these artifacts are uploaded to a repository
2018-12-11 18:26:36 <SpaceToast> so... you don't even need to port abuild?
2018-12-11 18:26:41 <SpaceToast> your approach seems confusing to me
2018-12-11 18:27:16 <gdanko> the go based rpm build utility downloads the tarball and sha, verifies, unpacks, generates the spec/pkginfo file, handles pre/post install/deinstall/upgrade scripts
2018-12-11 18:27:33 <gdanko> builds the package and publishes to our internal repo
2018-12-11 18:27:38 <gdanko> yum/deb/apk
2018-12-11 18:27:44 <gdanko> watch
2018-12-11 18:31:19 <gdanko> https://pastebin.com/QMJHcbMw
2018-12-11 18:32:06 <_ikke_> So you are not building anything?
2018-12-11 18:32:27 <gdanko> when jenkins sees a new commit to the repo it fires off a build container to compile the new version, then it fires off a gbfpm container to build and publish
2018-12-11 18:32:35 <gdanko> two processes at the moment
2018-12-11 18:33:01 <_ikke_> is there a reason for that?
2018-12-11 18:33:17 <gdanko> for what?
2018-12-11 18:33:27 <_ikke_> seperate build + package step?
2018-12-11 18:33:33 <gdanko> time
2018-12-11 18:33:40 <TBB> I have a similar setup that I've built over the course of some 3-4 years now. My reason was simply that it was expected our team would be working for multiple customers with multiple base distros.
2018-12-11 18:33:41 <gdanko> It will be consolidated
2018-12-11 18:33:49 <gdanko> same here
2018-12-11 18:34:28 <gdanko> rpm was the first supported format but nfpm was pretty bad IMO
2018-12-11 18:34:37 <TBB> we were originally working with an rpm based distro, then some requirements popped up and Alpine started looking like a good alternative (and as it turned out, it was)
2018-12-11 18:34:51 <gdanko> yum remove left stuff scattered all over. symlinks were not processed properly.
2018-12-11 18:35:00 <gdanko> yeah same here
2018-12-11 18:35:25 <gdanko> how do you use oracle java with alpine? I saw a glibc package. Is it reliable?
2018-12-11 18:35:37 <gdanko> over here, the world revolves around Java unfortunately.
2018-12-11 18:36:33 <TBB> we have client software written in Java, but fortunately we can avoid Oracle's packaging of it
2018-12-11 18:37:16 <TBB> sure, that sometimes causes, let' say, interesting surprises, but for the most part we're fine with openjdk. we're switching to Qt pretty much completely tho.
2018-12-11 18:37:22 <gdanko> Because of the high profile work we are stuck with oracle. :(
2018-12-11 18:38:55 <TBB> understandable... can't always get to choose
2018-12-11 18:40:43 <gdanko> right
2018-12-11 18:41:59 <TBB> there were rumours last year that there were people at Oracle interested in doing the porting of Java 9 to Alpine
2018-12-11 18:46:46 <gdanko> [gdanko@SDGL141bb265b abuild]$ ./abuildreadlink: illegal option -- fusage: readlink [-n] [file ...]
2018-12-11 18:46:48 <gdanko> close
2018-12-11 18:53:21 <gdanko> okay success
2018-12-11 18:53:39 <gdanko> let me try to build a package now
2018-12-11 18:54:03 <gdanko> if this is the case I will build a homebrew package for abuild and an abuild rpm
2018-12-11 18:54:10 <gdanko> then I can do it in a more sane manner
2018-12-11 18:55:10 <gdanko> can I use pre-compiled binaries in an apkbuild file?
2018-12-11 18:55:18 <_ikke_> sure
2018-12-11 18:55:20 <gdanko> i.e. unpack my tarball
2018-12-11 18:55:22 <gdanko> ok looking
2018-12-11 18:55:26 <gdanko> this is going to be better :)
2018-12-11 18:55:49 <gdanko> mac's readlink sucks
2018-12-11 20:51:39 <mps> clandmeter: nbd build fails on armv7, you know that probably, adding --without-libnl solves build problem, is that solution ok for Alpine
2018-12-11 22:03:33 <thorkild> Anybody have an example of a package with an APKBUILD that depends on the source code of a different package? I'm trying to build a nginx module (for opentracing), but since it isn't part of nginx in any official way I thought it woudl be best to build it as part of a separate package. The code needs to be built within a checked out nginx source tree (like most nginx modules).
2018-12-11 22:04:09 <thorkild> I wonder if there is a smarter way than putting a direct downloadable reference to the nginx source code in $sources. It seems.. suboptimal.
2018-12-11 22:05:43 <SpaceToast> thorkild: https://git.alpinelinux.org/cgit/aports/tree/testing/nginx-naxsi here's an example of a external module as it is in the source right now
2018-12-11 22:05:54 <SpaceToast> so... looks like it does just that
2018-12-11 22:08:06 <thorkild> hmm, yes, I was looking at that, but it depends on !nginx, so it is a complete replacement. But, if I look at the nginx APKBUILD, it does the same thing. Sounds like it is the way to go, yes! (I'm too used to debian etc. which has custom patches etc)
2018-12-11 22:08:32 <thorkild> SpaceToast: thanks! That made me rethink and was very helpful :)
2018-12-11 22:08:54 <SpaceToast> personally, my approach would be to add all modules to the nginx packagebuild, build them all at once (assuming they don't conflict) and then throw them all into subpackages
2018-12-11 22:09:06 <SpaceToast> it'd result in a really big APKBUILD though
2018-12-11 22:09:11 <SpaceToast> ¯\_(ツ)_/¯
2018-12-11 22:09:22 <SpaceToast> (and is obviously not the way of doing things, as is in-tree)
2018-12-11 22:10:55 <thorkild> it is pretty big already, and yes, I don't like the idea of stuffing 3rd party code deps into the "proper" nginx module. Only thing now is to figure out which nginx version is correct for the alpine linux version I am trying to build on, but I can postpone figuring out that for a bit :)
2018-12-11 22:12:55 <thorkild> SpaceToast: I think I'm very wrong. When I look at the nginx it has an "add_module" feature that does reference third party code. Think it will be more correct to include it there
2018-12-11 22:13:27 <thorkild> maybe this is just a lot easier than I expected!
2018-12-11 23:51:30 <ddevault> update on the riscv64 port
2018-12-11 23:51:42 <ddevault> bootstrapping is pretty much done
2018-12-11 23:51:56 <ddevault> I'm fixing some bugs with the musl port before I do anything else
2018-12-11 23:52:27 <ddevault> once I have that done I need to figure out how to use an upstream kernel and build a proper install (as opposed to a chroot)
2018-12-11 23:52:45 <ddevault> then I'll put up a public package repo and it'll be ready for others to contribute, if anyone is interested
2018-12-11 23:53:08 <ddevault> a couple weekends of work and I should be able to have a buildbot as well
2018-12-11 23:53:38 <danieli> it's a shame upstream alpine has no riscv builders
2018-12-11 23:54:08 <ddevault> well, I hope that the port will become official
2018-12-11 23:54:14 <ddevault> and you're welcome to continue using my builder for as long as you like
2018-12-11 23:54:33 <ddevault> I already use builds.sr.ht to maintain my own alpine repo for x86_64
2018-12-11 23:55:16 <ddevault> hifive said if there's demand for my CI service, they'd be happy to send me more RISC-V machines to add
2018-12-11 23:55:26 <ddevault> I hope to use it to encourage RISC-V ports for many linux distros
2018-12-11 23:55:39 <ddevault> sifive*
2018-12-11 23:55:55 <danieli> it's a bit complicated with signing keys, our own build system, and all that
2018-12-11 23:56:03 <danieli> the port itself being upstreamed would be wonderful though
2018-12-11 23:56:47 <ddevault> well
2018-12-11 23:57:10 <ddevault> I'll be putting together some nice automation and I hope you'll consider it
2018-12-11 23:57:23 <danieli> easier said than done, but we'll see, it's not up to me at all
2018-12-11 23:57:46 <danieli> trusting a third party with signing keys is understandably a hard decision
2018-12-11 23:58:05 <ddevault> I've volunteered to be a first party before, offer still stands
2018-12-11 23:58:11 <ddevault> I care a lot about alpine and have invested a lot into it
2018-12-11 23:58:23 <danieli> ncopa should be back after this week :)
2018-12-11 23:58:45 <ddevault> guess I'll need something to show by then :)
2018-12-11 23:59:56 <danieli> hah, no worries
2018-12-12 00:00:05 <danieli> getting world to build is the ultimate goal
2018-12-12 00:05:45 <SpaceToast> ddevault: your CI is open sauced, right? :)
2018-12-12 00:05:50 <ddevault> yes
2018-12-12 00:05:54 <ddevault> https://git.sr.ht/~sircmpwn/builds.sr.ht
2018-12-12 00:06:13 <SpaceToast> ah it's python based!
2018-12-12 00:06:30 <SpaceToast> I'll take a look later, might be interesting in general :D
2018-12-12 00:07:03 <ddevault> postmarketOS is using it now to automate their package maintenance (based on alpine)
2018-12-12 00:07:17 <ddevault> they told me how to stylize the name once, but I can't remember
2018-12-12 00:07:56 <SpaceToast> based on their site, you seem to have gotten it right
2018-12-12 01:08:11 <KH405_TV> Anybody has any idea for my deluge issue ?
2018-12-12 01:11:35 <SpaceToast> you're likely to have better luck asking during EU daytime, as most devs are based in the EU
2018-12-12 01:21:30 <KH405_TV> Damn, alright :S
2018-12-12 01:21:37 <KH405_TV> Eu daytime is hard for me tough
2018-12-12 01:22:25 <SpaceToast> similarly, current time is pretty hard for EU devs ;)
2018-12-12 01:22:53 <p4Wv1qn095FW> probably just a problem around the switch from libressl to openssl
2018-12-12 01:23:11 <SpaceToast> that's what I said a while ago, I even recall that specific hazmat file being involved
2018-12-12 01:23:17 <SpaceToast> I don't recall the resolution to that though
2018-12-12 01:23:29 <p4Wv1qn095FW> probably needs recompiling
2018-12-12 01:23:44 <p4Wv1qn095FW> the underlying python c library wrapper
2018-12-12 01:24:07 <p4Wv1qn095FW> btw hooray for lifting the curse of silence for non-registered users \o/
2018-12-12 01:29:14 <KH405_TV> lol ^^
2018-12-12 01:29:34 <KH405_TV> Yeah, that's what SpaceToast told me last week, but I still can't figure to make it work
2018-12-12 01:29:46 <KH405_TV> If someone wanna help out, it'd be very appreciated
2018-12-12 01:31:39 <KH405_TV> <p4Wv1qn095FW> The source of the problem has been identified, but I can't fix it :S
2018-12-12 01:35:47 <p4Wv1qn095FW> did you rebuild the py-cryptography package?
2018-12-12 01:36:06 <p4Wv1qn095FW> is it at the latest version?
2018-12-12 01:36:10 <ddevault> I sent a patch up http://lists.alpinelinux.org/alpine-aports/5863.html
2018-12-12 01:37:03 <SpaceToast> hmm... I recall one of the issues (not this one specifically) being related to PSK functionality being missing though
2018-12-12 01:37:08 <p4Wv1qn095FW> ah, you might also want to try this patch iiuc
2018-12-12 01:37:17 <SpaceToast> so perhaps including psk is the right move
2018-12-12 01:37:44 <SpaceToast> but I've been intentionally avoiding talking too much because my memory isn't the best (I suspect a choice was made at some point) and I'm too lazy to dig through logs
2018-12-12 01:39:42 <KH405_TV> I'm kinda cofused with python, is it a package that I should update with Pip, or with apk update ?
2018-12-12 01:39:59 <p4Wv1qn095FW> depends on how you installed it
2018-12-12 01:39:59 <KH405_TV> Everything should be updated on the latest edge branch right now
2018-12-12 01:42:07 <KH405_TV> It is updated
2018-12-12 02:38:25 <KH405_TV> Any other idea?
2018-12-12 04:29:20 <KH405> I'm still stuck there :S
2018-12-12 07:00:57 <ollieparanoid[m]> installing iptables gives a "BAD signature" error on Alpine edge x86_64
2018-12-12 07:12:01 <ollieparanoid[m]> this doesn't seem to be on every mirror though, nl.alpinelinux.org works
2018-12-12 07:12:42 <jwh> use dl-cdn?
2018-12-12 07:57:38 <ollieparanoid[m]> yeah, I'm using that
2018-12-12 07:58:54 <_ikke_> ollieparanoid[m]: might be that someone reverted the package without bumping pkgrel
2018-12-12 07:59:16 <_ikke_> dl-cdn is then returning a cached version that doesn't match the index
2018-12-12 08:09:30 <clandmeter> yes it was and it should be fixed
2018-12-12 08:12:01 <clandmeter> a trick to solve cdn cache is using curl -X PURGE $url
2018-12-12 08:12:05 <clandmeter> fcolista, ^
2018-12-12 08:12:51 <fcolista> <algitbot> aports:master |Francesco Colista| main/iptables: bump pkgrel due to the commit reverts | http://dup.pw/aports/4d0ac720
2018-12-12 08:12:57 <fcolista> 45min ago..
2018-12-12 08:13:07 <fcolista> forgot to do that yesterday, sorry /0\
2018-12-12 08:13:33 <clandmeter> fcolista, you can also purge the cache.
2018-12-12 08:13:51 <clandmeter> or just bump pkgrel
2018-12-12 10:31:05 <andypost> what is a common practice to upgrade dependent packages? should it be the same PR or separate one https://github.com/alpinelinux/aports/pull/5814#issuecomment-446348741
2018-12-12 10:39:38 <clandmeter> andypost, if you want travis to be successful (i guess  you would) you should use the same PR
2018-12-12 10:40:15 <clandmeter> it will also make sure build will succeed on builders
2018-12-12 10:40:37 <clandmeter> if PR's are not applied in correct order it would fail.
2018-12-12 10:41:46 <clandmeter> ddevault, you build complete x86_64 world or only the packages you need?
2018-12-12 10:41:57 <andypost> clandmeter, I mean travis can't detect that ABI changed and tells "ok"
2018-12-12 10:42:20 <andypost> so it is easy to miss ABI change
2018-12-12 10:42:45 <clandmeter> ah ok now i get it.
2018-12-12 10:43:12 <clandmeter> i was thinking in reverse.
2018-12-12 10:43:49 <clandmeter> yes if abi changed of the pkg itself you need to find all packages depending on it and put them in same PR
2018-12-12 10:45:43 <andypost> clandmeter, so that means only manual way to detect abi changes for now
2018-12-12 10:46:37 <clandmeter> yes, the dev that pushes it should always check if libs have changed.
2018-12-12 10:59:16 <nmeum> clandmeter: any chance you could fix the tpaste.us https cert even though you don't use it yourself? ;)
2018-12-12 10:59:54 <clandmeter> _ikke_, did you find time to check?
2018-12-12 11:00:54 <_ikke_> Not yet :(
2018-12-12 11:01:25 <clandmeter> np
2018-12-12 11:01:28 <clandmeter> ill give a quick check
2018-12-12 11:02:37 <clandmeter> hmm
2018-12-12 11:02:43 <clandmeter> proxy didnt register in dns
2018-12-12 11:36:09 <clandmeter> nmeum, how about now?
2018-12-12 11:36:41 <_ikke_> validates here
2018-12-12 11:41:25 <nmeum> clandmeter: yep, works now. thanks!
2018-12-12 12:43:16 <ddevault> clandmeter: only the ones I need, and not from world. I use a frequently updated alpine repo to ship releases of my software to my fleet
2018-12-12 12:43:39 <clandmeter> ddevault, right
2018-12-12 12:43:46 <clandmeter> you are not using our build tools i guess
2018-12-12 12:43:58 <ddevault> no, but my setup isn't perfect anyway
2018-12-12 12:44:09 <ddevault> I intend to transition to some happy medium between my tools and alpine's upstream tools
2018-12-12 12:49:08 <clandmeter> ddevault, sr.ht is completely running on alpine?
2018-12-12 12:49:19 <ddevault> not completely
2018-12-12 12:49:24 <ddevault> but I'm working on migrating everything
2018-12-12 12:49:34 <clandmeter> impressive!
2018-12-12 12:49:55 <ddevault> builds.sr.ht master runs on arch, but the slaves are running on alpine
2018-12-12 12:50:07 <ddevault> dispatch.sr.ht, man.sr.ht, and lists.sr.ht run on arch
2018-12-12 12:50:10 <ddevault> ns1 & ns2 run on debian
2018-12-12 12:50:12 <ddevault> the rest is alpine
2018-12-12 12:50:28 <clandmeter> ive been looking over it a bit,, didnt really device into code yet.
2018-12-12 12:50:38 <clandmeter> dive*
2018-12-12 12:51:25 <ddevault> what do you think?
2018-12-12 12:52:49 <clandmeter> well i like the simplicity (as long it doesnt limit user experience)
2018-12-12 12:53:42 <ddevault> seems like a reasonable constraint
2018-12-12 12:53:57 <ddevault> right now it does limit user experience
2018-12-12 12:54:26 <clandmeter> yes, thats my first experiance. but im not really using it so i cant realy judge.
2018-12-12 13:01:22 <clandmeter> ddevault, the concept of a pull request is non existent?
2018-12-12 13:01:38 <ddevault> correct, this is the main way in which UX is limited
2018-12-12 13:01:49 <ddevault> we use git send-email and lists.sr.ht to fill that niche
2018-12-12 13:02:01 <ddevault> but the goal is to have a web UI, similar to pull requests, which uses send-email under the hood
2018-12-12 13:02:11 <ddevault> so that you can use that if you prefer the web or you can use emails if you prefer emails
2018-12-12 13:02:28 <clandmeter> understand
2018-12-12 13:03:20 <clandmeter> i guess this can be self hosted?
2018-12-12 13:03:59 <mps> ddevault: yesterday read your text about workflow using send-email. nice :)
2018-12-12 13:04:17 <ddevault> clandmeter: it can be, yeah: https://man.sr.ht/installation.md
2018-12-12 13:04:28 <ddevault> clandmeter: you can just slap my alpine repo in /etc/apk/repositories and apk add git.sr.ht
2018-12-12 13:04:36 <ddevault> mps: thanks!
2018-12-12 13:04:58 <clandmeter> heh nice :)
2018-12-12 13:05:51 <clandmeter> what is your experience using py for web based solutions?
2018-12-12 13:06:17 <mps> would be nice if it could be somehow 'integrated' to Alpine, IMHO
2018-12-12 13:06:27 <clandmeter> i remember pagure never really felt snappy.
2018-12-12 13:06:33 <ddevault> does sr.ht feel snappy to you?
2018-12-12 13:06:46 <ddevault> mps: integrated how? like upstream in world?
2018-12-12 13:07:06 <clandmeter> it does, but i guess your customer base is limited atm?
2018-12-12 13:07:22 <ddevault> there are 5,499 users
2018-12-12 13:07:31 <ddevault> python is pretty light if you know what you're doing
2018-12-12 13:07:48 <mps> didn't looked deeply in it, but superficially it is something which could be considered
2018-12-12 13:07:56 <clandmeter> ah i didnt know you had that many already.
2018-12-12 13:08:09 <ddevault> mps: well, that may be possible but there are several drawbacks
2018-12-12 13:08:25 <ddevault> first, sr.ht is updating too fast right now for it to be practical
2018-12-12 13:08:51 <ddevault> second, I'd still have to run my own alpine repos so that I can close the loop between pushing updates to the repo and getting them running on my servers, without having to have someone from alpine sign-off in between
2018-12-12 13:09:21 <mps> well, didn't wanted to say that it should be integrated ASAP, just sounds like a idea to consider
2018-12-12 13:09:29 <ddevault> sure
2018-12-12 13:10:02 <clandmeter> we are looking into changing our build system.
2018-12-12 13:10:36 <clandmeter> i should check sr.ht a bit more deeper.
2018-12-12 13:11:00 <ddevault> great, let me know if you have any questions
2018-12-12 13:11:08 <ddevault> I did a writeup on bugs.alpinelinux.org a while ago
2018-12-12 13:11:20 <ddevault> https://bugs.alpinelinux.org/issues/9134
2018-12-12 13:11:31 <mps> i will look at it just to 'learn' something interesting, at least
2018-12-12 13:11:41 <clandmeter> and you are using alpine as a base, thats really attractive :)
2018-12-12 13:11:51 <ddevault> the build log linked there is out of date, but here's a fresher link https://builds.sr.ht/~sircmpwn/job/15415
2018-12-12 13:12:52 <clandmeter> yes i remember you mention it a few times, but ive been really busy with other infra things.
2018-12-12 13:13:20 <ddevault> I get it, that wasn't a slight on you
2018-12-12 13:13:24 <clandmeter> and ncopa is the one with more deeper knowledge of how are done on the builders
2018-12-12 13:13:51 <danieli> there are only around a handful of people with access to the alpine builders too
2018-12-12 13:13:54 <SpaceToast> moin \o
2018-12-12 13:14:07 <clandmeter> danieli, you can setup your own builder  :)
2018-12-12 13:14:14 <clandmeter> you would have lots of access all the time
2018-12-12 13:14:37 <danieli> not quite the same as a production system, i don't have a need for a fully automated builder system
2018-12-12 13:14:56 <SpaceToast> ddevault: I noticed (while looking around yday) that man.sr.ht is markdown-focused; how much work would it be to add asciidoc (either the syntax, or the asciidoctor implementation)? (asking noticing you offered to answer questions :) )
2018-12-12 13:15:12 <clandmeter> SpaceToast, that was also on my list to ask ;-)
2018-12-12 13:15:15 <ddevault> it might not be a whole lot of work, but it's not something I'm interested in adding right now
2018-12-12 13:15:17 <SpaceToast> ^^
2018-12-12 13:15:23 <danieli> https://github.com/asciidoc/asciidoc-py3 p[robably not too much work
2018-12-12 13:15:27 <danieli> s/[//
2018-12-12 13:15:27 <alpine-meetbot> danieli meant to say: https://github.com/asciidoc/asciidoc-py3 probably not too much work
2018-12-12 13:15:48 <SpaceToast> alright, once I'm done with my (~~relatively long todo list~~) the docs I might try and look into it
2018-12-12 13:16:07 <ddevault> before I was shilling sr.ht to alpine I was shilling scdoc to alpine :)
2018-12-12 13:16:23 <SpaceToast> yeah I saw mention of it; have not tried yet
2018-12-12 13:16:30 <SpaceToast> mostly because I'm very comfortable with asciidoctor
2018-12-12 13:16:36 <ddevault> but if markdown isn't sufficient for your needs, I recommend using builds.sr.ht to run whatever documentation generator you want, then pushing it to the sr.ht equivalent of github pages (as of yet not written)
2018-12-12 13:16:52 <SpaceToast> ah, that makes sense - how are you planning to set that up?
2018-12-12 13:16:57 <SpaceToast> (more like gitlab, or more like github?)
2018-12-12 13:17:10 <ddevault> rsync
2018-12-12 13:17:23 <SpaceToast> aha, so secrets in CI conf
2018-12-12 13:17:33 <ddevault> builds.sr.ht already supports secrets
2018-12-12 13:17:38 <SpaceToast> yup :)
2018-12-12 13:17:46 <ddevault> you add secrets on the web UI and get a UUID, which you put in your build manifest
2018-12-12 13:17:52 <ddevault> it only populates the actual secret for authorized builds
2018-12-12 13:18:11 <SpaceToast> ok, that sounds reasonable once pages.sr.ht is build
2018-12-12 13:18:18 <ddevault> but I intend to automatically authorize your builds with your sr.ht account so stuff like pages.sr.ht pushes will Just Werk
2018-12-12 13:18:21 <SpaceToast> s/build/built/
2018-12-12 13:18:21 <alpine-meetbot> SpaceToast meant to say: ok, that sounds reasonable once pages.sr.ht is built
2018-12-12 13:21:56 <clandmeter> when i have some free time i would like to look into building a pkg in a complete isolated environment. something like kvm with a trimmed down kernel.
2018-12-12 13:22:39 <ddevault> if you paste this into builds.sr.ht/submit that exact environment will be booted up for you https://sr.ht/pB9q.txt
2018-12-12 13:23:49 <clandmeter> which kind of virt does it use?
2018-12-12 13:23:52 <ddevault> kvm
2018-12-12 13:23:58 <clandmeter> :)
2018-12-12 13:25:10 <clandmeter> how would i set arch?
2018-12-12 13:25:56 <ddevault> arch: aarch64
2018-12-12 13:25:59 <ddevault> but it wouldn't work
2018-12-12 13:26:01 <ddevault> multiarch is a WIP
2018-12-12 13:26:36 <ddevault> you might be able to get the debian/stretch image to boot arm64
2018-12-12 13:27:05 <clandmeter> i guess you mean multiarch as in different arch per job?
2018-12-12 13:29:21 <ddevault> aye
2018-12-12 13:29:53 <ddevault> I'm working on a mix of software emulation (qemu) and actual builders running different arches
2018-12-12 13:31:57 <clandmeter> ddevault, how fast does it boot to execution?
2018-12-12 13:32:21 <ddevault> within a couple of seconds
2018-12-12 13:36:26 <clandmeter> this is the source of the images https://git.sr.ht/~sircmpwn/builds.sr.ht/tree/master/images/alpine/genimg
2018-12-12 13:36:35 <clandmeter> *image
2018-12-12 13:36:35 <ddevault> correct
2018-12-12 13:37:06 <clandmeter> its just a vanilla alpine image :)
2018-12-12 13:37:14 <clandmeter> still only few seconds :)
2018-12-12 13:37:52 <ddevault> yes
2018-12-12 13:37:57 <ddevault> bbiab
2018-12-12 13:37:59 <clandmeter> i do miss the log/blame features
2018-12-12 13:38:10 <ddevault> feel free to keep sending questions, I'll see them
2018-12-12 13:38:56 <clandmeter> you really did an amazing job, ill be sure to poke ncopa a bit :)
2018-12-12 13:40:24 <clandmeter> i wonder if we could ditch openrc and use something like linux-kvm. that should boot it up even faster.
2018-12-12 13:52:14 <AinNero> ddevault: nitpick: i had shells error out on [ * == * ], its single '=' in posix
2018-12-12 13:54:13 <ddevault> thanks clandmeter, I appreciate it
2018-12-12 13:54:19 <ddevault> AinNero: good nitpick
2018-12-12 13:54:49 <ddevault> AinNero: I'm embarassed to have this ticket in my backlog https://todo.sr.ht/~sircmpwn/builds.sr.ht/95
2018-12-12 13:55:23 <AinNero> 
ACTION judges

2018-12-12 13:55:42 <ddevault> would it make you feel better if I told you I was working on a new strictly POSIX shell with a buddy
2018-12-12 13:55:49 <ddevault> more POSIX even than dash
2018-12-12 13:56:25 <clandmeter> dont take away my non posix goodies! :)
2018-12-12 13:56:31 <AinNero> i think there are enough compliant shells, i'd prefer on making scripts compliant
2018-12-12 13:56:44 <ddevault> tbh I disagree
2018-12-12 13:56:55 <ddevault> it's easier to make scripts complaint when your shell gets pissed when you aren't
2018-12-12 13:57:03 <ddevault> and all of the POSIX shells leave a lot to be desired imo
2018-12-12 13:57:11 <ddevault> none of them are really strict on POSIX compliance
2018-12-12 13:57:11 <AinNero> just pick the right shell then :D
2018-12-12 13:57:16 <ddevault> and none of them have a comfortable interactive shell
2018-12-12 13:57:21 <ddevault> and their code all sucks
2018-12-12 13:57:30 <ddevault> https://git.sr.ht/~emersion/mrsh
2018-12-12 13:57:48 <AinNero> comfortable interactive shell is difficult inside of posix specs
2018-12-12 13:58:16 <ddevault> I don't consider POSIX's specifications for the interactive shell to be important
2018-12-12 13:58:22 <ddevault> at some point I'm going to ask the austin group to remove them from the spec
2018-12-12 13:58:29 <AinNero> you are aware that im Nathan?
2018-12-12 13:58:37 <AinNero> s/im/was/
2018-12-12 13:58:37 <alpine-meetbot> AinNero meant to say: you are aware that was Nathan?
2018-12-12 13:58:47 <ddevault> but mrsh is built as a library, so you can make new shells on top of it and leave the mrsh shell to be as POSIXLY annoying as possible
2018-12-12 13:58:51 <ddevault> hmmm
2018-12-12 13:58:58 <ddevault> no, but I'm also not 100% sure who Nathan is
2018-12-12 13:59:13 <ddevault> oh, Nathan Cladwell?
2018-12-12 13:59:19 <AinNero> oh no
2018-12-12 13:59:23 <AinNero> but im fine with the Situation
2018-12-12 13:59:43 <ddevault> huh.
2018-12-12 14:01:33 <SpaceToast> having a true_posix_shell:tm: sounds interesting (if at least for development and /bin/sh)
2018-12-12 14:01:46 <ddevault> clandmeter: https://todo.sr.ht/~sircmpwn/git.sr.ht/156 https://todo.sr.ht/~sircmpwn/git.sr.ht/157
2018-12-12 14:01:49 <SpaceToast> but I tend to use zsh for interactive usage (and most scripts that don't need to run in constrained environments)
2018-12-12 14:01:57 <ddevault> I use fish but I hate it
2018-12-12 14:02:05 <danieli> how exactly are you interfacing with git, by the way?
2018-12-12 14:02:12 <ddevault> pygit2, which is based on libgit2
2018-12-12 14:02:14 <danieli> implementing it, or wrapping `git` in CLI?
2018-12-12 14:02:15 <danieli> ah nice
2018-12-12 14:02:38 <ddevault> there are some performance issues I need to sort out
2018-12-12 14:02:41 <danieli> i've seen some terrible solutions, for instance gitea, which literally wraps `git` on the command line
2018-12-12 14:02:45 <danieli> do you use asyncio heavily?
2018-12-12 14:02:49 <ddevault> not heavily
2018-12-12 14:02:52 <ddevault> but I do use it in some places
2018-12-12 14:03:04 <ddevault> there are also some performance issues with pygit2 that I need to address
2018-12-12 14:03:09 <SpaceToast> I have some erm... gripes with fish
2018-12-12 14:03:10 <danieli> good to know, I might have a deep dive into the source and help out, I'm pretty good with profiling
2018-12-12 14:03:19 <ddevault> would be appreciated
2018-12-12 14:03:23 <SpaceToast> (it basically lets you inject things into otherwise running shells in a bad way)
2018-12-12 14:03:24 <ddevault> just put the linux kernel in a repo and use the interface
2018-12-12 14:03:32 <ddevault> it'll quickly become obvious what's slow (git log is the worst)
2018-12-12 14:03:44 <danieli> of course.. considered lazy loading and/or pagination?
2018-12-12 14:03:53 <ddevault> I do both
2018-12-12 14:03:55 <ddevault> and caching!
2018-12-12 14:03:56 <SpaceToast> and completely dropping any semblance of posix compant hasn't helped it, imo (since you end up with awkwardly lacking features; I forget the specifics because it's been a while though)
2018-12-12 14:04:01 <danieli> neat, redis or memcached?
2018-12-12 14:04:03 <ddevault> redis
2018-12-12 14:04:19 <danieli> hm, perhaps you have a freenode channel I could join instead of polluting this channel?
2018-12-12 14:04:23 <ddevault> #sr.ht
2018-12-12 14:04:37 <clandmeter> you cache each commit?
2018-12-12 14:05:02 <danieli> okay, brb
2018-12-12 14:05:03 <ddevault> danieli is right, let's talk about git.sr.ht in #sr.ht for topics that don't pertrain to alpine
2018-12-12 14:05:10 <danieli> :)
2018-12-12 14:30:42 <nmeum> 2
2018-12-12 14:30:46 <nmeum> oops
2018-12-12 14:38:58 <ddevault> is there a page anywhere which tracks the list of initiative like "add check to everything" and "split -openrc into subpackages"
2018-12-12 14:39:23 <_ikke_> If anything, redmine
2018-12-12 14:39:54 <ddevault> gotcha
2018-12-12 16:09:02 <Guest48495> Hi all, trying to use py-usb in an Alpine Docker Container and keep getting seg faults. Is this the right place to ask about this?
2018-12-12 16:10:48 <Guest48495> This is with python 2.7 and on an arm based docker running with qemu on an x86_64 host
2018-12-12 16:18:34 <gdanko> Does anyone happen to have an example APKBUILD file where you are using precompiled binaries and copying them versus building from source?
2018-12-12 16:20:10 <_ikke_> gdanko: isn't that just a matter of putting them in the right place in package()?
2018-12-12 16:21:20 <danieli> yeah, if you just want to package up some prebuilt binaries, you can make build() a noop and just do the magic (install/cp/chmod/chown/whatever) in package()
2018-12-12 16:22:17 <_ikke_> I think you can just leave out build
2018-12-12 16:22:33 <danieli> oh yeah, true
2018-12-12 16:22:48 <danieli> probs a noop by default, that one
2018-12-12 16:23:42 <SpaceToast> yup, by default it's just a :
2018-12-12 19:20:29 <jwh> install -m750 -o $pkgname -g $pkgname -D "$srcdir/$pkgname-v$pkgver.linux-musl-amd64/$pkgname" "$pkgdir"/usr/sbin/$pkgname
2018-12-12 19:20:32 <jwh> in package() :D
2018-12-12 19:20:37 <jwh> not unreadable *at all*
2018-12-12 19:21:38 <SpaceToast> seems fine to me, you just have to know what all those install options do :)
2018-12-12 19:21:42 <SpaceToast> is kind of STRANGE though
2018-12-12 19:22:07 <jwh> it needs a case so I can use $arch also
2018-12-12 19:22:49 <jwh> 
ACTION shakes fist at people using x86_64

2018-12-12 19:32:58 <danieli> alpine builders have super large passwd and group files
2018-12-12 19:33:07 <danieli> abuild adds them during the build process but doesn't clean up after itself
2018-12-12 19:34:36 <_ikke_> danieli: Is that causing issues?
2018-12-12 19:34:54 <danieli> it is not, it just feels hacky
2018-12-12 19:34:58 <[[sroracle]]> i think if the users and groups were added inside of rootbld instead of outside it wouldn't be a problem
2018-12-12 19:35:23 <[[sroracle]]> overall though apk and abuild need a revamped permissions system
2018-12-12 19:35:36 <_ikke_> [[sroracle]]: I don't think rootbld is being used atm
2018-12-12 19:35:38 <[[sroracle]]> adduser/addgroup in .pre-install is also hacky
2018-12-12 19:35:50 <danieli> [[sroracle]]: you're the one working on abuildd, right?
2018-12-12 19:35:53 <[[sroracle]]> yeah
2018-12-12 19:36:03 <danieli> mm, i had a look at the repo
2018-12-12 19:36:06 <[[sroracle]]> it's being based on rootbld
2018-12-12 19:36:08 <_ikke_> [[sroracle]]: abuild is warning for that already
2018-12-12 19:36:47 <[[sroracle]]> _ikke_: how else is it currently possible to add new users and groups with apk?
2018-12-12 19:37:13 <_ikke_> [[sroracle]]: you can define them in your APKBUILD
2018-12-12 19:37:23 <danieli> yes, pkguser and pkggroup iirc
2018-12-12 19:37:32 <[[sroracle]]> those add them to the system on which the build occurs
2018-12-12 19:37:42 <[[sroracle]]> but it doesn't get transferred to the apk file as far as i know
2018-12-12 19:37:46 <danieli> they do indeed, you have to use .post-install for that iirc
2018-12-12 19:37:50 <[[sroracle]]> right
2018-12-12 19:37:55 <[[sroracle]]> which is what i'm saying :P
2018-12-12 19:38:05 <[[sroracle]]> .PKGINFO should probably take care of this instead
2018-12-12 19:38:06 <danieli> it feels like an ugly solution to be honest
2018-12-12 19:38:30 <danieli> yes, it'd be neat if it kept a record of the file permissions and applied it during install rather than during packaging
2018-12-12 19:38:49 <[[sroracle]]> that is the most ideal solution
2018-12-12 19:39:12 <[[sroracle]]> i was also looking at replacing fakeroot for rootpkg with something that records permissions in such a way
2018-12-12 19:39:14 <_ikke_> danieli: doesn't tar take care of that?
2018-12-12 19:40:00 <danieli> you cannot chmod to a user/group that doesn't exist, so many packages use predefined uid/gids (that can be prone to fault)
2018-12-12 19:40:01 <_ikke_> Ok, it's chmod/chown/chgrp that abuild warns for
2018-12-12 19:40:01 <[[sroracle]]> it does but if new users/groups were to be more tightly integrated with apk it'd probably be better to also integrate file ownership as well
2018-12-12 19:40:09 <danieli> and the actual user/group is added on .post-install
2018-12-12 19:40:30 <_ikke_> yes
2018-12-12 19:40:44 <_ikke_> not on pre-install>
2018-12-12 19:40:46 <_ikke_> ?
2018-12-12 19:41:15 <danieli> er, per-install, my bad
2018-12-12 19:41:18 <danieli> s/per/pre
2018-12-12 19:41:18 <alpine-meetbot> danieli meant to say: er, pre-install, my bad
2018-12-12 19:42:30 <danieli> prime example: `adduser -S -D -h /var/lib/gitea -s /bin/ash -G www-data -g gitea gitea 2>/dev/null`
2018-12-12 19:42:37 <danieli> this isn't very pretty
2018-12-12 19:43:03 <[[sroracle]]> yeah
2018-12-12 19:44:51 <[[sroracle]]> ideally pkgusers / pkggroups should add something to the .PKGINFO and then apk would create the groups on pre-install automatically
2018-12-12 19:45:40 <danieli> yup, and that wouldn't break everything either
2018-12-12 19:45:41 <[[sroracle]]> this would perhaps require a change in the syntax of pkgusers/pkggroups to support the supplementary options though ($HOME, $SHELL, etc.)
2018-12-12 19:46:00 <danieli> that is true, that would be an issue
2018-12-12 19:46:55 <ollieparanoid[m]> clandmeter, fcolista, ikke: thanks for explaining and for fixing it
2018-12-12 19:47:31 <jwh> what about sensbile defaults? $HOME being /var/lib/$pkgname, or perhaps specify if its ephemeral and needs to be in tmpfs
2018-12-12 19:47:34 <jwh> etc
2018-12-12 19:47:43 <danieli> it can vary a lot
2018-12-12 19:48:37 <jwh> perhaps just define them for service users and adjust packages to suit
2018-12-12 19:51:28 <[[sroracle]]> there would probably be some sort of defaults
2018-12-12 19:51:35 <[[sroracle]]> but it needs to be overrideable
2018-12-12 19:51:36 <danieli> could probably do something along the lines of what gentoo does
2018-12-12 20:29:06 <danieli> hm, elixir fails on armhf
2018-12-12 20:29:14 <danieli> 13:18:25.365 [error] Can't load module ':lists' that resides in sticky dir
2018-12-12 20:29:53 <danieli> https://github.com/elixir-lang/elixir/issues/8183 seems relevant
2018-12-12 20:36:40 <danieli> seems like it isn't *really* failing? that's odd
2018-12-12 23:26:11 <thorkild> Does origin/master in aports map to alpine edge? (I built a few packages without thinking about it on master and I meant to use them on 3.8.1, so should I use that branch as starting point instead?
2018-12-12 23:30:28 <danieli> it does
2018-12-12 23:30:35 <danieli> edge is the development branch
2018-12-12 23:31:03 <danieli> either way, you don't need all of aports just to build a few packages
2018-12-12 23:31:13 <danieli> what matters is the host it's being built on
2018-12-12 23:33:15 <thorkild> right. It is being built on alpine 3.8, so then it should actually be right anway. I put it into aports simply so I can submit packages upstream (and abuild assumed it was running in a git repo). I followed the Creating_an_Alpine_package-wiki page, and I was really impressed by how smooth the packaing process was btw.
2018-12-12 23:33:52 <danieli> if you submit it, it'll land in edge, and in subsequent releases if it's moved to community
2018-12-12 23:40:35 <thorkild> How do people usually handle "living" with custom packages? I needed a few things wrapped and used in docker containers, so my current plan was to push my apkbuilds to our own git repos (just so my colleagues can recreate/update if I get hit a bus or something), and consider apks as artifacts and stick them on a webserver. Then I'll download and install them when building the docker images. Is ...
2018-12-12 23:40:41 <thorkild> ... this the common approach, or is there a more alpine linux-ish way of doing it?
2018-12-12 23:41:10 <danieli> often custom mirrors, or upstreaming them
2018-12-12 23:41:42 <danieli> when you build packages with abuild, it puts them in a directory in your home, which you can serve, bam, you have a mirror
2018-12-12 23:41:53 <thorkild> Hmm, good point. I could always make a custom apk repo and add that to the list of repos (until it, if it is accepted, gets included).
2018-12-12 23:42:08 <thorkild> danieli: indeed! I hadn't thought of that. Thanks. That will work very nicely
2018-12-12 23:42:32 <danieli> forresten, sen jobbing på en tirsdag, av alle ting? :)
2018-12-12 23:43:26 <thorkild> danieli: Jepp! Dette var alt for gøy og vanskelig å legge fra seg før det funker!
2018-12-12 23:44:04 <danieli> I definitely feel that one, I'm working on some Elixir stuff - I've been an Erlanger for some years now, but I'm starting to fall in love with Elixir
2018-12-12 23:44:43 <danieli> you're free to hit up #alpine-linux for questions/chat or #alpine-devel for Alpine-related development stuff
2018-12-12 23:45:47 <thorkild> thanks. I followed the docs and it mentioned this channel, but some of my questions are now so general that #alpine-linux is more appropriate.
2018-12-12 23:46:27 <danieli> as long as this channel isn't polluted to the point it disrupts active and on-topic conversations, no worries
2018-12-13 01:57:42 <ddevault> speaking of that aports openssl patch I linked yesterday
2018-12-13 01:57:44 <ddevault> http://lists.alpinelinux.org/alpine-aports/5863.html
2018-12-13 01:57:46 <ddevault> would be nice to see this land
2018-12-13 01:58:13 <ddevault> I can't run tests during CI when deploying sr.ht unless this is merged or I fork the package and put it in my repo
2018-12-13 02:10:21 <danieli> bah, is it still broken?
2018-12-13 02:15:38 <ddevault> yeah
2018-12-13 02:16:29 <ddevault> https://builds.sr.ht/~sircmpwn/job/14663#task-test-102
2018-12-13 08:00:01 <clandmeter> ddevault, done
2018-12-13 08:00:01 <alpine-meetbot> clandmeter: 2018-12-12 - 16:16:56 <_ikke_> tell clandmeter "Please register #alpine-docs"
2018-12-13 08:00:21 <clandmeter> huh?
2018-12-13 08:00:43 <clandmeter> ddevault, please next time use same commit  subject style  thx.
2018-12-13 08:33:10 <_ikke_> clandmeter: You asked us to remind you :P
2018-12-13 08:33:35 <clandmeter> i did?
2018-12-13 08:33:38 <_ikke_> yes
2018-12-13 08:33:46 <clandmeter> i dont think so :)
2018-12-13 08:33:58 <clandmeter> it was regarding ops not channel
2018-12-13 08:34:01 <_ikke_> "No time, please remind me later"
2018-12-13 08:34:09 <clandmeter> channel is already regged
2018-12-13 08:34:14 <_ikke_> ah ok
2018-12-13 08:34:19 <clandmeter> :p
2018-12-13 08:34:41 <clandmeter> but thx for the reminder ;-)
2018-12-13 08:35:05 <clandmeter> how did you set one?
2018-12-13 08:35:16 <_ikke_> . tell clandmeter ....
2018-12-13 08:35:52 <_ikke_> .tell clandmeter tada
2018-12-13 08:35:53 <alpine-meetbot> _ikke_: I'll pass that on when clandmeter is around.
2018-12-13 10:10:20 <clandmeter> Shiz, are you still working on rust on alpine?
2018-12-13 10:15:30 <AinNero> ^ ping strfry
2018-12-13 10:16:53 <strfry> AinNero: pong
2018-12-13 10:17:22 <strfry> AinNero: I'm not working on rust on alpine, but to bring rustup to musl-hosts in general ;P
2018-12-13 10:17:37 <AinNero> which is relevent here, i guess
2018-12-13 10:19:55 <clandmeter> rustup is to boostrap rust?
2018-12-13 10:22:11 <AinNero> yeah
2018-12-13 10:22:33 <strfry> mostly to install rust versions you don't get from your package manager
2018-12-13 10:22:43 <strfry> like beta/nightly channels, or cross-compile targets
2018-12-13 10:22:54 <clandmeter> i remember there was some project to make it easier to boostrap rust without rust?
2018-12-13 12:54:09 <ddevault> thanks clandmeter
2018-12-13 17:02:11 <jwh> hm....
2018-12-13 17:02:12 <jwh> [  325.137686] DVB: Unable to find symbol stb0899_attach()
2018-12-13 17:03:52 <jwh> stb0899                40960  -1
2018-12-13 17:03:55 <jwh> -1 huh
2018-12-13 17:04:45 <jwh> weird, fine after reboot
2018-12-13 21:52:14 <p4Wv1qn095FW> huh, i have a strange package that needs the architecture for which it is being compiled as a parameter to cmake... how do i do specify that in the APKBUILD file?
2018-12-13 21:53:58 <p4Wv1qn095FW> aah the CARCH variable helps
2018-12-13 21:55:34 <danieli> it does indeed
2018-12-13 22:32:04 <p4Wv1qn095FW> hrmpf it still complains about `error: ifunc is not supported on this target`, what is an ifunc in gcc, and why is it not enabled? sounds strange.
2018-12-13 22:38:04 <p4Wv1qn095FW> ah. found out about ifuncs
2018-12-13 23:11:32 <p4Wv1qn095FW> ah, gcc6 apparently works, only gcc8 does not.
2018-12-14 00:54:13 <jwh> hm, should probably revisit litespeed then
2018-12-14 00:54:17 <jwh> see whats up
2018-12-14 01:12:16 <jwh> hm, what am I missing....
2018-12-14 01:13:53 <jwh> judging from other packages, just add $pkgname-openrc to subpackages is enough to cause apk to install it as a dependency, or am I wrong?
2018-12-14 01:20:06 <SpaceToast> jwh: my understanding is that adding $pkgname-openrc just adds the subpackage - you can override dependencies on a per-subpackage basis though
2018-12-14 01:21:49 <jwh> hm, at least from my local repo if I do apk add $pkg, it isn't also installing -openrc, but on other packages from the main repo it does
2018-12-14 01:23:07 <jwh> just added -openrc to subpackages like the example I used (consul)
2018-12-14 01:36:41 <SpaceToast> it depends on the package
2018-12-14 01:36:55 <SpaceToast> identify a package where it does add them, and you may notice an extra line in package() (I think?)
2018-12-14 01:39:51 <[[sroracle]]> the way it works is you typically install the openrc related files (/etc/conf.d/* and /etc/init.d/*) inside of package(), then add $pkgname-openrc to $subpackages
2018-12-14 01:40:04 <[[sroracle]]> then abuild's default_openrc function will do the rest
2018-12-14 01:40:25 <danieli> that does make sense
2018-12-14 01:40:36 <[[sroracle]]> it includes an $install_if that will install $pkgname-openrc if $pkgname and openrc are installed
2018-12-14 01:44:58 <SpaceToast> ah, the default openrc() includes install_if, I don't think I noticed, ty
2018-12-14 01:45:28 <SpaceToast> APKBUILD ref doesn't mention the default openrc() right now, but at this point it might make sense to just wait until I get to that point in writing the official docs
2018-12-14 01:47:11 <[[sroracle]]> you're writing abuild docs?
2018-12-14 01:49:47 <danieli> SpaceToast: keep in mind that adélie has a wiki too, under CC-BY-SA-4.0 :)
2018-12-14 01:50:04 <SpaceToast> [[sroracle]]: I'm writing all the docs, for the entirety of alpine, atm
2018-12-14 01:50:21 <danieli> https://wiki.adelielinux.org/wiki/APK_internals
2018-12-14 01:50:45 <SpaceToast> danieli: well, when I get there, I'm going to be going through current sources and poking whoever works on apk nowadays :)
2018-12-14 01:50:49 <SpaceToast> that's still a distance off
2018-12-14 01:50:56 <danieli> no worries, just a heads up
2018-12-14 01:51:09 <SpaceToast> ^^
2018-12-14 01:51:42 <[[sroracle]]> SpaceToast: very cool
2018-12-14 01:51:56 <SpaceToast> [[sroracle]]: if you wanna help out (or keep up) feel free to join #alpine-docs :)
2018-12-14 02:20:48 <leo-unglaub> shit, i lost my complete irc logs
2018-12-14 02:21:04 <leo-unglaub> is someone here who has some complete channel logs and could grep something for me?
2018-12-14 02:21:21 <danieli> you could try this https://dev.alpinelinux.org/irclogs/
2018-12-14 02:21:25 <danieli> open the right date and ctrl+f
2018-12-14 02:22:09 <leo-unglaub> danieli, i have no idea when i asked that question
2018-12-14 02:22:10 <leo-unglaub> hehehehe
2018-12-14 02:22:22 <danieli> well, shit... I'm on Alpine's The Lounge right now
2018-12-14 02:22:35 <danieli> and I don't have access to the container that is dev.a.o
2018-12-14 02:24:51 <leo-unglaub> hmm, i have an idea
2018-12-14 02:25:11 <leo-unglaub> i download them all an grep them. i think i have a script for that somewhere in my home dir ;)\
2018-12-14 02:34:09 <jwh> ahhh
2018-12-14 02:34:11 <jwh> thanks [[sroracle]]
2018-12-14 02:34:21 <jwh> so I need to figure out why its not picking the files up
2018-12-14 02:35:33 <jwh> same as one that works...
2018-12-14 02:35:33 <jwh>         install -Dm755 "$srcdir"/$pkgname.initd \
2018-12-14 02:35:34 <jwh>                 "$pkgdir"/etc/init.d/$pkgname || return 1
2018-12-14 02:35:36 <jwh> looks sane
2018-12-14 02:35:54 <danieli> the `|| return 1` part is obsolete now afaik
2018-12-14 02:36:08 <danieli> but yeah, looks sane to me
2018-12-14 02:36:11 <SpaceToast> jwh: that's in package(), right?
2018-12-14 02:36:17 <jwh> yeah
2018-12-14 02:37:47 <jwh> APKBUILD in question is testing/litespeed
2018-12-14 02:38:16 <SpaceToast> and, to be sure, you have $pkgname-openrc in subpackages and no openrc() defined, right?
2018-12-14 02:38:25 <jwh> correct
2018-12-14 02:38:34 <jwh> cartwheel:~/aports/testing/litespeed$ grep -i openrc APKBUILD
2018-12-14 02:38:35 <jwh> subpackages="$pkgname-openrc $pkgname-snmp::noarch"
2018-12-14 02:38:40 <SpaceToast> very stange
2018-12-14 02:38:48 <SpaceToast> I might poke at it later, if I squeeze it in
2018-12-14 02:38:54 <jwh> :D
2018-12-14 02:39:24 <jwh> I only added it coz abuild warned about it, I was actually investigating something else... a whole bunch of stuff just doesn't work
2018-12-14 02:39:36 <jwh> but it seemed like a quick win to fix that
2018-12-14 02:39:58 <SpaceToast> wait till you look at alpine-baselayout and alpine-conf ;)
2018-12-14 02:40:38 <jwh> heh, well this package is kinda hacky anyway, hm
2018-12-14 02:45:08 <[[sroracle]]> jwh: did you bump pkgrel? do you have your local repository in /etc/apk/repositories?
2018-12-14 02:45:14 <jwh> yup, yup
2018-12-14 02:45:20 <jwh> even nuked packages/* just in case
2018-12-14 02:45:27 <jwh> I'm sure
2018-12-14 02:45:34 <[[sroracle]]> apk policy lightspeed indicates it's being installed from your local repo?
2018-12-14 02:45:47 <jwh> well theres a version bump as well, yup
2018-12-14 02:46:36 <[[sroracle]]> very odd
2018-12-14 02:47:08 <jwh> does openrc() check for specific naming?
2018-12-14 02:47:13 <jwh> I wonder...
2018-12-14 02:47:17 <[[sroracle]]> naming of?
2018-12-14 02:47:28 <jwh> files installed to init.d
2018-12-14 02:47:51 <jwh> theres no conf.d, but surely init.d is enough to trigger -openrc subpackage?
2018-12-14 02:48:31 <SpaceToast> jwh: vim /usr/bin/abuild -> :1425
2018-12-14 02:48:40 <[[sroracle]]> it should be. it basically just looks to see if $pkgdir/etc/init.d or conf.d exists and moves them
2018-12-14 02:50:33 <jwh> huh, who knows
2018-12-14 02:50:58 <jwh> because it *creates* the -openrc package, it just doesn't get installed as a dependency
2018-12-14 02:52:54 <jwh> since it works for packages in the official repo I'm gonna blame something local
2018-12-14 02:54:44 <SpaceToast> do you have openrc in world?
2018-12-14 02:55:05 <jwh> I'd hope so :P
2018-12-14 02:55:20 <SpaceToast> that's the main thing I can think of
2018-12-14 02:55:26 <SpaceToast> since the install_if is for openrc *and* the main package
2018-12-14 02:55:36 <jwh> hm
2018-12-14 02:56:00 <jwh> hang on
2018-12-14 02:56:13 <jwh> I think I may look foolish very shortly
2018-12-14 02:56:47 <jwh> yeah I'm just gonna go sit over in the dunce corner
2018-12-14 02:57:51 <jwh> sorry, I suck, thanks anyway
2018-12-14 02:57:59 <[[sroracle]]> happens to the best of us
2018-12-14 02:58:07 <[[sroracle]]> did you not have openrc installed?
2018-12-14 02:58:33 <jwh> I'd left -openrc installed from when I first tested it worked properly, didn't remove it for subsequent tests
2018-12-14 02:58:43 <[[sroracle]]> oof
2018-12-14 02:59:09 <jwh> could have sworn I did...
2018-12-14 02:59:22 <SpaceToast> ah, that'd do it :)
2018-12-14 02:59:31 <SpaceToast> and hey, don't worry, happens to literally everyone (I checked ;) )
2018-12-14 03:04:06 <jwh> heh
2018-12-14 03:07:08 <leo-unglaub> whats the correct way to execute something after an interface got up? post-up is the wrong one, right?
2018-12-14 03:07:56 <danieli> post means after/behind/subsequent to
2018-12-14 03:08:00 <SpaceToast> post-up is right
2018-12-14 03:08:21 <leo-unglaub> hmm, then i dont get why is is not executing it
2018-12-14 03:08:30 <danieli> +x?
2018-12-14 03:08:47 <SpaceToast> my wireguard configuration on $home_gateway uses post-up (among other things) and it runs fine
2018-12-14 03:08:50 <jwh> bleh, I have no idea why litespeed doesn't work properly at all ootb
2018-12-14 03:12:03 <jwh> would really help if the defaults in configure --help actually matched reality
2018-12-14 03:38:27 <jwh> hm, doesn't rootbld copy resolv.conf?
2018-12-14 03:40:22 <SpaceToast> I couldn't get rootbld working at all
2018-12-14 03:40:27 <SpaceToast> I didn't try very long or hard, to be fair
2018-12-14 03:41:03 <jwh> I've not really investigated but the error is typical of a missing resolv.conf in the chroot
2018-12-14 03:41:37 <jwh> it seems like something I should use so I start with a sane environment :D
2018-12-14 03:43:41 <[[sroracle]]> rootbld copies resolv.conf only if "net" is in $options
2018-12-14 03:44:08 <[[sroracle]]> the idea is most packages shouldn't need network to build since dependencies and fetching of sources is done outside of the buildroot
2018-12-14 03:44:43 <jwh> fair enough
2018-12-14 03:44:55 <jwh> screw this package anyway its a disaster
2018-12-14 03:44:57 <jwh> :D
2018-12-14 03:45:23 <jwh> upstream sucks
2018-12-14 06:58:39 <cw789> Hi all. I've one quick question. What is the state of LXC 3.0 on Alpine?
2018-12-14 07:32:34 <fabled> ncopa, i'm getting on firefox:
2018-12-14 07:32:36 <fabled> Sandbox: seccomp sandbox violation: pid 21344, tid 21344, syscall 16, args 36 21523 140729623829272 9259542123273814144 72 18374403900871474943.
2018-12-14 07:32:39 <fabled> Sandbox: seccomp sandbox violation: pid 21344, tid 21344, syscall 16, args 36 21523 140729623829640 9259542123273814144 72 18374403900871474943.
2018-12-14 07:32:42 <fabled> [Parent 21287, Gecko_IOThread] WARNING: pipe error (45): Connection reset by peer: file /home/buildozer/aports/testing/firefox/src/firefox-62.0.3/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 353
2018-12-14 07:32:45 <fabled> [Parent 21287, Gecko_IOThread] WARNING: pipe error: Broken pipe: file /home/buildozer/aports/testing/firefox/src/firefox-62.0.3/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 726
2018-12-14 07:32:48 <fabled> [Parent 21287, Gecko_IOThread] WARNING: pipe error: Broken pipe: file /home/buildozer/aports/testing/firefox/src/firefox-62.0.3/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 726
2018-12-14 07:32:51 <fabled> [Parent 21287, Gecko_IOThread] WARNING: pipe error: Broken pipe: file /home/buildozer/aports/testing/firefox/src/firefox-62.0.3/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 726
2018-12-14 07:32:54 <fabled> any ideas?
2018-12-14 07:40:35 <clandmeter> morning fabled, do you have time to check openjdk7 on armv7?
2018-12-14 07:53:52 <cw789> Hi all, one quick question. Anyone know the state of LXC 3.0 on Alpine?
2018-12-14 07:54:30 <clandmeter> non existent yet
2018-12-14 08:37:00 <clandmeter> im taking a look at lxc3
2018-12-14 08:39:07 <ncopa> Morning. fabled: i have no clue about Firefox issue
2018-12-14 08:42:31 <fabled> hum. seems sandbox is doing ioctl(TIOCGWINSZ)
2018-12-14 08:42:40 <fabled> could be musl or rust/firefox libs
2018-12-14 09:01:43 <fabled> ok. i have an idea
2018-12-14 09:02:01 <fabled> clandmeter, looked weird. maybe gcc-java issue still, need to look at it in more detail
2018-12-14 10:23:18 <ncopa> fabled: do you have any opinion on PSK support in openssl: https://github.com/alpinelinux/aports/pull/5829
2018-12-14 10:26:27 <clandmeter> i have a feeling abuild is slow than previously. at the stripping binaries part.
2018-12-14 10:29:18 <ncopa> thats quite possible
2018-12-14 10:30:25 <ncopa> are you sure its the stripping part and not the step after?
2018-12-14 10:30:28 <clandmeter> ah its not stripbin
2018-12-14 10:31:01 <clandmeter> the msg is confiusing like this
2018-12-14 10:31:43 <clandmeter> verbose options doesnt make it more clear
2018-12-14 10:33:55 <clandmeter> its prepare_metafiles
2018-12-14 10:35:41 <clandmeter> ah i already know what it is
2018-12-14 10:35:52 <clandmeter> stupid of me, i knew this already :|
2018-12-14 10:36:16 <clandmeter> a new aport will be slow to run git log cause there is no history for that path
2018-12-14 10:40:33 <ncopa> indeed
2018-12-14 10:40:51 <ncopa> i wonder if its better with `git rev-list`
2018-12-14 10:40:53 <ncopa> probably not
2018-12-14 10:40:55 <clandmeter> we could add a check, but i dont think its worth it.
2018-12-14 10:41:50 <clandmeter> so lxc will be split into 4 packages
2018-12-14 10:43:05 <clandmeter> ncopa, ill guess ill move those into main directly. we will have to do some tests locally.
2018-12-14 10:46:05 <ncopa> so no more lxc-2?
2018-12-14 10:49:15 <clandmeter> you want to keep two vcersions?
2018-12-14 10:51:28 <ncopa> no
2018-12-14 10:52:12 <clandmeter> they split py lua and templates out of main
2018-12-14 10:52:20 <clandmeter> and included pam
2018-12-14 10:52:44 <clandmeter> i guess the idea is to use osi
2018-12-14 11:07:38 <fabled> ncopa, no-PSK hit me earlier with py-cryptography: see also https://github.com/alpinelinux/aports/commit/abe1dc5988d12f5aca771605b109390f33ce7519#commitcomment-31279291
2018-12-14 11:08:02 <fabled> ncopa, i think libressl never had psk support. it's new openssl feature
2018-12-14 11:11:21 <clandmeter> reminds me, our init has libressl traces
2018-12-14 11:11:44 <lag> Is anyone here clear on which ARM specific architectures are currently supported?
2018-12-14 11:13:04 <clandmeter> armhf armv7( upcoming ) and aarch64 or is that not specific enough?
2018-12-14 11:14:30 <lag> clandmeter: I would like to know more about ARMv7 -- what's missing?
2018-12-14 11:14:43 <ncopa> fabled: i think libressl removed PSK support https://github.com/libressl-portable/portable/issues/450#issuecomment-437078113
2018-12-14 11:15:09 <lag> clandmeter: And what's the difference between ARMv7 and ARMHF -- Doesn't ARMv7 support ARMHF?
2018-12-14 11:15:18 <AinNero> lag: check the APKBUILD from the main/gcc package
2018-12-14 11:15:18 <clandmeter> lag, we have some aports that fail to build. not sure the exact list.
2018-12-14 11:15:19 <ncopa> armhf is armv6
2018-12-14 11:15:24 <fabled> ncopa, oh. hmm.
2018-12-14 11:15:38 <AinNero> lag: there is the _arch_configure= case switch for all supported arches
2018-12-14 11:15:38 <clandmeter> yes armv6 with hard float
2018-12-14 11:15:48 <lag> ncopa: That is not correct
2018-12-14 11:16:04 <ncopa> fabled: and i think TLS 1.3 needs PSK so i wonder if no-psk disabled tls 1.3
2018-12-14 11:16:05 <lag> ncopa: ARMv6 *can* have ARMHF support, but not always
2018-12-14 11:16:17 <lag> ncopa: ARMv7 always has ARMHF support
2018-12-14 11:16:26 <fabled> ncopa, i think psk is optional feature of tls 1.3
2018-12-14 11:16:41 <ncopa> lag: the alpine arch "armhf" is armv6 with hardware float
2018-12-14 11:17:08 <lag> ncopa: I see
2018-12-14 11:17:21 <lag> ncopa: clandmeter: So what will the ARMv7 port be called?
2018-12-14 11:17:30 <fabled> lag, armv7
2018-12-14 11:17:31 <clandmeter> armv7
2018-12-14 11:17:58 <clandmeter> if you are interested to help, we can send you a list of failed pkgs.
2018-12-14 11:17:59 <lag> Maybe armv6 & armv7 will be better, since both support ARMHF
2018-12-14 11:18:26 <ncopa> lag: you are right, but its too much pain to rename "armhf" to "armv6" at this point
2018-12-14 11:18:35 <lag> ncopa: Understood
2018-12-14 11:19:02 <lag> clandmeter: Not sure I have the bandwidth - but it won't hurt to look
2018-12-14 11:19:59 <clandmeter> ncopa, i guess we still want to keep the default alpine template in lxc main pkg?
2018-12-14 11:20:07 <lag> clandmeter: ncopa: Seeing as your ARMHF release works flawlessly (or at least appears to) on ARMv7 -- why don't you call that "works"?
2018-12-14 11:20:31 <lag> clandmeter: ncopa: Not a serious suggestion -- just trying to dig into the particulars of the issue
2018-12-14 11:21:03 <AinNero> ARMv7 has better performance, i guess due to float and thumb features
2018-12-14 11:21:39 <lag> AinNero: So you wish to build *specifically* for ARMv7 to utilise it's extended features -- makes sense
2018-12-14 11:21:42 <AinNero> the additional arm release for alpine was intended so people with newer device are able to make use of the additional features
2018-12-14 11:21:52 <AinNero> lag: https://github.com/alpinelinux/aports/blob/a29600791673c2a3ad5cdef65b129a8d8577cf0f/main/gcc/APKBUILD#L217
2018-12-14 11:22:08 <lag> AinNero: clandmeter: ncopa: Any idea on timelines?
2018-12-14 11:22:42 <clandmeter> ASAP, but not any sooner.
2018-12-14 11:22:50 <lag> clandmeter: :D
2018-12-14 11:23:07 <clandmeter> we are way behind on rel date
2018-12-14 11:23:11 <ncopa> lag: we are late already
2018-12-14 11:23:22 <ncopa> i think less than 2 weeks is realistic
2018-12-14 11:23:42 <ncopa> but i really really want it out before end of 2018
2018-12-14 11:24:04 <clandmeter> that just gave you another 3 days ;-)
2018-12-14 11:25:05 <clandmeter> hmm i wonder what to do with lxc. i have packages but no idea if it actually works :|
2018-12-14 11:25:28 <ncopa> clandmeter: from what i saw from upstream docs
2018-12-14 11:25:29 <clandmeter> i think ill have to spin it up on some virt
2018-12-14 11:25:50 <ncopa> the lxc-templaces are legacy
2018-12-14 11:26:02 <clandmeter> yes
2018-12-14 11:26:05 <ncopa> so i dont think we should ship the alpine template with main package anymore
2018-12-14 11:26:09 <lag> ncopa: clandmeter: AinNero: Thanks for the information -- that's good news
2018-12-14 11:26:21 <ncopa> lag: thanks for your patience
2018-12-14 11:26:28 <lag> ncopa: clandmeter: AinNero: BTW, who runs the Alpine Docker project?
2018-12-14 11:26:53 <ncopa> lag: depends on how you define "who runs"
2018-12-14 11:27:02 <AinNero> lag: that im present and vocal in this channel does not mean i'm someone of relevance here
2018-12-14 11:27:23 <AinNero> i just have opinions and some knowledge
2018-12-14 11:27:49 <lag> ncopa: Gliderlabs ?
2018-12-14 11:28:10 <lag> AinNero: That's okay -- you still deserve gratitude
2018-12-14 11:28:17 <ncopa> lag: Gliderlabs have sort of asked that someone else takes over maintenence
2018-12-14 11:28:27 <ncopa> so I guess its me who does it in practice
2018-12-14 11:28:51 <lag> ncopa: Ah, maybe you saw my 'Issue'?
2018-12-14 11:29:11 <AinNero> ncopa: Docker images? Because @work, im maintaining alpine base images myself, which we build from scratch
2018-12-14 11:29:23 <lag> ncopa: Although the issues do not look as though they have been triaged in quite some time
2018-12-14 11:29:36 <clandmeter> ncopa, i think you are right
2018-12-14 11:29:47 <clandmeter> it will also clash by name
2018-12-14 11:30:01 <clandmeter> so its proably better to rename them to lxc-templates-legacy
2018-12-14 11:33:16 <mps> lag: fyi, I run armv7 on two boxes for about month without problem, and yes, performance is better
2018-12-14 11:33:40 <clandmeter> ok i need to go. ill keep it in my local repo for now and test it later.
2018-12-14 11:33:44 <lag> mps: That's good news -- thank you for the information
2018-12-14 11:33:50 <fabled> finally. got backtrace on FF sandbox:
2018-12-14 11:33:51 <fabled> Thread 34 "Web Content" received signal SIGSEGV, Segmentation fault.
2018-12-14 11:33:52 <fabled> [Switching to LWP 30250]
2018-12-14 11:33:52 <fabled> 0x00007ff8c8b3bc0a in ?? () from /usr/lib/xorg/modules/dri/i965_dri.so
2018-12-14 11:33:52 <fabled> (gdb) where
2018-12-14 11:33:52 <fabled> #0  0x00007ff8c8b3bc0a in ?? () from /usr/lib/xorg/modules/dri/i965_dri.so
2018-12-14 11:33:53 <fabled> #1  0x00007ff8c8b3bfb7 in ?? () from /usr/lib/xorg/modules/dri/i965_dri.so
2018-12-14 11:33:55 <fabled> #2  0x00007ff8c8b42604 in ?? () from /usr/lib/xorg/modules/dri/i965_dri.so
2018-12-14 11:33:57 <mps> had to build some packages locally but nothing serious
2018-12-14 11:33:59 <fabled> #3  0x00007ff8c8b421d5 in ?? () from /usr/lib/xorg/modules/dri/i965_dri.so
2018-12-14 11:34:01 <fabled> #4  0x00007ff8e45e995b in start (p=<optimized out>) at src/thread/pthread_create.c:147
2018-12-14 11:34:03 <fabled> #5  0x00007ff8e45eb844 in __clone () at src/thread/x86_64/clone.s:21
2018-12-14 11:34:07 <fabled> sounds stack usage
2018-12-14 11:34:16 <lag> fabled: Woah!!  Pastebin dude!
2018-12-14 11:34:32 <fabled> hey, it's still under 10 lines
2018-12-14 11:34:35 <lag> ncopa: FYI: https://github.com/gliderlabs/docker-alpine/issues/463
2018-12-14 11:34:42 <lag> fabled: I think the unofficial rule is 5
2018-12-14 11:35:02 <lag> ncopa: I guess I will be able to close this after Christmas
2018-12-14 11:35:05 <_ikke_> freenode might even boot you if you send too much in a short time
2018-12-14 11:35:27 <lag> ncopa: Will you be the guy who will update the Docker Official Images library file?
2018-12-14 11:35:33 <clandmeter> as long fabled keeps fixing things he can paste whatever he wants from me ;-)
2018-12-14 11:35:49 <lag> clandmeter: :D
2018-12-14 11:35:58 <lag> ncopa: https://github.com/docker-library/official-images/blob/master/library/alpine
2018-12-14 11:42:22 <fabled> found it, 256k buffer on stack :roll:
2018-12-14 11:42:54 <ncopa> fabled: thats classic...
2018-12-14 11:42:57 <fabled> in mesa/src/util/disk_cache.c:deflate_and_write_to_disk()
2018-12-14 11:43:02 <fabled> ncopa, any suggestions how to fix
2018-12-14 11:43:23 <ncopa> problem is in mesa?
2018-12-14 11:43:35 <fabled> yes
2018-12-14 11:43:50 <fabled> mesa created threads; and some of them use the 256k buffer on stack
2018-12-14 11:44:50 <fabled> time to try -Wl,-z,stack-size=N ?
2018-12-14 11:44:58 <fabled> or just make the deflate buffer smaller
2018-12-14 11:45:15 <ncopa> i'd prefer either use buffer smaller or malloc the buffer
2018-12-14 11:45:46 <fabled> yeah. probably simplest to make it smaller
2018-12-14 11:46:02 <ncopa> looks like buffer shuold be 128 or 256k according comment
2018-12-14 11:46:10 <ncopa> * From the zlib docs:
2018-12-14 11:46:11 <ncopa>  *    "If the memory is available, buffers sizes on the order of 128K or 256K
2018-12-14 11:46:11 <ncopa>  *    bytes should be used."
2018-12-14 11:47:23 <fabled> it does not matter
2018-12-14 11:47:27 <fabled> it can be smaller
2018-12-14 11:47:40 <fabled> though, is suppose it achieves optimal performance
2018-12-14 11:48:10 <fabled> we could use 32k or 64k to start with
2018-12-14 11:48:37 <ncopa> im not sure 32k buffer on stack is a good idea
2018-12-14 11:49:09 <fabled> it really depends on the size of extraction is done
2018-12-14 11:49:58 <fabled> oh, it's used to create some cache stuff
2018-12-14 11:53:30 <ncopa> i think safest is to put it on heap
2018-12-14 11:53:31 <fabled> the cache files I have are small (under 1kB)
2018-12-14 11:53:33 <ncopa> malloc it
2018-12-14 11:54:07 <ncopa> something like this: http://tpaste.us/xp1r
2018-12-14 11:54:10 <fabled> 2kB buffer?
2018-12-14 11:54:41 <ncopa> 8k buffer should probably be ok too
2018-12-14 11:54:56 <fabled> based on my cache folder, i'd say 4kb is good
2018-12-14 11:55:05 <ncopa> aha
2018-12-14 11:55:27 <ncopa> 4k it is then :)
2018-12-14 11:55:32 <ncopa> i think it should be reported upstream
2018-12-14 11:55:36 <fabled> mileage may vary of course
2018-12-14 11:55:49 <fabled> nothing breaks. in any case
2018-12-14 11:55:57 <fabled> it affects only how many times the API call needs to be done
2018-12-14 11:55:58 <ncopa> i have no clue what the typical case is
2018-12-14 11:57:30 <fabled> can you check you cache item sizes? in ~/.cache/mesa_shader_cache
2018-12-14 11:58:35 <ncopa> http://tpaste.us/yPNn
2018-12-14 11:59:33 <fabled> ncopa, something like http://sprunge.us/A0Wg8O ?
2018-12-14 11:59:51 <fabled> yeah, 4k it is
2018-12-14 11:59:52 <ncopa> yup
2018-12-14 11:59:58 <fabled> i think most files are smaller.
2018-12-14 12:00:25 <ncopa> seems like they are less than 1000 bytes
2018-12-14 12:00:51 <fabled> i had few around 3kB
2018-12-14 12:01:34 <fabled> but even if the output is more, using 4kB buffer works. the 128k/256k is just what makes it go fastest if the file is huge (megabytes)
2018-12-14 12:01:53 <ncopa> understood
2018-12-14 12:02:54 <fabled> i push http://sprunge.us/rfU7cX ?
2018-12-14 12:03:11 <ncopa> yes please
2018-12-14 12:03:37 <ncopa> so i have 36 files of 1200 that are > 4096
2018-12-14 12:04:00 <ncopa> so 3%
2018-12-14 12:04:50 <ncopa> we should send the patch upstream
2018-12-14 12:04:50 <fabled> oh. we could bump it to 8k too
2018-12-14 12:05:04 <ncopa> 8k would be 100%
2018-12-14 12:05:22 <fabled> there's also some 10-200 bytes header before the deflated part
2018-12-14 12:06:57 <ncopa> i guess 4k vs 8k doesnt make any diff in practice for performance
2018-12-14 12:07:09 <ncopa> but would need to be benchmarked to know for sure
2018-12-14 12:07:28 <fabled> i'm pretty happy i got the issue found. it has been bugging me a long time
2018-12-14 12:07:34 <fabled> there's few websites that kept crashing on me
2018-12-14 12:07:56 <fabled> and i think also some media player did not work either at all. maybe same reason
2018-12-14 12:08:22 <ncopa> i would expect changing it from 256k to 4k (or 8k) increase perfromance due to fewer cache misses
2018-12-14 12:08:29 <ncopa> cpu cache misses
2018-12-14 12:10:47 <fabled> also possible. depends on the work load...
2018-12-14 13:02:43 <ncopa> fabled: do you think you cuold help us with openjdk7? apparently gcc6-java manages to build a broken bootstrap java
2018-12-14 13:03:12 <ncopa> i think its reproducible on x86_64 too
2018-12-14 13:03:15 <fabled> i can take a look at it soonish. not sure if today, but sometime next week should work out.
2018-12-14 13:03:22 <ncopa> ok
2018-12-14 14:09:28 <fabled> ncopa, seems openjdk7 builds on x86_64 (at least further than on arm)
2018-12-14 14:19:49 <fabled> ncopa, found one issue in java-gcj-compat; not sure if that is the cause of everything, but let's see
2018-12-14 16:39:16 <danieli> ncopa: does gcj break because of gcc 8?
2018-12-14 17:22:21 <ncopa> danieli: sort of
2018-12-14 17:22:37 <danieli> it's the only viable bootstrap path :(
2018-12-14 17:22:53 <ncopa> gcc 7 and later does not support gjc at all, so we needed to add gcc6
2018-12-14 17:23:22 <danieli> ah right, I forgot about that for a sec
2018-12-14 17:23:42 <danieli> correction then, does gcc 6 break because of gcc 8?
2018-12-14 17:24:45 <ncopa> not that i know
2018-12-14 18:56:27 <ncopa> hum, perl-io-socket-ssl test suite hangs
2018-12-14 18:56:38 <ncopa> i thought i fixed it, but apparently its sort of random
2018-12-14 20:26:28 <ollieparanoid[m]> clandmeter: in case nobody posted this yet, I think you've asked about that: https://github.com/thepowersgang/mrustc "In-progress alternative rust compiler. Capable of building a fully-working copy of rustc, but not yet suitable for everyday use."
2018-12-14 20:26:57 <SpaceToast> once that's stable that could be a great way to bootstrap rust :D
2018-12-14 20:57:27 <muhaha> Any idea why in alpine:3.8 does not work dig ANY google.com?    (-t ANY)
2018-12-14 21:01:52 <SpaceToast> muhaha: I get lots of answers - are you sure your resolv.conf is populated?
2018-12-14 21:03:55 <muhaha> docker run --rm -it alpine:3.8 sh -c "apk update > /dev/null && apk add --no-cache bind-tools > /dev/null && dig any +short google.com"  returns nothing
2018-12-14 21:04:33 <muhaha> well I am able to resolve: dig A +short google.com
2018-12-14 21:05:24 <muhaha> SpaceToast: ^
2018-12-14 21:05:34 <SpaceToast> do hold on, I'm trying to reproduce
2018-12-14 21:07:12 <SpaceToast> I think the issue is with any - since you're instructing your dns to do a whole extra bunch of stuff (e.g LDNS)
2018-12-14 21:07:29 <SpaceToast> if you remove +short you'll notice that you get some output
2018-12-14 21:07:50 <SpaceToast> note that this happens on other distros (that I've just tried it on) as well
2018-12-14 21:09:07 <SpaceToast> it mostly seems to depend on the dns server you're using - I got a response connecting directly to a local unbound instance
2018-12-14 21:09:12 <SpaceToast> (and nowhere else)
2018-12-14 21:10:40 <muhaha> well it works in my ubuntu:bionic .. there is systemd-resolved
2018-12-14 21:10:57 <SpaceToast> it doesn't work on my docker host (arch) with systemd-resolved
2018-12-14 21:11:11 <SpaceToast> nor on an ubuntu bionic baremetal system at work
2018-12-14 21:11:34 <SpaceToast> it does work on an ubuntu bionic baremetal system connected to local unbound directly though
2018-12-14 21:11:38 <SpaceToast> why exactly are you using -t ANY?
2018-12-14 21:13:51 <muhaha> it seems that results are pulled from cache...  dig ANY +short google.com @1.1.1.1 does not work for me for example, but dig ANY +short google.com does
2018-12-14 21:30:49 <jwh> ANY is discouraged
2018-12-14 22:02:43 <danieli> ^
2018-12-14 22:02:49 <danieli> most sane nameservers block it
2018-12-14 22:03:29 <jwh> it has no real use anyway since ANY won't return what you think it will
2018-12-14 22:03:41 <jwh> and its an amplification vector
2018-12-14 22:05:38 <danieli> muhaha: but yeah, what exactly are you expecting, and *how* does it not work?
2018-12-14 22:15:01 <muhaha> its ok.. I will need to enable zone transfer on my BIND and use -t axfr instead of -t any
2018-12-14 22:15:15 <danieli> you should not keep zone transfer enabled without a strict whitelist
2018-12-14 22:15:32 <muhaha> I am aware of this
2018-12-14 22:16:03 <danieli> just making sure
2018-12-15 02:01:59 <jwh> oh
2018-12-15 02:02:02 <jwh> how did I not spot this before
2018-12-15 02:02:04 <jwh> 
ACTION sighs

2018-12-15 02:02:33 <jwh> I'm not sure this package ever worked
2018-12-15 02:03:18 <SpaceToast> that is a commonly-known feeling in the computing industry
2018-12-15 02:03:56 <jwh> the paths the APKBUILD sets up are not the same as the default config, so it never could have worked
2018-12-15 02:03:59 <jwh> :D
2018-12-15 02:04:17 <jwh> heh
2018-12-15 02:05:42 <jwh> alright, well thats one thing fixed
2018-12-15 02:06:44 <jwh> https://github.com/joeholden/aports/commits/litespeed
2018-12-15 02:06:45 <jwh> o/
2018-12-15 02:06:56 <jwh> ugh, typo
2018-12-15 02:39:39 <ddevault> woot woot strange RISC-V musl bugs fixed
2018-12-15 02:39:43 <ddevault> \o\
2018-12-15 02:39:44 <ddevault> /o/
2018-12-15 02:39:59 <ddevault> porting packages now resumes
2018-12-15 02:40:50 <SpaceToast> ddevault: nice! So musl's officially fully ported to RISC-V now then? :D
2018-12-15 02:40:57 <ddevault> well, who knows if I'll hit more bugs
2018-12-15 02:41:08 <SpaceToast> all the bugs, I hope
2018-12-15 02:41:17 <SpaceToast> wouldn't be any good if some were to remain unsquashed :)
2018-12-15 02:41:17 <ddevault> but I submitted my patches upstream (where upstream = the group working on the riscv port, not yet musl upstream)
2018-12-15 02:41:29 <SpaceToast> ah, hope you guys can get it upstreamed soon :)
2018-12-15 02:41:30 <ddevault> https://github.com/riscv/riscv-musl/pull/3
2018-12-15 02:41:32 <SpaceToast> but \o/ for now
2018-12-15 02:41:39 <ddevault> musl wants to upstream it in the next release iirc
2018-12-15 02:41:51 <jwh> hmmm, speaking of... are there any tools packaged for bringing up new architectures?
2018-12-15 02:42:34 <ddevault> aports has scripts/bootstrap.sh, which has been indispensible in this effort
2018-12-15 02:42:55 <ddevault> I'll be putting together some improvements to it later and sending them along
2018-12-15 02:43:27 <SpaceToast> nice, thank you :)
2018-12-15 02:43:36 <jwh> cool
2018-12-15 02:44:25 <SpaceToast> ddevault: if you figure out any significant details regarding bootstrap.sh (including your changes when they come along) - would you mind throwing a writeup (just personal-note style stuff, so I have less source-code reading to do) over into #alpine-docs?
2018-12-15 02:44:40 <SpaceToast> bootstrapping new architectures is something I'd like to document in the developer handbook once I get to that
2018-12-15 02:44:42 <ddevault> bootstrap.sh basically works
2018-12-15 02:44:53 <ddevault> but I'd like to make some quality-of-life improvements
2018-12-15 02:45:03 <ddevault> e.g. not having to edit it to cross-compile another package with your sysroot
2018-12-15 02:45:05 <SpaceToast> well yes, but the idea is to give insight into the inner workings/details :)
2018-12-15 02:45:21 <ddevault> I'll also write up a blog post when all is said and done, I'd be happy to distill that into a wiki page too
2018-12-15 02:45:30 <ddevault> with fewer risc-v specific details, naturally
2018-12-15 02:45:39 <SpaceToast> oh just linking the blog post in the channel should be more than enough, thanks :)
2018-12-15 02:45:47 <ddevault> sure thing
2018-12-15 02:46:09 <SpaceToast> (assuming you write blogposts relatively similarly to how I do, but I read your (I think?) series on wlroots so I think that's a reasonable assumption to make)
2018-12-15 02:46:40 <ddevault> https://drewdevault.com
2018-12-15 02:46:44 <ddevault> you tell me
2018-12-15 02:47:02 <ddevault> with the weird musl bugs sorted, I think I can complete the bootstrapping process before the weekend is up
2018-12-15 02:47:16 <ddevault> expect an email on alpine-devel with status/how to help, and a bunch of patches
2018-12-15 02:47:45 <SpaceToast> yup, yup, https://drewdevault.com/2018/02/17/Writing-a-Wayland-compositor-1.html is what I had read :)
2018-12-15 02:47:48 <ddevault> I probably won't have my weird kernel stuff sorted soon, though
2018-12-15 02:48:21 <SpaceToast> :/ I'd love to help but I do have a pretty monumental task ahead of me as is (+ fixing all of the broken things in baselayout and such as I go through documenting them :) )
2018-12-15 02:48:32 <ddevault> no worries
2018-12-15 02:48:35 <ddevault> I intend to automate most of the process
2018-12-15 02:49:31 <SpaceToast> :)
2018-12-15 03:14:10 <danieli> ... wow
2018-12-15 03:14:12 <danieli> woot woot woot
2018-12-15 03:14:20 <danieli> clandmeter: it's a little buggered
2018-12-15 03:15:17 <danieli> either way, neat @ ddevault
2018-12-15 03:15:30 <ddevault> ^^
2018-12-15 03:15:36 <ddevault> will be pushing up a new set of patches to my aports tree shortly
2018-12-15 03:16:03 <danieli> if it doesn't affect anything else, it'd be neat to get it upstream
2018-12-15 03:16:48 <ddevault> looking foward to it
2018-12-15 03:17:06 <ddevault> lots of work ahead though
2018-12-15 03:17:54 <danieli> if the patches do have any adverse effects, i'd assume we want to review
2018-12-15 03:18:07 <ddevault> I assume you want to review either way
2018-12-15 03:18:29 <danieli> well yeah, but extra care needs to be taken if they have any adverse side-effects
2018-12-15 03:18:41 <ddevault> I see
2018-12-15 03:18:50 <ddevault> well, so far I don't know of anything which introduces risk to other ports
2018-12-15 03:19:13 <danieli> risc-v isn't so terribly weird it turns everything it touches into shit, so that's good :)
2018-12-15 03:19:28 <ddevault> in fact, riscv is super cool, this arch is awesome
2018-12-15 03:19:42 <ddevault> this is some of the most fun I've had on a project in recent memory
2018-12-15 03:22:17 <danieli> that sounds fun, hopefully we manage to get some boxes we can use as builders and publish a port
2018-12-15 03:23:05 <ddevault> offer still stands to use my hardware
2018-12-15 03:23:09 <ddevault> I'm going to automate building world on builds.sr.ht
2018-12-15 03:23:28 <danieli> it would be cool, we'll have to discuss it
2018-12-15 04:12:30 <jwh> before I open a PR, can someone have a gander at https://github.com/joeholden/aports/commits/litespeed - fixed the outstanding issues I can see but any suggestions welcome
2018-12-15 04:12:47 <jwh> its pretty horrible either way due to having to move things around
2018-12-15 04:17:09 <ddevault> https://mirror.sr.ht/alpine/main/
2018-12-15 04:18:03 <ddevault> I now have apk working and pulling updates/packages from this repo on my hifive unleashed
2018-12-15 04:19:02 <jwh> nice
2018-12-15 04:20:16 <jwh> what are you using for the building?
2018-12-15 04:20:19 <jwh> software that is
2018-12-15 04:20:38 <ddevault> ?
2018-12-15 04:20:52 <ddevault> I have a sysroot on an x86_64 machine based on bootstrap.sh
2018-12-15 04:20:59 <ddevault> working on setting up an abuild thing on the riscv64 machine too
2018-12-15 04:21:02 <jwh> ah
2018-12-15 04:21:05 <ddevault> need a few other things
2018-12-15 04:21:08 <jwh> cool
2018-12-15 04:21:22 <ddevault> just porting some quality of life stuff right now
2018-12-15 04:21:46 <jwh> heh
2018-12-15 04:22:04 <ddevault> so I have a comfortable working environment on this machine
2018-12-15 04:27:23 <ddevault> I also put this up https://mirror.sr.ht/alpine/community/
2018-12-15 04:41:09 <jwh> o/
2018-12-15 04:41:47 <ddevault> self-hosting status: ALMOST works, but I need a newer kernel to get fakeroot to work
2018-12-15 04:51:54 <jwh> I'd kinda like some mips64 builds, but I doubt theres enough demand to justify the extra support load
2018-12-15 05:05:31 <jwh> but then apparently it can't even build gcc
2018-12-15 05:26:30 <jwh> what on earth, my serial ports are all messed up
2018-12-15 05:55:07 <jwh> https://gist.github.com/joeholden/850e6303c9da6f23e9f8c7222d1fc0b2
2018-12-15 05:55:08 <jwh> P(
2018-12-15 05:55:10 <jwh> :(
2018-12-15 09:51:52 <fcolista> ncopa, clandmeter : https://dpaste.de/5U6r/raw
2018-12-15 09:52:26 <fcolista> i had to create a py2 dir and slighlty modify the standard py APKBUILD template for this package
2018-12-15 09:52:35 <fcolista> what do you think?
2018-12-15 12:12:41 <andypost> fcolista, in edge py3-setuptools lives inside of python3, there was some issue to decouple
2018-12-15 13:11:07 <andypost> clandmeter, would be great to get you POV https://github.com/alpinelinux/aports/pull/5180
2018-12-15 14:53:56 <jwh> andypost: o/
2018-12-15 15:00:51 <jwh> hm actually, no that change is all wrong
2018-12-15 15:00:55 <jwh> baaad
2018-12-15 15:01:48 <jwh> admin webui key will be generated by whatever creates the package and then static for all installs... I mean it probably should't matter since if its important it should be replaced, but I wonder if I could generate it in post install
2018-12-15 16:10:21 <fcolista> andypost, good point.
2018-12-15 16:10:22 <fcolista> https://dpaste.de/DMRu/raw
2018-12-15 16:30:55 <Lochnair> jwh: pretty sure it fails because you're using the kernel headers for the wrong arch
2018-12-15 16:31:11 <Lochnair> struct sigcontext is different on x86 vs mips
2018-12-15 16:33:22 <jwh> well I dunno, I just ran bootstrap.sh with the target
2018-12-15 16:33:49 <jwh> unless I misunderstood what bootstrap actually needs
2018-12-15 16:34:15 <jwh> binutils succeeds, but then gcc fails
2018-12-15 16:58:00 <Lochnair> oh that's weird
2018-12-15 16:58:31 <Lochnair> lemme try it here
2018-12-15 17:15:39 <Lochnair> jwh: works like expected here so far
2018-12-15 17:15:47 <Lochnair> are you running edge or stable?
2018-12-15 17:15:54 <jwh> edge
2018-12-15 17:15:58 <jwh> master apoerts
2018-12-15 17:15:59 <jwh> aports*
2018-12-15 17:16:32 <jwh> did I do the setup right? I just installed a copy of x86_64 alpine into a dir for the build chroot
2018-12-15 17:16:37 <jwh> gave it that, and the tagret
2018-12-15 17:16:40 <jwh> target*
2018-12-15 17:22:42 <Lochnair> the 3.8 minirootfs from the dl page?
2018-12-15 17:23:05 <jwh> oh, nope, apk --initdb
2018-12-15 17:23:09 <jwh> edge also
2018-12-15 17:23:35 <jwh> maybe I should have used the rootfs now its available
2018-12-15 17:28:48 <Lochnair> maybe, but you should still be on edge in the build chroot when compilng edge packages iirc
2018-12-15 17:29:07 <Lochnair> I'm running the bootstrap in a alpine:edge Docker container
2018-12-15 17:29:19 <Lochnair> only installed alpine-sdk in it
2018-12-15 17:29:37 <Lochnair> cloned aports and started the bootstrap
2018-12-15 17:30:00 <jwh> hm
2018-12-15 17:30:05 <jwh> weird
2018-12-15 17:32:15 <jwh> lemme start again
2018-12-15 17:57:55 <jwh> hm
2018-12-15 18:00:28 <mps> ncopa: I posted new crystal APKBUILD few days ago, https://patchwork.alpinelinux.org/patch/4273/
2018-12-15 18:01:09 <mps> if you remember, we talked about before your travel
2018-12-15 18:02:52 <mps> core developer (RX14) are interested to have crystal 0.27 in new stable Alpine, because they test crystal first on Alpine
2018-12-15 18:08:42 <danieli> calm down, when it gets to it, 3.9 won't be released without it
2018-12-15 18:08:52 <danieli> there are still things left to do before that
2018-12-15 18:11:16 <mps> danieli: ok, hope so
2018-12-15 18:13:31 <danieli> if you pay some attention to the IRC channels, it'll be hard to miss it when the release is closing in :)
2018-12-15 18:15:30 <mps> danieli: in that case i'm appearing as a crystal devs agent, unpaid unfortunately :)
2018-12-15 18:21:07 <jwh> Lochnair: I must be doing something wrong
2018-12-15 18:22:01 <jwh> if abuild would stop moaning about being run s uid 0 and setup users in the chroot it would be much easier
2018-12-15 18:22:08 <jwh> or bootstrap, rather
2018-12-15 19:35:44 <ddevault> alpine riscv64 port is officially self-hosting :D
2018-12-15 19:36:08 <ddevault> going to send an email about it to alpine-devel as soon as I'm able to write that email from this machine
2018-12-15 19:37:01 <danieli> hohoho, nice!
2018-12-15 19:37:10 <danieli> been able to build world yet_
2018-12-15 19:37:12 <danieli> ?
2018-12-15 19:37:18 <ddevault> no longer in a chroot, booting into openrc
2018-12-15 19:37:33 <ddevault> haven't run the full build yet
2018-12-15 19:38:04 <ddevault> I have a few bootstrapping hacks to unhack first
2018-12-15 19:44:58 <ddevault> todo list https://sr.ht/8jZe.txt
2018-12-15 19:58:21 <Lochnair> jwh: I mean probably, but I have no clue what that could be
2018-12-15 19:58:32 <Lochnair> pretty sure that's abuild itself complaining
2018-12-15 19:58:47 <danieli> it is ^
2018-12-15 19:58:57 <jwh> yeah
2018-12-15 19:59:16 <jwh> I have an entirely different error on this one, I'm pretty sure I've just set it up wrong
2018-12-15 20:01:22 <jwh> nm, got loads of other things I *should* be doing heh
2018-12-15 20:07:03 <Lochnair> heh, you and me both
2018-12-15 20:07:18 <Lochnair> tho I can dump the resulting packages from my bootstrap somewhere if you want them
2018-12-15 20:07:48 <jwh> that would be awesome
2018-12-15 20:11:32 <Lochnair> there you go: https://dl.lochnair.net/Alpine/mips64-bootstrap/packages/
2018-12-15 20:11:50 <jwh> thank you sir
2018-12-15 20:12:12 <Lochnair> np
2018-12-15 20:22:47 <jwh> need to figure out why my serial cable isn't working now :D
2018-12-15 20:38:19 <jwh> aw, Illegal instruction
2018-12-15 20:38:20 <jwh> Illegal instruction
2018-12-15 20:38:21 <jwh> oops
2018-12-15 20:38:43 <jwh> may need to investigate
2018-12-15 21:14:24 <jwh> heh, my freshly setup one I did before failed too, wonder what differs
2018-12-15 21:14:32 <jwh> but anyway at least I got the toolchain
2018-12-15 21:19:35 <jwh> oohhhh
2018-12-15 21:36:52 <Lochnair> did you figure something out?
2018-12-15 21:40:10 <jwh> I thought I had, but nope
2018-12-15 21:40:41 <jwh> I could do with figuring out what I'm doing wrong, but I can't see there is much scope for doing it wrong
2018-12-16 23:42:40 <ddevault> hifive:~$ echo "$(uname -m): $(apk search | wc -l)"
2018-12-16 23:42:42 <ddevault> riscv64: 487
2018-12-16 23:42:51 <ddevault> making pretty good progress
2018-12-17 00:02:04 <mps> is the 'riscv64' official arch name for it
2018-12-17 00:02:46 <danieli> yes
2018-12-17 00:04:28 <mps> want to have such machine, but don't think that will happen soon
2018-12-17 00:04:47 <ddevault> they're somewhat difficult to obtain, but super cool and I highly recommend getting one if you can
2018-12-17 00:04:59 <ddevault> this one cost a grand and I had to wait like 5 months for it to be delievered
2018-12-17 00:05:33 <ddevault> though if their latest batch has leftovers there might not be a wait
2018-12-17 00:06:38 <ddevault> how do you guys do maintenance on the ppc64le port, by the way? do you have hardware or do you use qemu?
2018-12-17 00:06:40 <mps> ddevault: could you give some estimation of the performance
2018-12-17 00:06:55 <ddevault> I only did one crappy "benchmark"
2018-12-17 00:07:13 <mps> your personal impression is enough for me
2018-12-17 00:07:46 <ddevault> a native build of musl from RAM on all 4 cores took about 5x as long as a 4 core cross-build on my Core Duo @ 2.40GHz
2018-12-17 00:08:04 <ddevault> the bottleneck is the very slow mmcblk I/O
2018-12-17 00:08:15 <ddevault> but on the whole I've been impressed with the performance on files which are in the cache
2018-12-17 00:08:57 <mps> mmc is slow, I build aarch64 and armhf/armv7 on mmc cards and that is slow job
2018-12-17 00:09:15 <ddevault> I'm going to move to nbd once I start doing automated builds of world
2018-12-17 00:09:22 <ddevault> or just RAM
2018-12-17 00:10:25 <mps> i like riscv cpu architecture
2018-12-17 00:11:12 <ddevault> me too
2018-12-17 00:12:19 <mps> i'll bye it for sure when it become available in my 'market'
2018-12-17 00:14:45 <mps> ddevault: thanks for sharing your impression about riscV, it is late here so good night
2018-12-17 00:14:49 <ddevault> night
2018-12-17 01:25:40 <jwh> hmph, getting '1 error; 21 MiB in 26 packages', verbose isn't telling me whats wrong
2018-12-17 01:25:47 <danieli> tried apk fix?
2018-12-17 01:26:04 <jwh> ahhh, that'll do :D
2018-12-17 01:26:07 <jwh> thanks
2018-12-17 01:26:24 <jwh> (1/1) Reinstalling libcrypto1.1 (1.1.1a-r0)
2018-12-17 01:26:25 <jwh> o/
2018-12-17 01:26:33 <danieli> let me guess, you went from stable to edge?
2018-12-17 01:26:36 <jwh> ye
2018-12-17 01:26:45 <danieli> yeah, that's related to libressl -> openssl
2018-12-17 01:26:52 <danieli> also, this is #alpine-devel, the development channel
2018-12-17 01:26:53 <jwh> yeah I thought it was
2018-12-17 01:26:56 <jwh> ugh
2018-12-17 01:27:05 <jwh> both next to each other on my keyboard :(
2018-12-17 02:04:33 <ddevault> the dependency tree for mutt is wild
2018-12-17 02:04:41 <ddevault> I'm almost 50 packages into it
2018-12-17 02:04:56 <ddevault> and that's _after_ disabling some features in various packages
2018-12-17 02:05:16 <jwh> that seems... excessive
2018-12-17 02:05:25 <ddevault> it's mostly all of the crypto dependencies
2018-12-17 02:05:27 <ddevault> gnupg
2018-12-17 02:05:29 <ddevault> etc
2018-12-17 02:05:37 <danieli> slightly related: i'm actually working on a new aports/pkgs browser
2018-12-17 02:05:46 <danieli> dependency trees are cool
2018-12-17 02:05:51 <ddevault> nice
2018-12-17 02:06:24 <ddevault> lots of these crypto-related packages have large, slow test suites too :/
2018-12-17 02:06:41 <jwh> hm, when is 3.9 due? I know you guys are busy and stuff.. just wondering when my PRs might be merged (sorry)
2018-12-17 02:07:03 <danieli> how does 3.9 matter to that?
2018-12-17 02:07:08 <danieli> new packages land in edge
2018-12-17 02:07:20 <danieli> and releases are essentially freezes of edge
2018-12-17 02:07:22 <jwh> well, presumably thats more of a focus so time is being spent there instead
2018-12-17 02:07:51 <danieli> edge (master) is where the fun happens
2018-12-17 02:07:54 <jwh> which is cool, just wondering
2018-12-17 02:08:20 <jwh> yeah
2018-12-17 02:11:27 <ddevault> >PASS: t-do-exceptions-work-at-all-with-this-compiler
2018-12-17 02:11:30 <ddevault> spiteful test, that one
2018-12-17 02:11:43 <jwh> lol
2018-12-17 02:11:50 <danieli> i bet it's there for a reason
2018-12-17 08:05:33 <fabled> ncopa, i'm trying to figure openjdk7 on x86_64 first. but it's sort of smelling compiler issue
2018-12-17 08:41:45 <fabled> ncopa, yeah, x86_64 openjdk7 bootstrap fails because of incorrect code generation in gcc8
2018-12-17 08:55:19 <danieli> i think erlang (specifically erlang-wx) needs a rebuild against whatever is the latest wxwidgets version
2018-12-17 08:55:26 <danieli> observer (and probably other things) are breaking
2018-12-17 08:55:58 <danieli> built against abi 1010, current is 1013
2018-12-17 09:08:29 <fabled> ncopa, the miscompiled part: http://sprunge.us/1zX1bw ...
2018-12-17 09:10:20 <clandmeter> ncopa, i guess we could split ca-certificates to have ca-certificates.crt separated. I guess /etc/ssl/cert.pem is a bsd only thing.
2018-12-17 09:31:12 <clandmeter> ah lol, that gets generated on the fly :|
2018-12-17 12:59:29 <ripplewang888> hello, everyone~~~
2018-12-17 12:59:44 <ripplewang888> Ask a simple question
2018-12-17 13:00:09 <ripplewang888> I want to develop on Alpine linux. Where can I download the source code?
2018-12-17 13:00:21 <ripplewang888> Do we have any github? or download scripts?
2018-12-17 13:00:31 <ripplewang888> Can Anyone help me?
2018-12-17 13:00:42 <_ikke_> ripplewang888: It helps to be a little bit patient
2018-12-17 13:02:11 <ripplewang888> yes
2018-12-17 13:02:34 <ripplewang888> I'm reading wiki. But still not found anywhere to download source code
2018-12-17 13:03:44 <_ikke_> ripplewang888: What source code exactly?
2018-12-17 13:03:58 <_ikke_> alpinelinux is a distribution, so there are many components involved
2018-12-17 13:04:22 <ripplewang888> uboot and linux source code.
2018-12-17 13:04:26 <_ikke_> All the packages are defined in a repository called aports
2018-12-17 13:04:47 <ripplewang888> That I can cross-compile, and burn image to my board.
2018-12-17 13:05:31 <_ikke_> https://git.alpinelinux.org/cgit/aports/tree/main/linux-vanilla
2018-12-17 13:05:56 <ripplewang888> https://github.com/alpinelinux/aports
2018-12-17 13:06:12 <ripplewang888> I think it's this?
2018-12-17 13:06:49 <_ikke_> yes
2018-12-17 13:07:07 <ripplewang888> okay, Thanks. I will download
2018-12-17 13:22:00 <ripplewang888> seems use mkimage.sh this script to downlaod sourcecode and compile automatically.
2018-12-17 13:22:10 <ripplewang888> Am I right? @_ikke_
2018-12-17 13:23:09 <ncopa> ripplewang888: alpine is built of thousands of packages
2018-12-17 13:23:20 <ncopa> one of those packages is the kernel, linux-vanilla
2018-12-17 13:23:48 <ncopa> the mkimage.sh collects a chosen number of packages and creates a bootable iso image from it
2018-12-17 13:24:52 <ncopa> each package has an APKBUILD, a script that describes how to build it
2018-12-17 13:25:13 <ripplewang888> okay, I think when system is up.  Package also can use apk install?
2018-12-17 13:25:35 <ripplewang888> So when compile system, just need to build the minimal system?
2018-12-17 13:25:44 <ncopa> the packages built from the APKBUILDs can be installed with `apk add`, yes
2018-12-17 13:25:57 <ncopa> depends a bit what you want to build
2018-12-17 13:26:04 <ncopa> do you want build a bootable iso image?
2018-12-17 13:26:10 <ripplewang888> yes.
2018-12-17 13:26:13 <ripplewang888> with uboot
2018-12-17 13:26:15 <ripplewang888> kernel
2018-12-17 13:26:17 <ripplewang888> rootfs
2018-12-17 13:26:38 <ripplewang888> sorry, today is my first day. so lots of question.
2018-12-17 13:26:54 <ncopa> and you want build all the packages shipped on the iso from source?
2018-12-17 13:27:57 <ripplewang888> no. choose some package. not all package? I think can use make menuconfig to configure?
2018-12-17 13:28:37 <ripplewang888> I want to build the minimal system, with my own chipset driver.
2018-12-17 13:28:41 <ncopa> no, menuconfig is for kernel modules. not for distro software packages
2018-12-17 13:28:53 <ripplewang888> okay,
2018-12-17 13:29:49 <ncopa> do you only want build kernel? or do you also want build userspace tools, like apk, libc etc?
2018-12-17 13:30:03 <ripplewang888> yes, include apk ,libc
2018-12-17 13:30:19 <ripplewang888> so , use mkimage.sh can reach this?
2018-12-17 13:30:26 <ncopa> no
2018-12-17 13:30:41 <ncopa> you need build each package you want first, using abuild
2018-12-17 13:30:42 <ripplewang888> mkaimage.sh  only for kernel?
2018-12-17 13:31:06 <ncopa> mkimage only builds the bootable iso image, but it dependsn on prebuilt apk packages
2018-12-17 13:32:09 <ripplewang888> Does this script download kernel sourcecode?
2018-12-17 13:32:26 <ripplewang888> If I want to change some driver for my own board.
2018-12-17 13:32:43 <ripplewang888> like clocks. memory controller...etc
2018-12-17 13:32:55 <ripplewang888> HDMI.. bluetooth
2018-12-17 13:33:43 <ripplewang888> where is abuild? I can't find in script directory
2018-12-17 13:38:15 <ripplewang888> Do you have any help document ? or link ?
2018-12-17 13:38:35 <clandmeter> documentation is poor. we are working on it.
2018-12-17 13:38:43 <ripplewang888> About how to set up development environment.
2018-12-17 13:38:48 <clandmeter> its best to first look around the repos, then come back and ask questions.
2018-12-17 13:39:18 <clandmeter> we have documentation on the wiki. but its not 100$% complete.
2018-12-17 13:39:35 <ripplewang888> yes.
2018-12-17 13:40:21 <clandmeter> asking 100 questions in a short time will scare away developers to help you. best is to do some research first.
2018-12-17 13:42:50 <_ikke_> ripplewang888: https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package#Setup_your_system_and_account
2018-12-17 13:42:53 <_ikke_> This is the basic
2018-12-17 13:43:04 <ripplewang888> okay .
2018-12-17 13:43:09 <ripplewang888> Thanks a lot
2018-12-17 13:43:23 <clandmeter> fabled, are you on vpn already?
2018-12-17 13:46:44 <ripplewang888> I'm not using vpn.  can access this chat room directly.
2018-12-17 13:48:58 <SpaceToast> ripplewang888: last I checked you were ripplewang888, and not fabled :)
2018-12-17 13:50:17 <ripplewang888> oh...
2018-12-17 23:52:35 <ddevault> who was it that was working on a tool for working with dependency trees
2018-12-17 23:54:28 <danieli> i'm working on a service that incorporates them, not sure if you're aiming at that
2018-12-17 23:55:07 <danieli> probably not
2018-12-17 23:55:08 <ddevault> I was wondering about how best to prioritize which packages to build in world
2018-12-17 23:55:16 <ddevault> part of that would be ordering them right
2018-12-17 23:55:27 <ddevault> I could just iterate over everything in order and abuild -R
2018-12-17 23:55:39 <danieli> it's probably best to just prioritize main/
2018-12-17 23:56:01 <ddevault> how big is main once compiled? for x86_64
2018-12-17 23:56:24 <danieli> 17.3G   ./main
2018-12-17 23:56:25 <danieli> that's in 3.8
2018-12-17 23:56:42 <ddevault> thanks
2018-12-17 23:56:42 <danieli> 20.6G in edge
2018-12-17 23:56:49 <danieli> so it's around 20 somewhere
2018-12-17 23:56:51 <ddevault> how about community
2018-12-17 23:57:04 <danieli> 28G in 3.8, 34.7 in edge
2018-12-17 23:57:24 <danieli> oh right, this is all the architectures, my bad!
2018-12-17 23:57:25 <ddevault> gotcha, thanks
2018-12-17 23:57:29 <ddevault> oh, that helps
2018-12-17 23:57:31 <danieli> let me check again
2018-12-17 23:57:55 <danieli> i thought it felt strangely large
2018-12-17 23:57:56 <danieli> v3.8/main/x86_64 is 3G
2018-12-17 23:58:08 <danieli> and 3.1G in edge
2018-12-17 23:58:53 <danieli> so, edge/{main,community}/x86_64 are 3.1G and 6.2G respectively
2018-12-17 23:58:55 <ddevault> nice
2018-12-17 23:59:04 <ddevault> that's a very reasonable size
2018-12-17 23:59:08 <danieli> agreed
2018-12-17 23:59:33 <ddevault> in other news, ✓ ruby
2018-12-18 03:33:52 <ddevault> for the moment I'm out of packages I need to build for my own ends
2018-12-18 03:34:12 <ddevault> and switching gears to finishing up that ffmpeg upgrade workstream I had going
2018-12-18 03:34:31 <ddevault> in the meantime any suggestions on what to have building so my RISC-V doesn't get cold?
2018-12-18 03:36:10 <danieli> the largest and most challenging ones, probably
2018-12-18 03:36:15 <danieli> it'll highlight some potential issues
2018-12-18 03:36:29 <ddevault> I'm looking easy stuff I can build in the background while my focus is elsewhere
2018-12-18 03:36:38 <ddevault> if I hit issues I'll write it down and look later
2018-12-18 03:36:46 <danieli> ah, fair enough
2018-12-18 03:36:58 <danieli> you could just have it build everything and skip + log on errors
2018-12-18 03:37:05 <ddevault> I suppose
2018-12-18 03:37:15 <ddevault> I could also do a native gcc build
2018-12-18 03:37:22 <ddevault> that'll take a while
2018-12-18 03:37:49 <ddevault> actually I probably should just recompile everything that was cross compiled
2018-12-18 04:11:30 <ddevault> checking for libcurl soname... Segmentation fault
2018-12-18 04:11:35 <ddevault> building kodi on x86_64
2018-12-18 04:11:45 <ddevault> about what I expected from kodi
2018-12-18 04:11:55 <danieli> no surprise there
2018-12-18 08:18:21 <danieli> ncopa: keep an eye on sqlite, bugfixes a' comin
2018-12-18 08:19:33 <danieli> it's not very severe though, by the looks of it, but we should still stay on top of it
2018-12-18 08:39:59 <TBB> I suppose it wasn't a 10 second exploitable one but "remote code execution" always sounds severe
2018-12-18 08:40:22 <TBB> I guess the noise was mostly about the fact sqlite is practically everywhere these days
2018-12-18 08:40:31 <danieli> yeah
2018-12-18 08:40:38 <danieli> tl;dr upgrade to 3.26.0, context @ https://blade.tencent.com/magellan/index_en.html
2018-12-18 08:41:40 <danieli> as far as I saw, it has pretty specific requirements for exploitation
2018-12-18 09:39:26 <ncopa> anybody can help figure out whats wrong with perl-net-ssleay?
2018-12-18 09:39:42 <ncopa> the perl-io-socket-ssl test suite seems to hang occationally
2018-12-18 09:40:11 <ncopa> and apparently there was another package that hung in test suite, which looked like it was testing something with ssleay
2018-12-18 09:43:09 <ncopa> hum... maybe the latest patch fixed it
2018-12-18 10:07:06 <mps> ncopa: it passed all tests right now, at least on my edge box with 'abuild -r'
2018-12-18 10:07:35 <ncopa> yeah, samae here
2018-12-18 10:07:44 <ncopa> i think problem may be fixed
2018-12-18 10:11:55 <mps> and it is linked with openssl, so everything looks ok
2018-12-18 10:15:46 <mps> ncopa: sorry for annoying again, but did you looked at crystal 0.27.0 patch I posted. https://patchwork.alpinelinux.org/patch/4273/
2018-12-18 11:23:26 <rdutra> ncopa: regarding packages that are hanging seems that: py-pynacl 1.3.0-r0 too
2018-12-18 11:23:39 <rdutra> ncopa: in the ppc64le builder I can see:  build-edge-ppc64le   main/py-pynacl 1.3.0-r0
2018-12-18 11:23:50 <rdutra> seems it is running since yesterday
2018-12-18 13:50:57 <ncopa> mps: seems like rnalrd pushed your crystal patch. thanks to both of you!
2018-12-18 13:56:20 <rnalrd> np
2018-12-18 14:14:49 <fcolista> ncopa, you around?
2018-12-18 14:15:23 <fcolista> What do you think? https://dpaste.de/gNrY/raw
2018-12-18 14:16:22 <fcolista> seems that py-future cannot be built  within the same dir
2018-12-18 14:16:47 <fcolista> so I had to create a dir for py2 and build the package from there
2018-12-18 14:17:14 <fcolista> perhaps jirutka[m] or clandmeter have some ideas on that
2018-12-18 14:17:46 <fcolista> arch does something like that
2018-12-18 14:17:46 <fcolista> https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/python-future
2018-12-18 14:19:12 <mps> rnalrd: I
2018-12-18 14:19:31 <mps> sorry, I'm mostly here if help needed with it
2018-12-18 14:22:03 <rnalrd> mps, thank it went through smoothly
2018-12-18 14:29:56 <clandmeter> fcolista, looks ok
2018-12-18 14:34:26 <fcolista> thx a lot clandmeter
2018-12-18 15:57:25 <ncopa> fcolista: im here
2018-12-18 15:58:18 <fcolista> hi  ncopa
2018-12-18 15:58:18 <fcolista> https://bugs.alpinelinux.org/issues/9136
2018-12-18 15:58:26 <fcolista> wondering if this is enough
2018-12-18 15:58:34 <ncopa> [ $python == "python2" ] is bashism
2018-12-18 15:58:46 <fcolista> aha
2018-12-18 15:58:47 <ncopa> [ "$python" = "python2" ]
2018-12-18 15:59:12 <ncopa> i personally think its more readable with an if .. else
2018-12-18 15:59:15 <fcolista> if [ "$python" ...
2018-12-18 15:59:21 <fcolista> ok good
2018-12-18 15:59:41 <ncopa> yeah, its more lines of code, but the intention is clearer
2018-12-18 16:00:07 <fcolista> i did it to have less lines actually
2018-12-18 16:00:21 <fcolista> but I've not thought that it was a bashism
2018-12-18 16:00:23 <fcolista> ok good
2018-12-18 16:01:13 <fcolista> https://dpaste.de/Gh0a/raw
2018-12-18 16:01:55 <ncopa> ==
2018-12-18 16:01:58 <ncopa> use single =
2018-12-18 16:02:12 <ncopa> the double == is bashism
2018-12-18 16:02:30 <fcolista> ah that part was the bashism
2018-12-18 16:02:31 <fcolista> ok
2018-12-18 16:03:07 <ncopa> otherwise it looks good
2018-12-18 16:03:35 <fcolista> ok good. Pushed
2018-12-18 16:04:26 <ncopa> oh...
2018-12-18 16:04:38 <ncopa> shouldprobably have a comment on why the -fno-PIC is needed
2018-12-18 17:29:16 <ncopa> perl-net-server is hanging in testsuite: http://build.alpinelinux.org/buildlogs/build-3-9-x86_64/main/perl-net-server/perl-net-server-2.009-r1.log
2018-12-18 17:33:30 <ncopa> i think it hangs because perl-io-ssleay was installed build time
2018-12-18 17:36:16 <ncopa> restarted the builder. lets see if it still hangs
2018-12-18 20:38:53 <mps> xf86-video-s3 on armv7? is it needed there
2018-12-19 09:29:21 <lag> clandmeter: ncopa: AinNero: mps: Is there somewhere I can keep track of ARMv7 developments without hounding you guys on here?
2018-12-19 09:29:48 <clandmeter> development as in?
2018-12-19 09:30:26 <lag> clandmeter: Progress for release
2018-12-19 09:30:47 <clandmeter> armv7 will be released for next alpine release.
2018-12-19 09:31:59 <clandmeter> its still struggling with building world.
2018-12-19 09:32:56 <clandmeter> you can see some progress in alpine-commits channel.
2018-12-19 09:36:36 <ncopa> and you can see current status on  build.alpinelinux.org
2018-12-19 10:08:50 <mps> lag: you can install it on real hardware or on emulator (qemu, lxc even chroot) and look how it works
2018-12-19 10:10:58 <mps> armv7 edge works quite fine and stable on real hardware. I have one SBC whose `uptime` says: 11:08:56 up 24 days, 20:51,  0 users,  load average: 0.11, 0.15, 0.10
2018-12-19 10:12:03 <mps> and another one with Xorg running quite fine, when I need it
2018-12-19 10:15:26 <lag> mps: I will rely on your good judgement with regards to stability
2018-12-19 10:15:35 <lag> mps: I really would like to know when it'll be formally released
2018-12-19 10:15:57 <lag> mps: But again, without bugging you guys every week
2018-12-19 10:16:17 <lag> mps: Are there any weekly meeting minutes I can go look at (or similar)?
2018-12-19 10:20:16 <mps> lag: it is already released but not as stable. It is now formally 'edge' which means testing phase. It will be declared stable whith other architectures, probably, if all went as planned
2018-12-19 10:21:17 <mps> but, some packages (apks) could be missing in it if couldn't be built on armv7
2018-12-19 10:22:47 <mps> s/if couldn't/if they couldn't/
2018-12-19 10:22:47 <alpine-meetbot> mps meant to say: but, some packages (apks) could be missing in it if they couldn't be built on armv7
2018-12-19 10:28:23 <lag> mps: Thanks for the info
2018-12-19 10:28:39 <lag> alpine-meetbot: Thanks for the clarification :'D
2018-12-19 18:14:06 <mtutty> Hey all, pretty simple question here.  If I need NGROUPS_MAX > 16 (or 32, whatever alpine's default), can I edit /etc/system file and restart, or do I need to rebuild the kernel?
2018-12-19 18:14:06 <mtutty> set ngroups_max = 32
2018-12-19 18:16:41 <SpaceToast> mtutty: the default on alpine (as far as I can see) is 65536
2018-12-19 18:16:50 <SpaceToast> you can use sysctl kernel.ngroups_max
2018-12-19 18:16:58 <SpaceToast> you can set it on boot in /etc/sysctl.d
2018-12-19 18:17:11 <mtutty> Super!  Will try that right away.
2018-12-19 18:20:55 <mtutty> @SpaceToast Would the docker image be any different?
2018-12-19 18:20:58 <mtutty> I see this:
2018-12-19 18:20:59 <mtutty> docker run -it --rm alpine getconf NGROUPS_MAX
2018-12-19 18:20:59 <mtutty> 32
2018-12-19 18:22:32 <SpaceToast> docker is a container system
2018-12-19 18:22:42 <SpaceToast> this means that it runs in a namespace under the host
2018-12-19 18:22:54 <SpaceToast> if you want to change a kernel variable in a docker image, you have to modify those on the host system
2018-12-19 18:23:29 <SpaceToast> in terms of getconf I think musl defines NGROUPS_MAX as 32 (and provides getconf)
2018-12-19 18:23:38 <SpaceToast> but my understanding is that it's the kernel setting that matters
2018-12-19 18:24:12 <mtutty> SpaceToast:  It's not host-related.
2018-12-19 18:24:13 <mtutty> docker run -it --rm debian:8-slim getconf NGROUPS_MAX
2018-12-19 18:24:13 <mtutty> 65536
2018-12-19 18:24:23 <SpaceToast> ... you did read *everything* I wrote, right?
2018-12-19 18:25:11 <mtutty> Yes.  I just showed two different images on the same host, showing different values.  I think that rules out the first part of what you said, yes?
2018-12-19 18:25:33 <mtutty> So it's really a musl problem, not a kernel config thing.
2018-12-19 18:25:43 <SpaceToast> ngroups is a kernel thing
2018-12-19 18:25:54 <SpaceToast> musl defines NGROUPS_MAX as 32 and provides getconf
2018-12-19 18:26:00 <SpaceToast> try docker run --rm alpine cat /proc/sys/kernel/ngroups_max
2018-12-19 18:26:31 <SpaceToast> are you actually running into the limit, or are you pre-emptively optimizing? :)
2018-12-19 18:26:45 <mtutty> No optimization yet :)
2018-12-19 18:27:04 <mtutty> We're seeing a failure using nscd and nss-pgsql.
2018-12-19 18:27:35 <mtutty> It works, but we'll get different # of groups on alpine vs debian.
2018-12-19 18:28:07 <SpaceToast> if you use getconf, which I just explained twice to not be relevant
2018-12-19 18:28:14 <SpaceToast> or are you *actually* seeing a failure?
2018-12-19 18:28:23 <SpaceToast> "we're seeing a failure" -> "it works" seems like a strange thing to say
2018-12-19 18:28:55 <mtutty> SpaceToast: "A failure" !== "nothing works"
2018-12-19 18:29:06 <SpaceToast> ok, so what exactly isn't working?
2018-12-19 18:29:23 <mtutty> We're getting a limited # of groups under alpine vs debian.
2018-12-19 18:29:26 <SpaceToast> the only thing you've mentioned so far is that getconf shows a different value - the reasoning of which I've explained and pointed out as not being relevant
2018-12-19 18:29:42 <SpaceToast> are you actually hitting and confirming that limit, or are you assuming that getconf is correct?
2018-12-19 18:31:27 <mtutty> We're trying to figure out why nss-pgsql works differently on alpine vs debian.
2018-12-19 18:31:45 <SpaceToast> what are the symptoms of it working differently?
2018-12-19 18:33:15 <mtutty> SpaceToast: I'm digging up the specific getent cmds
2018-12-19 18:33:45 <SpaceToast> also, you may want to note that musl does not actually have (or want) nss
2018-12-19 18:33:50 <SpaceToast> https://wiki.musl-libc.org/future-ideas.html
2018-12-19 18:34:23 <SpaceToast> (that's why getconf and getent and such are shims that provide default values, while the actual stuff is under the kernel (such as with NGROUPS_MAX))
2018-12-19 18:34:45 <mtutty> Yes, we got that distinct impression.   https://bugs.alpinelinux.org/issues/6711
2018-12-19 18:34:59 <mtutty> So maybe we're wasting time trying to get this working.
2018-12-19 18:36:11 <SpaceToast> musl-nscd does exist, and (as far as I can tell) doesn't fetch NGROUPS_MAX from limits.h
2018-12-19 18:36:30 <SpaceToast> but ultimately, neither getconf nor getent are reliable tools for finding out details as to NGROUPS_MAX
2018-12-19 18:36:37 <SpaceToast> because that is ultimately a kernel setting
2018-12-19 18:37:10 <mtutty> SpaceToast: But if we're going through musl-nscd then its limitations become ours, regardless of the kernel setting.
2018-12-19 18:37:29 <SpaceToast> as I just mentioned, musl-nscd does not read (and thus does not care) about NGROUPS_MAX
2018-12-19 18:37:33 <mtutty> And we have another bug to fix there anyway, so maybe we should focus on that code.
2018-12-19 18:38:40 <SpaceToast> still, you may consider poking the musl ML asking to set their built-in NGROUPS_MAX def to 65536 (which is the kernel default)
2018-12-19 18:38:50 <SpaceToast> even though I doubt that's an actual source of your problems
2018-12-19 18:39:12 <SpaceToast> the likely issue you're actually encountering is that musl-nscd implements a subset of the nss protocol
2018-12-19 18:40:02 <mtutty> It doesn't appear to be well maintained.  We're looking at the most current fork from Github.  Is there a better source for us to contact?
2018-12-19 18:44:17 <SpaceToast> the only one I'm aware of is https://github.com/pikhq/musl-nscd
2018-12-19 18:44:25 <SpaceToast> they also have an APKBUILD but it clearly isn't in our world right now
2018-12-19 18:44:40 <SpaceToast> you can try using that APKBUILD to build a package and contact the person marked as the "Maintainer" in it
2018-12-19 18:44:46 <mtutty> Right, and the same guy has two other forks from that repo, one of which has a small commit from 10 months ago.
2018-12-19 18:45:37 <SpaceToast> either way, alpine uses musl, whose official stance is "we do not have (nor want) NSS"
2018-12-19 18:45:54 <SpaceToast> to resolve issues such as this faster in the future, please consider having a read through http://xyproblem.info/ :)
2018-12-19 18:46:50 <mtutty> Lol, I've had that bookmarked for 10 years or more.  Not a noob, but thanks for the info.
2018-12-19 18:47:26 <SpaceToast> well, your original question is "how do I set NGROUPS_MAX to be > 16", the answer to which is "change kernel.ngroups_max, by the way it's at 65536 by default" ;)
2018-12-19 18:48:34 <mtutty> Yes, but my real problem would take longer to explain than this entire conversation.  Thanks again, but don't stress too much over the perceived inefficiency.  It wasn't, I promise.
2018-12-19 18:48:39 <SpaceToast> (and I *still* don't know what failures you encounter)
2018-12-19 21:40:01 <jwh> don't you just hate it wehn your build vms walk off
2018-12-19 21:40:21 <jwh> when*
2018-12-19 21:40:31 <jwh> searched *all* 30 odd screen windows, not a sign
2018-12-19 21:43:37 <jwh> hm, what should I use for pkgver if the package has no release version?
2018-12-19 21:45:23 <SpaceToast> I'm not sure it'll actually make it into main/community if there are no releases, but I would do YYYYmmdd
2018-12-19 21:45:43 <SpaceToast> ultimately what matters is that pkgver increments over time (so rebuilds work), at least as my understanding goes
2018-12-19 21:45:47 <jwh> yeah I'm not really expecting it to
2018-12-19 21:46:12 <jwh> just thought it might be useful
2018-12-19 21:48:34 <jwh> once I figure out how to make it git clone ayway
2018-12-19 21:49:04 <jwh> anyway
2018-12-19 21:49:43 <jwh> guess I could just use archive
2018-12-19 21:50:16 <SpaceToast> jwh: oh, actually; https://wiki.alpinelinux.org/wiki/APKBUILD_Reference#giturl + https://wiki.alpinelinux.org/wiki/APKBUILD_Reference#pkgver
2018-12-19 21:50:34 <SpaceToast> also snapshot()
2018-12-19 21:51:06 <jwh> oh, cool
2018-12-19 21:52:32 <jwh> yeah I don't grok that
2018-12-19 22:46:40 <muhlemmer|2> I'm having some segfault issues with Dovecot. I've obtained a core dump file which I'm running through `gdb`. It complaints about missing debugging symbols. I've already found musl-dbg which helped a bit.
2018-12-19 22:47:48 <muhlemmer|2> I somehow want to install debugging symbols for Dovecot. For that I gues I have to build the software myself.
2018-12-19 22:48:16 <muhlemmer|2> I've attempted to follow https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package
2018-12-19 22:48:26 <SpaceToast> erm
2018-12-19 22:48:31 <SpaceToast> there's already a dovecot package
2018-12-19 22:48:33 <SpaceToast> you can just modify that
2018-12-19 22:48:44 <muhlemmer|2> But it doesn't quite tell me how to build the debug symbols
2018-12-19 22:49:23 <muhlemmer|2> Yeah, but what to modify? Sorry. I'm used to gentoo's make.conf where it's a matter of a centralized flag
2018-12-19 22:49:50 <SpaceToast> https://git.alpinelinux.org/cgit/aports/tree/main/dovecot/APKBUILD
2018-12-19 22:50:21 <SpaceToast> I'm not entirely sure as to how to keep debug symbols right now, but, looking at musl (https://git.alpinelinux.org/cgit/aports/tree/main/musl/APKBUILD) for example, it looks like it might be possible to get them just by adding a -dbg subpackage
2018-12-19 22:50:28 <mps> muhlemmer|2: subpackages="$pkgname-dbg"
2018-12-19 22:50:36 <SpaceToast> yup, default_dbg() is a thing
2018-12-19 22:50:59 <muhlemmer|2> ok, that'd be cool.
2018-12-19 22:51:12 <muhlemmer|2> thansk for the hint
2018-12-19 23:02:24 <brebs> muhlemmer|2: options="!strip"
2018-12-19 23:02:48 <muhlemmer|2> thanks also
2018-12-19 23:07:49 <muhlemmer|2> And now I found also CFLAGS in abuild.conf. Such a relief :P. FIrst to take out -fomit-frame-pointer.
2018-12-19 23:11:16 <jwh> hm, is there a post start that I'm missing for openrc init scripts, or should I just define start() and do it there instead?
2018-12-19 23:12:40 <SpaceToast> jwh: https://github.com/OpenRC/openrc/blob/master/service-script-guide.md
2018-12-19 23:12:50 <SpaceToast> the official docs will have our own guide, but that'll take a bit
2018-12-19 23:12:58 <SpaceToast> feel free to poke me with what you make, I'll provide feedback
2018-12-19 23:13:16 <jwh> yeah i'm looking at that
2018-12-19 23:13:33 <jwh> was just wondering if I could avoid having to define start-stop-daemon stuff in start() and just add post-start commands
2018-12-19 23:13:49 <SpaceToast> yes, you can
2018-12-19 23:13:54 <SpaceToast> it's in that link
2018-12-19 23:14:01 <SpaceToast> you should almost never have a start() at all
2018-12-19 23:14:11 <jwh> oh hm
2018-12-19 23:14:16 <jwh> I'm missing it
2018-12-19 23:16:03 <jwh> theres start_pre(), but no post so I'll have to just have start-stop-daemon in start()
2018-12-19 23:16:08 <SpaceToast> there is a post
2018-12-19 23:16:13 <SpaceToast> it's just not on the page :)
2018-12-19 23:16:15 <jwh> oh
2018-12-19 23:16:26 <jwh> kinda useless pointing me to the doc I'm already reading then :P
2018-12-19 23:16:43 <SpaceToast> you were asking if a doc exists
2018-12-19 23:16:50 <SpaceToast> you said you were reading it after I linked it
2018-12-19 23:17:20 <jwh> well not really, I asked if thre was a post start, couldn't find it on there so I was asking in case I missed something
2018-12-19 23:17:23 <jwh> coz I do that
2018-12-19 23:17:29 <SpaceToast> well, yes there is :)
2018-12-19 23:17:42 <SpaceToast> you can look at /lib/rc/*stuff*
2018-12-19 23:17:43 <jwh> post works, that'll do
2018-12-19 23:17:51 <jwh> someone should document it or something
2018-12-19 23:17:57 <jwh> :D
2018-12-19 23:18:06 <SpaceToast> as I said, I'm working on it ;)
2018-12-19 23:18:53 <jwh> :D
2018-12-19 23:37:03 <muhlemmer|2> SpaceToast: brebs: mps: All your suggestions are working like a charm! In the end not so difficult. Thanks
2018-12-20 04:42:52 <ddevault> draft https://gist.github.com/ddevault/c6c076f1b975f945c7b72cbfb3654168
2018-12-20 04:43:01 <ddevault> I don't recall exactly who wanted to see this, something about docs
2018-12-20 04:43:20 <ddevault> when I finish updating the bootstrap script I'll probably add a page to the alpine wiki
2018-12-20 04:44:21 <SpaceToast> ddevault: that'd be me, thanks :)
2018-12-20 04:44:47 <ddevault> np
2018-12-20 04:46:19 <sorear> the language pedant in me is very bothered by "open-source instruction set", instruction sets don't have source code
2018-12-20 04:46:27 <ddevault> s/source//
2018-12-20 04:46:30 <ddevault> (draft)
2018-12-20 04:47:21 <sorear> and the claims about the hifive board are … interesting
2018-12-20 04:47:45 <ddevault> which claims? that it's suprisingly fast?
2018-12-20 04:48:28 <ddevault> that it's the first totally free computer? yeah... it's a stretch
2018-12-20 04:48:34 <ddevault> I should remove that, clarifying it would ruin the point
2018-12-20 04:49:47 <sorear> if you go on ebay and buy an ultrasparc T2, you'll have a machine which is open in the same sense as the hifive unleashed - all core RTL is public, instruction set patents were waived by Sun
2018-12-20 04:50:15 <ddevault> I can put the hifiveu on an FPGA
2018-12-20 04:50:24 <ddevault> is the same true of the ultrasparc?
2018-12-20 04:50:51 <sorear> the difference is that sparcv8 is EOL by Oracle and there's no critical mass of open designs beyond openpiton and leon
2018-12-20 04:50:52 <sorear> yes
2018-12-20 04:51:11 <ddevault> nice
2018-12-20 04:51:41 <sorear> you probably want to look at openpiton which is an academically maintained fork of Sun's code drop
2018-12-20 04:52:16 <sorear> but it won't exactly correspond to what's in a T2 chip you can buy
2018-12-20 04:52:25 <danieli> #alpine-offtopic please :)
2018-12-20 07:14:34 <danieli> morning ncopa
2018-12-20 08:06:33 <ncopa> danieli: morning
2018-12-20 11:56:15 <ncopa> seems like chromium is broken
2018-12-20 11:56:19 <ncopa> hangs occationally
2018-12-20 12:05:51 <danieli> works fine for me, on edge
2018-12-20 12:06:04 <danieli> actually performs way better than on my arch desktop
2018-12-20 12:06:33 <danieli> i'm gonna try fixing chromium with a different patchset to get 70+
2018-12-20 12:20:29 <ncopa> i pushed chromium 71
2018-12-20 12:20:32 <ncopa> which hangs
2018-12-20 12:20:36 <danieli> aha, recently?
2018-12-20 12:20:37 <danieli> i can try it out
2018-12-20 12:20:59 <ncopa> i have noticed a hang in google search restul page
2018-12-20 12:21:02 <ncopa> and slack
2018-12-20 12:21:21 <ncopa> slack is practically useless in chrome 71
2018-12-20 12:22:53 <danieli> slack is practically useless period
2018-12-20 12:23:39 <TBB> well, if google's been caught sabotaging their services in other browsers, I wouldn't be surprised if they also sabotage other people's services in their browser
2018-12-20 12:24:10 <danieli> it works fine in other distros, so it's something related to our patchset or env
2018-12-20 12:28:18 <ncopa> hum, also commenting in PR reviews on github hangs
2018-12-20 12:29:00 <ncopa> it could also be that other distros (eg void) has patch for it and we don't
2018-12-20 12:29:43 <danieli> it lags and uses a lot of cpu here
2018-12-20 12:30:38 <danieli> where have you gotten the patchset for 71 from?
2018-12-20 12:33:10 <andypost> ncopa, chromium needs rebuild against fresh sqlite https://www.sqlite.org/releaselog/3_26_0.html
2018-12-20 12:33:49 <TBB> does firefox still use sqlite as their db backend?
2018-12-20 12:33:51 <danieli> separate issue, but yeah
2018-12-20 12:35:21 <ncopa> danieli: from void
2018-12-20 12:35:41 <ncopa> andypost: huh? its not abi compatible=
2018-12-20 12:35:43 <ncopa> ?
2018-12-20 12:35:46 <danieli> sec issue
2018-12-20 12:36:00 <danieli> it's pretty bad, can be exploited through websql
2018-12-20 12:36:09 <danieli> i think i posted it yesterday
2018-12-20 12:37:08 <ncopa> but does chromium need to be rebuilt? is sqlite not linked dynamic?
2018-12-20 12:38:18 <ncopa> if its not linked dynamic, then I would expect chromium to ship a bundled version of sqlite
2018-12-20 12:38:27 <ncopa> we need wait for upstream update in that case
2018-12-20 12:38:47 <andypost> ncopa, not sure about dynamic linking there was chromium issue about make it work with system sqlite
2018-12-20 12:39:34 <ncopa> if it does not use system sqlite, then its not enough to just rebuild, then the bundled sqlite needs to be replaced with updated version of sqlite
2018-12-20 12:40:03 <ncopa> if its  dynamically linked to system sqlite, then it should be enough to update sqlite and not need to rebuild chromium
2018-12-20 12:40:13 <ncopa> it looks like its not dynamically linked to libsqlite
2018-12-20 12:40:21 <danieli> indeed
2018-12-20 12:40:25 <ncopa> so they bundle sqlite sources
2018-12-20 12:40:34 <danieli> it does a lot of custom stuff around it with websql and all
2018-12-20 12:40:58 <andypost> guess the issue https://bugs.chromium.org/p/chromium/issues/detail?id=22208
2018-12-20 12:41:17 <danieli> wontfix, nice
2018-12-20 12:41:25 <ncopa> that looks like old issue from 2009
2018-12-20 12:41:38 <ncopa> they probably have a patched version of sqlite bundled
2018-12-20 12:41:51 <danieli> probably
2018-12-20 12:41:53 <ncopa> so its no just to replace the sqlite source in chromium source tree
2018-12-20 12:42:27 <ncopa> and a simple rebuild wont do anything
2018-12-20 12:45:55 <ncopa> chromium bundles Version: 3.25.3
2018-12-20 12:48:16 <ncopa> i think the same problem is with firefox
2018-12-20 12:48:27 <ncopa> iirc firefox bundles 2 or 3 copies of sqlite :)
2018-12-20 12:48:37 <danieli> not a big surprise
2018-12-20 12:49:21 <andypost> ncopa, FF is not affected https://bugzilla.mozilla.org/show_bug.cgi?id=1247329
2018-12-20 12:52:11 <andypost> looks new key should be used https://news.ycombinator.com/item?id=18686572
2018-12-20 13:00:18 <andypost> ncopa, please accept secfix for mariadb https://github.com/alpinelinux/aports/pull/5779
2018-12-20 13:04:45 <danieli> that's a whole lot of CVEs
2018-12-20 13:17:37 <mps> I made small one line patch for busybox-initscripts (/etc/mdev.conf) which add ttyUSB[0-9] devices to dialout group, https://patchwork.alpinelinux.org/patch/4283/
2018-12-20 13:18:51 <mps> it allows ordinary users to use attached tty usb devices (serial adapters usually) without needs to use su or sudo
2018-12-20 13:19:17 <mps> would be nice to be applied to next stable
2018-12-20 13:19:34 <danieli> mps: is there a bugs.a.o issue for that?
2018-12-20 13:19:48 <danieli> we generally use that and github to track target versions
2018-12-20 13:20:28 <mps> didn't post bug/issue, only sent patch
2018-12-20 13:21:02 <danieli> most of us, especially the core devs, have a lot to do - keeping track of it all can be hard
2018-12-20 13:22:06 <mps> understand that, but I have had feeling that sending patch to alpine-aports is enough
2018-12-20 13:22:38 <danieli> it'd require repeated pokes on IRC, and things can slip through the cracks
2018-12-20 13:23:37 <mps> I thought that is the preferred to send patch than just made bug report
2018-12-20 13:25:20 <danieli> 340 open PRs, 81 patches in patchwork
2018-12-20 13:26:48 <mps> yes, a lot. anyway what I should do for that issue, open bug and add url in it to patchwork.a.o ?
2018-12-20 13:29:01 <danieli> ncopa: thoughts?
2018-12-20 14:18:47 <ncopa> um
2018-12-20 14:19:35 <ncopa> the problem is if you send patch to mailing list, create a ticket and a PR to gihub, then we may need to close it multiple places = more work
2018-12-20 14:20:30 <ncopa> and if we forget to close the issues every place, we will have to look over same issue later: "was this fixed or not? is it a new unknonw issue, similar to the previous?"
2018-12-20 14:21:25 <danieli> yeah, so it's better to submit issues in only one place
2018-12-20 14:21:39 <danieli> but should people create a bugs.a.o issue to track patchwork patches?
2018-12-20 14:21:40 <danieli> github has labels
2018-12-20 14:21:53 <ncopa> one way to deal with it is to first create an issue at bugs.a.o, explaining the problem, then in the commit message you write "fixes #<issuenumber>"
2018-12-20 14:22:13 <ncopa> and send the patch to either mailing list or github PR (but not both)
2018-12-20 14:22:53 <danieli> all right, there you go pms
2018-12-20 14:23:04 <danieli> s/pm/mp/
2018-12-20 14:23:04 <alpine-meetbot> danieli meant to say: all right, there you go mps
2018-12-20 14:23:24 <ncopa> maybe it would be good to also mention in th eissue at bugs.a.o that a patch was sent to patchwork or a PR was created
2018-12-20 14:23:56 <ncopa> in case someone look at the bugs.a.o, and make a new patch, forgetting to check if someone sent anything to patchwork or github
2018-12-20 14:24:19 <danieli> mm, good both for avoiding duplication and work and for tracking target versions
2018-12-20 14:32:17 <yangxuan> ncopa: would you mind check this PR for linux-amlogic: https://github.com/alpinelinux/aports/pull/5831
2018-12-20 14:35:44 <ncopa> yangxuan: merged. thanks!
2018-12-20 14:41:58 <yangxuan> ncopa: thanks, if it's possible move linux-amlogic to community?
2018-12-20 14:44:14 <yangxuan> after upgrade it's 4.19, LTS
2018-12-20 14:45:06 <danieli> have you tested that it's not broken?
2018-12-20 14:50:27 <yangxuan> do you mean test linux-amlogic? yes, I have tested it on my android box
2018-12-20 14:50:38 <danieli> all right, then I don't see why it can't be moved to community
2018-12-20 14:53:52 <yangxuan> ddevault: hi, are you Drew DeVault?
2018-12-20 14:57:17 <ddevault> yangxuan: yes
2018-12-20 15:00:42 <yangxuan> ddevault: I want to do some modification for ibus alpine package
2018-12-20 15:00:51 <ddevault> please, go right ahead
2018-12-20 15:01:10 <yangxuan> remove this line: https://github.com/alpinelinux/aports/blob/master/testing/ibus/APKBUILD#L51
2018-12-20 15:01:32 <ddevault> seems fair
2018-12-20 15:01:59 <ddevault> that should be install-pkgconfigDATA, I think
2018-12-20 15:02:16 <ddevault> this probably came from the arch package because I'm dumb
2018-12-20 15:02:57 <yangxuan> after remove this will keep pkg file, and some package like ibus-libpinyin need it for compiling
2018-12-20 15:03:09 <ddevault> ack
2018-12-20 15:05:25 <yangxuan> if you are ok with this, I will create a PR later
2018-12-20 15:05:48 <ddevault> if you don't mind, can you use git send-email to send it to the aports list with me on the Cc?
2018-12-20 15:07:02 <yangxuan> sure
2018-12-20 15:07:05 <ddevault> cheers
2018-12-20 15:27:43 <wener> yangxuan: Chinese ? would you like to join the qq group 558299436 ?
2018-12-20 15:28:28 <danieli> I did not know that group was a thing
2018-12-20 15:32:24 <wener> I can't find any alpinelinux fan community in China, so I create this one, hope I can solve some problems for those who want to know more to try alpine.
2018-12-20 15:32:55 <ncopa> yangxuan: i can move linux-amlogic to community but i will depend on someone else maintaning it
2018-12-20 15:33:12 <ncopa> eg, provide patches/bugfixes for the stable branch
2018-12-20 15:35:13 <yangxuan> ncopa: what kind of patches
2018-12-20 15:35:37 <ncopa> bugfixes if needed, security fixes
2018-12-20 15:35:41 <ncopa> or general updates
2018-12-20 15:35:51 <ncopa> most linux updates are security updates
2018-12-20 15:36:04 <ncopa> even if there are no CVE
2018-12-20 15:37:07 <SpaceToast> generally speaking, a maintainer is supposed to keep a package up to date, backport security fixes into releases, and fix issues users may have with the packages they maintain
2018-12-20 15:41:42 <ddevault> setting up notifications for new releases on my packages is on my todo list...
2018-12-20 15:41:51 <yangxuan> well, I'm not so experienced, but since it's basically mainline, after linux-vanilla upgrade to 4.19, maybe we can take necessary security update from it
2018-12-20 15:41:58 <ddevault> but if there's a willing user who wants to make a patch I'd rather let them to familiarize them with the process and make a new contributor
2018-12-20 15:42:54 <SpaceToast> ddevault: for any packages that are on github, they recently added an option to "watch" repositories for releases only
2018-12-20 15:43:03 <SpaceToast> (prior to that I was using gitpunch)
2018-12-20 15:43:04 <ddevault> nice
2018-12-20 15:43:55 <wener> Hope there is tool like brew bump-formula-pr, can reduce most of work
2018-12-20 15:44:28 <ddevault> cd some/package/, vim APKBUILD, /pkgver, $^a, :wq
2018-12-20 16:15:23 <ncopa> yangxuan: yes, but you have a number of patches too. what happens if your patches no longer apply due to changes in upstream?
2018-12-20 16:15:44 <ncopa> it may or may not be trivial to resolve those conflicts
2018-12-20 16:16:14 <ncopa> what i am saying is that I don't have the capacity to do that kind of work for the stable branch
2018-12-20 16:32:40 <ncopa> yangxuan: are you willing to take this responsibility? im warning that it may take some time and may not be trivial
2018-12-20 16:32:48 <ncopa> i've learned that the hard way...
2018-12-20 16:48:49 <yangxuan> ncopa: then maybe it's okay keep linux-amlogic in testing
2018-12-20 17:03:02 <mm9899> who would i speak to about some general questions? or email. thanks
2018-12-20 17:03:43 <ddevault> just ask your questions
2018-12-20 17:03:45 <danieli> mm9899: #alpine-linux and alpine-user@lists.alpinelinux.org
2018-12-20 17:03:56 <danieli> if it's related to alpine development, this channel, or alpine-devel@lists.alpinelinux.org
2018-12-20 17:04:54 <mm9899> cool, thank you.
2018-12-20 17:15:55 <mps> danieli: ncopa: thanks for explanation about sending patches and adding issues on bugs.d.o
2018-12-20 17:25:47 <mps> btw, I see a lot of patches on the patchwork.a.o without corresponding issues on bugs.a.o so I had impression (wrong, looks like) that the patches are enough
2018-12-20 17:26:33 <danieli> makes it a little harder to track target versions and stuff, but far from impossible
2018-12-20 17:28:51 <mps> danieli: understand, just wanted to explain my POV, and I always thought that is better not to pollute workflow services with duplicate (some kind of) writings
2018-12-20 17:30:00 <mps> actually I thought to add issue but hesitate just because of that
2018-12-20 20:21:19 <ncopa> mps: in general: if you want your fix in stable branch, then create an issue with target 3.8.x
2018-12-20 20:21:39 <ncopa> i normally check the bugs, but i ofetn forgot to check patchwork
2018-12-20 20:24:41 <mps> ncopa: didn't thought that the change to /etc/mdev.conf should be applied to stable, but after your post think 'why not'.
2018-12-20 20:25:22 <mps> will keep in mind that for future
2018-12-20 20:27:03 <ncopa> i mean, *specially* if you dont want your issue be forgotten when i tag stable release
2018-12-20 20:30:16 <mps> ah, ok. maybe two bugs, one for stable and one for edge :)
2018-12-20 20:34:14 <ncopa> we copy security bugs for every branch that is affected, but im not too happy with it
2018-12-20 20:34:41 <ncopa> i wish we had a beetter way to tell which branch a given issue affect
2018-12-20 20:37:07 <mps> well, security issues are special and need special care, but feature requests could be applied or backported by it's usefulness
2018-12-20 20:38:06 <ncopa> yeah
2018-12-20 20:38:35 <ncopa> for other bugs i prefer to only create a single issue with target version set to the lowest branch its wanted for
2018-12-20 20:39:17 <mps> do you by 'lowest branch' mean lowest release version?
2018-12-20 20:39:44 <ncopa> yes, so if you for example have a fix that we need apply to v3.7
2018-12-20 20:39:52 <ncopa> then you sent target to v3.7.x
2018-12-20 20:39:56 <ncopa> set*
2018-12-20 20:40:33 <ncopa> then i will fix it in master, backport it to v3.8 and backport it from there to v3.7
2018-12-20 20:40:54 <ncopa> commit message in master will have "ref #<issuenum>"
2018-12-20 20:40:59 <ncopa> same with 3.8-stable
2018-12-20 20:41:20 <ncopa> and 3.7-stable i change it to "fixes #<issuenum>"
2018-12-20 20:41:22 <mps> ah, understand. I had a 'fear' that the just important bug fixes are 'backported' but features goes only in edge (next stable)
2018-12-20 20:41:39 <ncopa> correct
2018-12-20 20:42:02 <ncopa> but sometimes a fix is required for older
2018-12-20 20:43:21 <mps> yes, understand for fixes, it should be backported, but new features are probably examined by their importance
2018-12-20 20:43:35 <mps> s/it/they/
2018-12-20 20:43:35 <alpine-meetbot> mps meant to say: yes, understand for fixes, they should be backported, but new features are probably examined by their importance
2018-12-20 20:46:19 <ncopa> yes, we normally dont backport new features
2018-12-20 20:47:53 <mps> ofc, it would require a lot of work. better is for users to just upgrade to newer release
2018-12-20 20:50:21 <mps> if the manpower for AL increase a lot some day in future (I hope it will) than maybe could be done more for backporting some packages or features
2018-12-20 21:54:46 <ncopa> does this release notes look ok? http://wwwtest.alpinelinux.org/posts/Alpine-3.8.2-released.html
2018-12-20 21:54:57 <_ikke_> reading..
2018-12-20 21:56:48 <ncopa> looks like git shortlog got a horizontal scrollbar
2018-12-20 21:57:02 <ncopa> shows importance of having nice commit messages ;)
2018-12-20 21:57:42 <_ikke_> :)
2018-12-20 21:58:08 <_ikke_> community/postgresql-bdr-extension0.9: downgrade to 0.9.0 to maintain compatibility with earlier Alpine versions
2018-12-20 21:59:40 <_ikke_> ncopa: looks alright
2018-12-21 04:15:06 <ddevault> starting to put together an install procedure https://git.sr.ht/~sircmpwn/alpine-riscv-bootstrap
2018-12-21 04:15:45 <danieli> argh, i accidentally hit a button in protonmail and it sent some crap to alpine-devel
2018-12-21 04:15:46 <danieli> oh well
2018-12-21 04:17:17 <ddevault> still not sure what to do about the kernel...
2018-12-21 04:18:15 <ddevault> aside
2018-12-21 04:18:26 <ddevault> this script is POSIX shell, whereas lots of alpine scripts use dash extensions
2018-12-21 04:18:38 <ddevault> in the future it might be wise to refactor those out of the rest
2018-12-21 08:05:51 <ncopa> chromium fails on armv7 too: /home/ncopa/aports/community/chromium/src/chromium-71.0.3578.98/tools/gn/base/numerics/safe_conversion
2018-12-21 08:05:52 <ncopa> s.h:17:10: fatal error: base/numerics/safe_conversions_arm_impl.h: No such file or directory
2018-12-21 08:05:52 <ncopa>  #include "base/numerics/safe_conversions_arm_impl.h"
2018-12-21 08:05:52 <ncopa>           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2018-12-21 10:50:42 <terra> I was able to install each added build dependencies in APKBUILD by running "abuild deps" for each time. But ,it seems this doesn't work anymore.
2018-12-21 10:51:42 <terra> I have to do "abuild undeps" and then "abuild deps" for newly added each build deps in APKBUILD.
2018-12-21 10:52:13 <danieli> i remember seeing something about adding to virtual packages a while ago, don't remember what it was though
2018-12-21 10:52:29 <terra> This issue becomes really annoying when making a new package for Alpine.
2018-12-21 10:53:35 <terra> danieli: is that about me?
2018-12-21 10:56:50 <danieli> terra: it might be relevant to it
2018-12-21 10:56:53 <danieli> perhaps you remember ncopa?
2018-12-21 10:59:10 <terra> I thought this issue might be fixed soon because I'm not the only one who involves with packages.
2018-12-21 13:19:13 <ncopa> terra: I have noticed it too, and yes it is slightly annoying. May be fabled can help us fix it.
2018-12-21 13:19:50 <ncopa> I haven’t get annoyed enough to take a look at it myself, yet
2018-12-21 13:38:46 <terra> ncopa: thanks for reply. hope we get it fixed.
2018-12-21 15:36:12 <jwh> i know I'm a real pest, but can someone merge my PR now? :D
2018-12-21 15:37:28 <danieli> which one...?
2018-12-21 15:37:37 <jwh> 5706
2018-12-21 15:37:42 <danieli> which is?
2018-12-21 15:37:48 <jwh> traefik, new aport
2018-12-21 15:37:51 <danieli> aha
2018-12-21 15:37:52 <jwh> been approved
2018-12-21 15:38:03 <jwh> my other one needs review by the maintainer
2018-12-21 15:38:16 <danieli> 333 PRs
2018-12-21 15:38:22 <jwh> crazy huh
2018-12-21 15:38:39 <jwh> need more reviewers and stuff
2018-12-21 15:38:40 <danieli> usually I'd suggest to wait your turn, but it's understandably pretty painful
2018-12-21 15:38:49 <jwh> I know :(
2018-12-21 15:39:03 <jwh> I'm just impatient to get stuff moved to alpine and see what other stuff I need to submit
2018-12-21 15:39:03 <SpaceToast> jwh: go to patchwork and scroll to the bottom, look at the dates and such ;)
2018-12-21 15:39:19 <jwh> oh patchwork
2018-12-21 15:39:29 <danieli> you *could* set up a mirror if you must have things in alpine quickly
2018-12-21 15:39:35 <danieli> that's probably the better option
2018-12-21 15:39:41 <jwh> googling "alpine patchwork" did not return the expected results
2018-12-21 15:39:44 <danieli> patchwork.a.o
2018-12-21 15:39:47 <jwh> however I have founda new duvet
2018-12-21 15:40:10 <jwh> yeah I was trying to avoid local repos heh
2018-12-21 15:40:34 <jwh> how come theres so many, just not enough reviewers/committers?
2018-12-21 15:43:12 <SpaceToast> more or less
2018-12-21 15:43:28 <SpaceToast> that and the current methodology doesn't scale very well
2018-12-21 15:43:36 <jwh> oh?
2018-12-21 15:43:37 <SpaceToast> (which is why changing up the infra comes up relatively often)
2018-12-21 15:44:01 <SpaceToast> well, with patchwork as an example - let's say you have a series of patches (1/5 - 5/5)
2018-12-21 15:44:07 <jwh> yeah
2018-12-21 15:44:09 <SpaceToast> applying them will take 5 sets of actions
2018-12-21 15:44:16 <SpaceToast> get patch 1, git am, repeat for 2-5
2018-12-21 15:45:13 <danieli> traefik runs
2018-12-21 15:45:14 <jwh> yeah
2018-12-21 15:45:25 <jwh> danieli: it should do :D
2018-12-21 15:46:03 <danieli> i like the attitude from it, "Built:        I don't remember exactly"
2018-12-21 15:46:10 <jwh> heh
2018-12-21 15:48:26 <clandmeter> jwh, did you check if check runs any tests?
2018-12-21 15:49:18 <jwh> well, it does stuff... I'm not really a go man
2018-12-21 15:49:33 <danieli> ?       github.com/containous/traefik   [no test files]
2018-12-21 15:49:37 <jwh> yea
2018-12-21 15:49:39 <jwh> thats it D
2018-12-21 15:49:40 <jwh> :D
2018-12-21 15:50:17 <jwh> I took that as there aren't any, or they're not hooked up, but left it there in case they are in the future
2018-12-21 15:50:27 <clandmeter> i think it doesnt do anything
2018-12-21 15:50:32 <danieli> seems like a noop
2018-12-21 15:50:41 <clandmeter> so its better to to explicitly mention it
2018-12-21 15:50:58 <clandmeter> ill disable them and wrap longer lines
2018-12-21 15:51:02 <danieli> "You can run unit tests using the test-unit target and the integration test using the test-integration target."
2018-12-21 15:51:07 <jwh> ah
2018-12-21 15:51:39 <danieli> I'll test it
2018-12-21 15:52:04 <jwh> I've tested in semi production, seems ok, but I didn't spot the test-unit target
2018-12-21 15:56:17 <clandmeter> jwh, i pushed it. if you can find a way to properly include tests please do.
2018-12-21 15:56:32 <danieli> jwh: I just did, I'll pass you a patch
2018-12-21 15:56:40 <jwh> oh cool
2018-12-21 15:56:41 <jwh> ok
2018-12-21 15:56:46 <danieli> it does however complain at CGO
2018-12-21 15:57:02 <danieli> clandmeter: i just disable it [cgo], right?
2018-12-21 15:57:21 <jwh> go is a total nightmare tbh
2018-12-21 15:57:46 <clandmeter> danieli, i dont know what goes wrong. i didnt try the tests
2018-12-21 15:58:01 <danieli> the CGO thing is a different issue with PIE on alpine iirc
2018-12-21 15:58:11 <clandmeter> it was fixed afaik?
2018-12-21 15:58:19 <danieli> i think we just disabled cgo
2018-12-21 15:58:37 <clandmeter> didnt ncopa find some issue with cgo some time ago
2018-12-21 15:58:54 <danieli> for some reason the issue got resurrected recently-ish, he fixed it in docker i think
2018-12-21 15:59:07 <clandmeter> introduced by some local change by one of our devs
2018-12-21 16:00:11 <danieli> jwh: http://tpaste.us/mZqd
2018-12-21 16:00:33 <danieli> runs the unit and integration tests successfully
2018-12-21 16:00:40 <jwh> cool ok
2018-12-21 16:01:02 <clandmeter> want me to add those?
2018-12-21 16:01:26 <danieli> that'd probably be neat, it successfully runs all the applicable tests on my box
2018-12-21 16:06:01 <ddevault> it looks like shadow-4.5-r1 is in aports but r0 is in community
2018-12-21 16:06:04 <ddevault> can someone look into that?
2018-12-21 16:06:50 <clandmeter> ?
2018-12-21 16:06:59 <ddevault> err
2018-12-21 16:07:07 <ddevault> that's my local, patched aports, apparently
2018-12-21 16:07:09 <ddevault> disregard
2018-12-21 16:07:59 <clandmeter> i didnt see a thing
2018-12-21 16:10:04 <mort___> n00b alpine dev here - after being pointed to it by ncopa, was looking through the list of failed reports on buildozer for 3.9 and picked out seabios at random. looks like the `source` download URL has changed and the current checksum is of the index page the 301 redirect points to rather than the tarball. is anyone else fixing already? if not, i'll try and produce my first patch :)
2018-12-21 16:12:48 <clandmeter> go for it
2018-12-21 16:13:19 <mort___> ta. btw, does anyone have/recommend an emacs mode for APKBUILD files?
2018-12-21 16:13:31 <ddevault> I set vim to ft=sh (shell script)
2018-12-21 16:13:32 <danieli> they're just shell scrits
2018-12-21 16:13:35 <danieli> scripts*
2018-12-21 16:13:47 <danieli> so shell mode should be fine
2018-12-21 16:13:57 <danieli> er, you know what I meant
2018-12-21 16:14:13 <danieli> sh mode
2018-12-21 16:14:48 <jwh> clandmeter: thanks
2018-12-21 16:15:19 <jwh> just need litespeed reviewed and whatnot now then I can move my first project over :D
2018-12-21 16:15:32 <jwh> and no doubt uncover other things to fix/add
2018-12-21 16:15:51 <mort___> danieli: oh yes, thanks, will do that.
2018-12-21 16:16:53 <danieli> jwh: looks like there have been multiple PRs for cockroach, by cockroach devs
2018-12-21 16:16:55 <clandmeter> mort___, if they are small patches please tpaste them here. while im online i can apply them if they are related to current build breakage.
2018-12-21 16:17:01 <jwh> danieli: oh?
2018-12-21 16:17:14 <danieli> #1183 and #2757
2018-12-21 16:17:21 <jwh> I do have an issue open on cockroach and there are numerous problems
2018-12-21 16:17:24 <danieli> goddarn it, not bugs, algitbot
2018-12-21 16:17:24 <mort___> clandmeter: sure; tpaste?
2018-12-21 16:17:36 <clandmeter> mort___, its our own paste service
2018-12-21 16:17:40 <danieli> mort___: http://tpaste.us
2018-12-21 16:17:43 <ddevault> can we consider moving py-beautifulsoup and py-flask-login into community?
2018-12-21 16:17:45 <clandmeter> apk add tpaste
2018-12-21 16:17:48 <danieli> `apk add tpaste` and `cat file | tpaste`
2018-12-21 16:17:52 <jwh> some are being fixed, others need more work
2018-12-21 16:17:54 <mort___> ah ok, thanks!
2018-12-21 16:18:04 <clandmeter> or redirect :)
2018-12-21 16:18:16 <jwh> danieli: ah yes, thats the guy
2018-12-21 16:18:50 <ddevault> also, maybe, pygfm
2018-12-21 16:19:43 <jwh> danieli: https://github.com/cockroachdb/cockroach/issues/32613
2018-12-21 16:19:53 <jwh> I haven't had time to look at it though
2018-12-21 16:20:26 <danieli> oh, they're using jemalloc
2018-12-21 16:20:30 <mort___> clandmeter: http://tpaste.us/RgEr — or did you want it formatted as a patch?
2018-12-21 16:20:31 <jwh> yup
2018-12-21 16:20:51 <jwh> but... their binaries build and work just fien
2018-12-21 16:20:54 <jwh> fine*
2018-12-21 16:20:55 <ncopa> mort___: as patch: git format-patch -1 --stdout | tpaste
2018-12-21 16:21:05 <ncopa> then we can do: curl $url | git am
2018-12-21 16:21:15 <mort___> ncopa: gotcha thanks
2018-12-21 16:21:17 <mort___> clandmeter: http://tpaste.us/9gPK
2018-12-21 16:21:25 <jwh> oh thats convenient
2018-12-21 16:21:34 <danieli> jwh: :)
2018-12-21 16:21:48 <danieli> mort___: wonderful!
2018-12-21 16:21:53 <ncopa> clandmeter: i'll push it
2018-12-21 16:22:17 <ncopa> mort___: thanks!
2018-12-21 16:22:28 <mort___> np, ta!
2018-12-21 16:24:15 <jwh> danieli: so yeah, theres nothing I can really do for cockroach
2018-12-21 16:24:48 <danieli> clandmeter: how come jemalloc was broken again? I think the cockroachdb people were hitting their head in the wall on that one
2018-12-21 16:24:57 <danieli> we moved it to unmaintained
2018-12-21 16:25:05 <jwh> they bundle their own jemalloc
2018-12-21 16:25:20 <jwh> or at least a copy is pulled, it doesn't use system jemalloc
2018-12-21 16:25:22 <danieli> yeah but i believe it [jemalloc] was broken
2018-12-21 16:25:26 <jwh> ah, yeah
2018-12-21 16:25:38 <jwh> supposedly it was fixed at some point
2018-12-21 16:30:58 <clandmeter> i think jemalloc failed on some archs
2018-12-21 16:31:17 <clandmeter> and there was no pkg depending on it
2018-12-21 16:31:28 <clandmeter> i think we prefer musl malloc
2018-12-21 16:31:37 <jwh> most software seems to bundle it if they use it
2018-12-21 16:34:09 <clandmeter> ddevault, do you want to take maintainership?
2018-12-21 16:34:54 <clandmeter> not sure what the current status of those ports are
2018-12-21 16:37:40 <SpaceToast> I personally don't mind jemalloc (esp. relative to glibc), but musl malloc is excellent as well, so I don't usually use it.
2018-12-21 16:38:20 <jwh> jemalloc is pretty fast and its portable, likely why they chose it
2018-12-21 16:38:25 <SpaceToast> jwh: I think they bundle it because things like tracking/debug modes are build-time
2018-12-21 16:38:29 <jwh> yeah
2018-12-21 16:38:34 <danieli> not portable enough apparently
2018-12-21 16:38:36 <SpaceToast> so you can't depend on upstream having your debugging setup
2018-12-21 16:38:38 <jwh> danieli: heh quie
2018-12-21 16:38:41 <jwh> quite*
2018-12-21 16:39:38 <jwh> there must be other packages which bundle it though, so
2018-12-21 16:39:57 <SpaceToast> I think firefox bundles their own copy
2018-12-21 16:40:04 <danieli> we removed it from the deps of one or two packages and configured them not to use jemalloc
2018-12-21 16:40:17 <danieli> jemalloc is in unmaintained/ atm
2018-12-21 16:40:17 <jwh> or maybe they're just using it wrong and it doesn't show up on their build env
2018-12-21 16:40:29 <jwh> danieli: well I mean bundled copies
2018-12-21 16:40:31 <jwh> rather than deps
2018-12-21 16:40:46 <danieli> even then you can often configure the software to use system malloc
2018-12-21 16:40:50 <jwh> yeah
2018-12-21 16:41:09 <ddevault> clandmeter: sure
2018-12-21 16:41:14 <ddevault> they work, I use them out of testing
2018-12-21 16:41:16 <jwh> tbh though in those cases I'd err on the side of caution, likely not that well tested with system malloc if they default to je
2018-12-21 16:42:15 <danieli> if you depend on advanced and implementation-specific detail;s, sure
2018-12-21 16:42:33 <mps> can't remember exact number, but few days ago there were discussion about jemalloc and why it is moved to unmaintained
2018-12-21 16:42:39 <danieli> yes
2018-12-21 16:45:52 <mps> jwh: try to replace jemalloc with musl malloc in your package
2018-12-21 16:46:09 <danieli> nah, we're discussing something else
2018-12-21 16:46:20 <mps> ah, sorry then
2018-12-21 17:13:15 <danieli> man, python 3.7 is going to require a rebuild of so many damn packages
2018-12-21 17:13:28 <danieli> considering we've gone from libressl to openssl, we can get py3.7
2018-12-21 17:38:40 <ncopa> i dont want to do that til after v3.9
2018-12-21 17:38:46 <ncopa> or 3.9 will never get out
2018-12-21 17:40:45 <mort___> fwiw am taking a look at smokeping atm (#8777)
2018-12-21 17:41:06 <mort___> as it looked like it was on the 3.9 list (but tell me if i misinterpreted that!)
2018-12-21 17:44:04 <ncopa> ah, great!
2018-12-21 17:44:15 <ncopa> woudl be great to have that fixed before 3.9
2018-12-21 17:44:41 <ncopa> as you see it was on the 3.8 list too, but got postponed
2018-12-21 17:46:55 <mort___> mostly builds ok, bloomin' CPAN packages giving me a pain atm
2018-12-21 17:47:34 <mort___> one package complaining another is not installed a couple of lines after claiming the other package *was* successfully installed
2018-12-21 17:49:02 <tdtrask> danieli: was your protonmail message just a mistake, or was there something you wanted to say about acf?
2018-12-21 17:51:47 <SpaceToast> tdtrask: it was just a mistake, they mentioned it here right after sending it by accident
2018-12-21 17:53:42 <tdtrask> ok, thanks
2018-12-21 17:56:42 <ncopa> mort___: im not surprised
2018-12-21 17:56:49 <ncopa> be glad its not ruby....
2018-12-21 17:56:52 <ncopa> :)
2018-12-21 17:57:00 <mort___> !
2018-12-21 17:57:02 <mort___> :)
2018-12-21 17:57:23 <ncopa> we used to package all the deps for redmine
2018-12-21 17:57:31 <mort___> honestly.
2018-12-21 17:57:33 <ncopa> complete pain to maintain
2018-12-21 17:57:40 <mort___> …Successfully installed Net-SSLeay-1.85
2018-12-21 17:57:40 <mort___> ! Installing the dependencies failed: Module 'Mozilla::CA' is not installed, Module 'Net::SSLeay' is not installed
2018-12-21 17:57:40 <mort___> ! Bailing out the installation for IO-Socket-SSL-2.060.
2018-12-21 17:57:40 <mort___> Successfully installed Mozilla-CA-20180117
2018-12-21 17:58:19 <ncopa> do you have perl-net-ssleay in depends?
2018-12-21 17:58:35 <mort___> ooh, no
2018-12-21 17:58:47 <ncopa> or perl-io-socket-ssl
2018-12-21 17:58:49 <mort___> trying that
2018-12-21 17:59:12 <ncopa> i think its perl-io-socket-ssl it needs and perl-net-ssleay is dep of perl-io-socket-ssl
2018-12-21 17:59:25 <ncopa> but we are currently having issues with those
2018-12-21 17:59:34 <mort___> ok plausible
2018-12-21 17:59:39 <ncopa> the testsuite for perl-io-socket-ssl hangs
2018-12-21 17:59:42 <ncopa> occationally
2018-12-21 17:59:57 <mort___> this is for the thirdparty subdir in smokeping
2018-12-21 18:00:07 <mort___> which installs dependent CPAN modules with `—notest`
2018-12-21 18:00:35 <ncopa> i never figured out what the problem with perl-io-socket-ssl is, but i have a feeling problem is in perl-net-ssleay
2018-12-21 18:00:46 <ncopa> we had other perl package that also hung
2018-12-21 18:00:58 <ncopa> perl-net-server or similar. dont remember exactly
2018-12-21 18:00:58 <mort___> i was searching around earlier, it looked like homebrew had pinned it down to something to do with TLS1.3
2018-12-21 18:01:10 <ncopa> and openssl 1.1.1
2018-12-21 18:01:17 <mort___> yeah
2018-12-21 18:01:33 <ncopa> i grabbed some patches from fedora, that i thought would fix it
2018-12-21 18:01:46 <ncopa> and the tests passed in my work machine
2018-12-21 18:01:56 <ncopa> but some of the builders still hung
2018-12-21 18:02:20 <ncopa> so i have disabled the testsuite for perl-io-socket-ssl for now
2018-12-21 18:02:24 <ncopa> to unblock the builders
2018-12-21 18:03:34 <ncopa> i also saw that there was another repo with perl-net-ssleay version 1.86, but im not sure if its a fork or the project got new official maintainer....
2018-12-21 18:12:12 <mps> clamsmtp fails on builders because source site is down
2018-12-21 18:12:56 <mps> is it ok to add source from somewhere else, debian archive for example?
2018-12-21 18:14:08 <mps> ncopa: perl-io-socket-ssl passed test in local machine with 'abuild check'
2018-12-21 18:15:34 <danieli> tdtrask: it sent the protonmail crap by accident, but dent the correct answer to the original poster - to;dr is "wrong list, and ask them, not us"
2018-12-21 18:21:02 <mps> procmail source is missing on the ftp://ftp.informatik.rwth-aachen.de/pub/packages/procmail/
2018-12-21 18:22:29 <ncopa> its weekend for me now
2018-12-21 18:22:46 <danieli> I'll be here all weekend, I don't really do holidays
2018-12-21 18:22:56 <ncopa> have a nice weekend everyone, and thanks for great work this week
2018-12-21 18:23:09 <SpaceToast> the holiday I celebrate is actually today, but I didn't manage to get off work ^^;;
2018-12-21 18:23:15 <SpaceToast> see you ncopa \o
2018-12-21 18:23:21 <danieli> you too, take a break - you definitely deserve it ncopa
2018-12-21 18:28:41 <mort___> if anyone isn't taking a well-deserved break :) smokeping upgrade builds now, but fails on install
2018-12-21 18:28:49 <mort___> where do i start looking for things like
2018-12-21 18:28:49 <mort___> >>> ERROR: smokeping*: Arch specific binaries found so arch must not be set to "noarch"
2018-12-21 18:28:49 <mort___> >>> ERROR: smokeping*: prepare_package failed
2018-12-21 18:28:49 <mort___> >>> ERROR: smokeping: rootpkg failed
2018-12-21 18:29:04 <mort___> ah, arch var
2018-12-21 18:29:35 <mort___> nm
2018-12-21 18:36:03 <mort___> ok smokeping.2.7.3 package built ok afaics
2018-12-21 18:39:53 <mort___> http://tpaste.us/zBla
2018-12-21 18:40:02 <mort___> i'll try and put a proper patch in
2018-12-21 18:40:12 <mort___> but will be later / over the w/e as i really ought to go home now
2018-12-21 18:54:37 <mort___> ok i think that sent
2018-12-21 21:55:39 <andypost> clandmeter, sec upgrade https://github.com/alpinelinux/aports/pull/5886 I bet it needs backport
2018-12-22 00:13:17 <SpaceToast> hey fcolista, latest lxd fails (it's missing libdqlite.so.0) - likely due to clustering (which uses distributed sql) being a thing now
2018-12-22 00:14:14 <SpaceToast> I don't see dqlite being worked on in your user-aports, so perhaps you hadn't noticed
2018-12-22 07:58:11 <danieli> SpaceToast: we are painfully aware of it
2018-12-22 07:58:25 <SpaceToast> ok, ty :)
2018-12-22 07:58:35 <SpaceToast> I use lxd (and am planning to use clustering) in my infra, both at home and work
2018-12-22 07:58:38 <SpaceToast> so it's quite important for me
2018-12-22 07:58:48 <danieli> it's a can of worms, that dqlite and patched sqlite
2018-12-22 07:58:54 <SpaceToast> aye :/
2018-12-22 07:59:15 <SpaceToast> at least their choice of gossip alg was good :) (serf is awesome)
2018-12-22 09:32:50 <TBB> gotta love lxd, even though its commandline client could use some improvements like ... return codes :)
2018-12-22 16:03:19 <fcolista> ncopa, I've a strange issue with latest LXC: https://dpaste.de/wZNo
2018-12-22 16:03:39 <fcolista> this is the APKBUILD:https://dpaste.de/wA8s/raw
2018-12-22 16:04:28 <fcolista> the issue is that latest LXD ships his own version of sqlite (with replication patche) and  dqlite
2018-12-22 16:04:44 <fcolista> dqlite to be compiled needs sqlite with replication patches
2018-12-22 16:05:18 <fcolista> to build sqlite with replication i've issue because it does not find sqlite3.h headers (even if sqlite-dev is among makedepends).
2018-12-22 16:06:08 <fcolista> So I went ahead with this APKBUILD, since managing multple packages that needs to be updated with version constraints is a pain from manintenance perspective
2018-12-22 16:06:15 <fcolista> but I never seen this error before
2018-12-23 08:13:41 <wener> ncopa: hi, I'd like to maintain some packages current in testing, should I just move to community or some else to do this ?
2018-12-23 08:47:11 <wener> https://github.com/alpinelinux/aports/pull/5893 failed due to make: execvp: /bin/sh: Argument list too long
2018-12-23 08:47:17 <wener> how to fix this ?
2018-12-23 10:21:54 <danieli> i was just working on ports for a bunch of cloud software, including grpc - i'll see if i ran into that
2018-12-23 10:22:58 <danieli> when i've seen that, it's the kernels ARG_MAX
2018-12-23 10:35:33 <wener> danieli: but I can build this on my host
2018-12-23 11:16:50 <kaniini> the CI kernel may have a smaller ARG_MAX
2018-12-23 11:20:55 <danieli> that sounds plausible
2018-12-23 19:59:53 <mps> clandmeter: here is clamsmtp source fix https://patchwork.alpinelinux.org/patch/4330/
2018-12-23 20:00:17 <mps> source url, I mean
2018-12-23 20:01:58 <mps> there are a lot of fail reports for clamsmtp on #alpine-commits
2018-12-23 20:06:52 <clandmeter> I'm about to take off, literally. So maybe later.
2018-12-23 20:07:04 <_ikke_> o/
2018-12-23 20:07:35 <mps> np
2018-12-23 22:56:17 <ollieparanoid[m]> has anyone had problems with the latest util-linux in alpine edge? it seems that openrc doesn't want to boot some of our devices anymore: https://gitlab.com/postmarketOS/pmaports/issues/156 (note that we use another initfs script, not the same one as Alpine - but the problem seems to appear later when openrc runs)
2018-12-23 22:59:12 <SpaceToast> ollieparanoid[m]: I had my email server get stuck in openrc (after caching service dependencies) after an edge update
2018-12-23 22:59:32 <SpaceToast> I never figured out what it was though, because I was in a hurry to get it back to erm... functioning
2018-12-23 22:59:36 <SpaceToast> so perhaps I've experienced this as well
2018-12-23 22:59:54 <ollieparanoid[m]> that was two days ago or so?
2018-12-23 23:00:08 <SpaceToast> no, closer to a monthish ago
2018-12-23 23:00:22 <ollieparanoid[m]> SpaceToast: do you remember where it got stuck, and how did you get it working again?
2018-12-23 23:00:38 <SpaceToast> it got stuck after printing "Caching service dependencies"
2018-12-23 23:00:47 <SpaceToast> not sure if it was on that, or on the service after that (with just no output)
2018-12-23 23:00:56 <SpaceToast> I got it working by rebooting into a rescue environment and downgrading to 3.8 :)
2018-12-23 23:01:21 <SpaceToast> (since I didn't know what package was causing issues, I figured I'd just go all the way back)
2018-12-23 23:01:31 <SpaceToast> that did break my webmail but I didn't use it anyway
2018-12-23 23:01:32 <ollieparanoid[m]> SpaceToast: great fix ;D I see, thanks!
2018-12-23 23:01:42 <SpaceToast> no worries, good luck figuring this one out!
2018-12-23 23:02:00 <ollieparanoid[m]> thanks :)
2018-12-24 12:03:45 <ncopa> im am setting the v3.9 builders to continue on errors
2018-12-24 12:03:57 <ncopa> so we can collectd a list of packages that fails
2018-12-24 12:07:50 <danieli> nice, I'd love a piece of the list to fix some stuff
2018-12-24 12:27:22 <clandmeter> ncopa, it would be nice if we could ask algitbot the list.
2018-12-24 12:31:44 <clandmeter> i checked it some time ago, but it seems there is currently no glue to make it happen from the builders.
2018-12-24 12:35:59 <ncopa> its sort of nontrivial
2018-12-24 12:36:01 <ncopa> and hackish
2018-12-24 12:36:37 <ncopa> i think we better spend the energy for that for the build infra rewrite
2018-12-24 12:37:35 <_ikke_> Do we already know what way we want to go with that?
2018-12-24 12:39:35 <danieli> as far as i know, we do not have anything more than rough ideas
2018-12-24 12:45:26 <mps> ncopa: some packages fails to build because of source urls are non functional, clamsmtp, procmail and possibly more
2018-12-24 12:46:23 <danieli> mps: i'll write a script to check all packages in aport
2018-12-24 12:46:30 <danieli> i have a feeling a couple will have broken sources
2018-12-24 12:46:49 <ncopa> abuild sourcecheck
2018-12-24 12:46:51 <mps> I posted one patch for clamsmtp (https://patchwork.alpinelinux.org/patch/4330/) changing source to Debian archive
2018-12-24 12:47:14 <mps> danieli: I thought to do that, also
2018-12-24 12:47:25 <ncopa> that may be one way to do it, but is that the official upstream?
2018-12-24 12:47:55 <mps> ncopa: no, upstream for clamsmtp is 'dead'
2018-12-24 12:48:03 <ncopa> ok
2018-12-24 12:48:08 <danieli> where do other distros pull from, debian archive?
2018-12-24 12:48:38 <ncopa> i think distros generally have their own archive
2018-12-24 12:48:52 <danieli> both arch and gentoo use the broken site
2018-12-24 12:48:57 <mps> danieli: well, didn't had better idea, if there are somewhere internet archive it would be preferred, ino
2018-12-24 12:49:09 <danieli> it must've broken fairly recently, or nobody uses clamsmtp on those OSes
2018-12-24 12:49:12 <mps> s/ino/imo/
2018-12-24 12:49:12 <alpine-meetbot> mps meant to say: danieli: well, didn't had better idea, if there are somewhere internet archive it would be preferred, imo
2018-12-24 12:50:22 <ncopa> i guess we should store it in our own archive
2018-12-24 12:50:28 <clandmeter> thats why i asked
2018-12-24 12:50:30 <ncopa> dev.alpinelinux.org/archive/
2018-12-24 12:50:30 <danieli> who has access to that, by the way?
2018-12-24 12:50:34 <clandmeter> we store it per branch
2018-12-24 12:50:37 <clandmeter> which breaks things
2018-12-24 12:50:41 <mps> it would be best idea to have Alpine source archive but someone have to set it
2018-12-24 12:51:20 <ncopa> danieli: people with git push access (i think)
2018-12-24 12:51:23 <clandmeter> ncopa, cant we just keep distfiles on a location wtih enough space?
2018-12-24 12:51:34 <clandmeter> and make builders prefer it?
2018-12-24 12:51:36 <danieli> sounds like it's loosely coupled to that
2018-12-24 12:52:02 <ncopa> i dont think it makes sense to store all the files indefinitively
2018-12-24 12:52:25 <ncopa> at least not edge
2018-12-24 12:52:36 <clandmeter> i dont think it makes sense to clean when you have enough space?
2018-12-24 12:52:40 <danieli> distfiles.a.o vs dev.a.o?
2018-12-24 12:53:01 <ncopa> distfiles is a "cache" of upstreams archives
2018-12-24 12:53:19 <ncopa> dev.a.o/archive is storage for our own projects tarballs
2018-12-24 12:53:25 <danieli> gotcha, good to know
2018-12-24 12:53:38 <ncopa> we also upload things there when we make git snapshots
2018-12-24 12:54:08 <danieli> i rarely see references to distfiles and dev, but i come across them once in a while
2018-12-24 12:54:27 <mps> ehm, didn't know for distfiles.a.o
2018-12-24 12:54:52 <ncopa> clandmeter: some of the projects like chromium and firefox eat lots of space, "enough space" can quickly become insane
2018-12-24 12:55:01 <mps> how long files are kept there
2018-12-24 12:55:23 <ncopa> mps: the vX.Y/ dirs are supposed to be kept forever
2018-12-24 12:55:36 <ncopa> or as long as we provide the release images and binary repos
2018-12-24 12:55:37 <danieli> mps: ever seen ancient.a.o referenced or mentioned?
2018-12-24 12:55:40 <danieli> :')
2018-12-24 12:55:45 <clandmeter> ncopa, currently we always bump into these issues.
2018-12-24 12:55:55 <danieli> this one dir 	2006-Sep-18 12:55:07
2018-12-24 12:56:05 <clandmeter> src is gone and we need to fix it.
2018-12-24 12:56:19 <mps> ok, now I can post patches for clamsmtp and procmail with source url on distfiles.a.o
2018-12-24 12:56:24 <clandmeter> while we could use our own cache.
2018-12-24 12:57:22 <ncopa> there are 2 sides of it
2018-12-24 12:57:48 <ncopa> one is the problem above, builder stop due to upstream is moved or gone
2018-12-24 12:57:55 <mps> sources for at least actively supported AL releases are fine, imo
2018-12-24 12:58:03 <ncopa> the second issue is to keep our APKBUILDs uptodate
2018-12-24 12:58:27 <ncopa> if upstream move to new location, we will want to detect that and fix APKBUILD to have new location
2018-12-24 12:58:46 <mps> danieli: no, first time see ancient.a.o mentioned
2018-12-24 12:59:02 <ncopa> which is the main reason I don't point the builders to distfiles by default
2018-12-24 12:59:03 <danieli> i can't think of any easy way to automatically 'detect' when upstream moves to new locations
2018-12-24 12:59:41 <clandmeter> sounds like a hack to fix apkbuild
2018-12-24 13:00:19 <ncopa> danieli: it should be easy enough to check if source is there or gives 404
2018-12-24 13:00:25 <ncopa> but it requires some scripting
2018-12-24 13:00:33 <danieli> right, detects whether it's broken or not, but not the actual new location
2018-12-24 13:00:34 <ncopa> and a cronjob or whatever
2018-12-24 13:00:49 <danieli> i'll write a demo script to check that
2018-12-24 13:01:06 <ncopa> i think thats good enough, to get a list of broken upstream source URLs
2018-12-24 13:01:20 <danieli> mm, i'll continue the code i started a while ago to do exactly that
2018-12-24 13:01:34 <ncopa> what I wonder is what we do when upstream disapears?
2018-12-24 13:01:41 <ncopa> what do we put in APKBUILD?
2018-12-24 13:02:03 <danieli> I'd say we keep the last version that was released
2018-12-24 13:02:14 <danieli> we shouldn't have to rebuild it, should we?
2018-12-24 13:02:21 <ncopa> even if host is gone?
2018-12-24 13:02:47 <ncopa> the info in APKBUILD is to tell where the upstream package is to be found
2018-12-24 13:02:57 <ncopa> we do rebuild ever 6 month
2018-12-24 13:03:06 <danieli> honestly, I'd say we move it to unmaintained in edge (and subsequent releases) and leave the last released version in the older releases
2018-12-24 13:03:06 <ncopa> for each stable release
2018-12-24 13:03:32 <ncopa> older stable releases does not need to rebuild
2018-12-24 13:03:44 <ncopa> and if it does, due to sec fix, then we should have it in the distfiles cache
2018-12-24 13:04:07 <ncopa> which is why we shouldnt remove it from distfiles/v3.x/
2018-12-24 13:04:20 <danieli> if upstream is gone, i'm in favor of just not having package X in subsequent releases, unless it's absolutely critical it exists because package Y depends on it
2018-12-24 13:04:38 <mps> if the package is accepted source should be put on archive
2018-12-24 13:05:09 <danieli> if sec issues show up and upstream literally is dead (there are no releases/fixes of the software), we should remove it imo
2018-12-24 13:05:10 <ncopa> mps: that is what im thinking too
2018-12-24 13:05:41 <ncopa> danieli: its not uncommon that distros still ship dead packages for some time, and add sec fixes themselves
2018-12-24 13:06:02 <danieli> it isn't uncommon, but it's a lot of extra work on a small team like alpine's
2018-12-24 13:06:07 <mps> even if upstream 'dies', changes license, make something bad, whatever, then there is last acceptable version to build
2018-12-24 13:06:13 <ncopa> and its normally possible to find patch from other distro
2018-12-24 13:06:57 <ncopa> i think the two alternatives we have are: move to unmaintained, or store it in our own archive (dev.a.o/archive/)
2018-12-24 13:07:25 <ncopa> but i'd like to keep the distfiles as a cache
2018-12-24 13:07:34 <danieli> i would honestly be in favor of leaving it in older releases (until unfixable or severe sec issues show up) and move to unmaintained in edge
2018-12-24 13:07:41 <mps> having archive is the safest, although that require a lot of disk space
2018-12-24 13:07:59 <danieli> if we have the disk space to waste on something like this, sure, go ahead I guess
2018-12-24 13:08:42 <mps> if I have fast link and some free big disks I would, for sure
2018-12-24 13:11:27 <mps> and, I don't think that the bad idea to use sources from other free distributions, like Debian for example. Till the AL manages to its own
2018-12-24 13:12:33 <mps> s/manages to/manages to setup/
2018-12-24 13:12:33 <alpine-meetbot> mps meant to say: and, I don't think that the bad idea to use sources from other free distributions, like Debian for example. Till the AL manages to setup its own
2018-12-24 20:37:59 <[[sroracle]]> If the APKINDEX contained the source URIs or repology was somehow otherwise made aware of them, you could offload dead link tracking to them
2018-12-24 20:59:22 <danieli> the apkbuilds do, but not the apkindex unfortunately
2018-12-24 21:14:31 <[[sroracle]]> Right... which is why I’m suggesting they could be put in the APKINDEX
2018-12-24 21:14:38 <[[sroracle]]> since that’s what repology looks at
2018-12-25 07:48:35 <yangxuan> what's the proper way to use aports/scripts/mkimage.sh?
2018-12-25 07:49:42 <yangxuan> always got Ignoring /media/usb/apks/aarch64/APKINDEX.tar.gz: UNTRUSTED signature
2018-12-25 10:26:24 <danieli> yangxuan: if you're trying to use apk on a repo you built yourself, you'll have to add your abuild signing key to /etc/apk/keys
2018-12-26 11:34:59 <_ikke_> Anyone having an issue with if we restart the x86 / x86_64 builders?
2018-12-26 11:59:46 <ncopa> i think its ok to reboot now
2018-12-26 12:01:28 <ncopa> its going down
2018-12-26 21:20:54 <[[sroracle]]> Those are already reserved keywords in 3.6 iirc
2018-12-26 21:21:49 <danieli> they existed in 3.6 but afaik they weren't made reserved until 3.7
2018-12-26 21:22:19 <danieli> pretty sure since i ran into issues with that with some code that worked on .6 but not .7 with a highly specific exception
2018-12-26 21:22:39 <danieli> they also changed some internal encoding stuff, which will be a little painful to fix on musl
2018-12-27 07:30:04 <fabled> woot
2018-12-27 07:30:14 <fabled> i think i figured out openjdk7 build fail on armv7
2018-12-27 07:31:27 <_ikke_> sounds good
2018-12-27 08:32:37 <ncopa> im working on 4.19 kernel configs
2018-12-27 08:32:45 <ncopa> will hopefully push those today
2018-12-27 08:49:52 <fabled> clandmeter, java/armv7 fix https://git.alpinelinux.org/cgit/aports/commit/?id=66a06a28
2018-12-27 08:50:23 <clandmeter> \o/
2018-12-27 08:50:45 <fabled> it was rather nasty to debug and find
2018-12-27 08:50:51 <fabled> fix was relatively simple as can be seen
2018-12-27 08:51:08 <_ikke_> dhcp-option=option:router,...
2018-12-27 08:51:21 <clandmeter> thats why we have you around, make the impossible possible :)
2018-12-27 08:51:51 <clandmeter> _ikke_, wrong window?
2018-12-27 08:51:54 <_ikke_> yes
2018-12-27 08:51:57 <clandmeter> :p
2018-12-27 11:56:31 <ncopa> Linux localhost 4.19.12-0-vanilla #1-Alpine SMP Thu Dec 27 09:24:40 UTC 2018 x86_64 Linux
2018-12-27 11:56:39 <ncopa> here comes 4.19...
2018-12-27 11:57:32 <danieli> choo choo
2018-12-27 12:32:12 <mps> maybe this will be good to have in 4.19.x https://lkml.org/lkml/2018/12/24/38
2018-12-27 12:34:12 <ncopa> those packages fails on x86 (32bit): http://tpaste.us/jXNm
2018-12-27 12:35:22 <ncopa> mps: i guess we get it with 9.19.13. seems like its added for stable too
2018-12-27 12:36:38 <mps> I think so, i.e. it will be in 4.19.13, but anyway mentioned it to not be forgotten
2018-12-27 14:31:36 <ncopa> kunkku: ping. i think I have a problem with lxc and dad.if-up
2018-12-27 14:31:39 <ncopa> it hangs
2018-12-27 14:31:44 <ncopa> forever
2018-12-27 14:32:08 <ncopa> its build-edge-x86_64 on bld2.a.o
2018-12-27 15:19:14 <ncopa> i solved it by change the mac address
2018-12-27 15:28:23 <SpaceToast> ncopa: dad.if-up hung for me forever on 3.8 without lxc
2018-12-27 15:28:31 <SpaceToast> a pretty long time ago too
2018-12-27 15:28:42 <SpaceToast> I just disabled it at the time (was in a hurry to get network running)
2018-12-27 15:32:38 <ncopa> ok
2018-12-27 15:32:49 <ncopa> i saw there was a patch recently
2018-12-27 15:33:15 <ncopa> but in general, i think we should have a finite loop
2018-12-27 15:33:28 <ncopa> in other news, lcms test suite fails on armv7:
2018-12-27 15:33:32 <ncopa> Testing linear interpolation ...Error in Linear interpolation (2p): Must be i=8000, But is n=8001
2018-12-27 15:33:32 <ncopa> make[1]: *** [Makefile:489: check] Error 1
2018-12-27 15:35:52 <danieli> off by one?
2018-12-27 15:36:58 <ncopa> huh?, it succeeds on my machine...
2018-12-27 15:37:10 <ncopa> i mean in my dev container
2018-12-27 15:38:31 <ncopa> ok, this is super weird...
2018-12-27 15:38:41 <danieli> sounds like a true heisenbug
2018-12-27 15:38:45 <danieli> off-by-one on a specific architecture
2018-12-27 15:40:42 <ncopa> i have more werid stuff going on:
2018-12-27 15:40:50 <ncopa> >>> lcms: Package is up to date
2018-12-27 15:40:50 <ncopa> ncopa-edge-armv7:~/aports/main/lcms$ abuild cleanpkg
2018-12-27 15:40:50 <ncopa> >>> lcms: Cleaning built packages...
2018-12-27 15:40:50 <ncopa> >>> lcms: Updating the main/armv7 repository index...
2018-12-27 15:40:50 <ncopa> ERROR: APKINDEX.tar.gz: UNTRUSTED signature
2018-12-27 15:41:06 <ncopa> it fails to update the index
2018-12-27 15:41:09 <danieli> why?
2018-12-27 15:41:13 <ncopa> no clue
2018-12-27 15:42:21 <ncopa> sounds like it generates a broken signature
2018-12-27 15:46:07 <danieli> that's so strange
2018-12-27 15:47:45 <ncopa> yup
2018-12-27 15:47:57 <ncopa> im considering drop armv7 for alpine 3.9
2018-12-27 15:48:11 <ncopa> too much weird brokeness
2018-12-27 15:49:41 <SpaceToast> I know of quite a few people running alpine on armv7, but seeing as only tmpfs style installations are supported that's not necessarily a good thing... perhaps we could come back to it once there's more time (and ideas on how to support it properly?)
2018-12-27 15:49:48 <SpaceToast> also, would this affect rpi(0-3)?
2018-12-27 15:50:37 <ncopa> we stil have armhf
2018-12-27 15:51:01 <ncopa> so no, it shouldnt affect rpi
2018-12-27 15:51:18 <ncopa> except you cannot run the newer rpis as armv7
2018-12-27 15:51:38 <danieli> the cortex a53 is armv8 (64bit)
2018-12-27 15:51:42 <SpaceToast> oh so you mean armv7 w/o hardware float
2018-12-27 15:51:56 <ncopa> no, i think its armv7hf
2018-12-27 15:52:21 <ncopa> danieli: yes the aarch64 work on rpi3
2018-12-27 15:52:42 <SpaceToast> armhf typically refers to armv7 + hardware float support, and aarch64 is armv8 64bit (at least as far as I'm aware)
2018-12-27 15:53:04 <ncopa> yes, but not for alpine
2018-12-27 15:53:12 <SpaceToast> ah, how do we categorize all of this?
2018-12-27 15:53:16 <ncopa> for alpline armhf is armv6hf
2018-12-27 15:53:22 <SpaceToast> oh
2018-12-27 15:54:02 <ncopa> we did that for be able to support the early rpis
2018-12-27 15:54:36 <ncopa> i think we want drop support for armv6 and only support armv7
2018-12-27 15:54:37 <danieli> pi1 is an armv6 arm11 chip, pi2 v1.1 is armv7, pi2 v1.2 and pi3+ are cortex-a53 armv6 chips
2018-12-27 15:54:52 <danieli> er
2018-12-27 15:55:11 <danieli> s/a53 armv6/a53 armv8/
2018-12-27 15:55:11 <alpine-meetbot> danieli meant to say: pi1 is an armv6 arm11 chip, pi2 v1.1 is armv7, pi2 v1.2 and pi3+ are cortex-a53 armv8 chips
2018-12-27 15:55:26 <ncopa> right, so we may drop support for the pi1
2018-12-27 15:55:34 <SpaceToast> dropping armv6 sounds reasonable, you initially said "drop armv7 for alpine 3.9" which got me confused :)
2018-12-27 15:55:55 <SpaceToast> armv7hf is still quite widespread
2018-12-27 15:56:02 <ncopa> well, we currently have problems building the armv7hf
2018-12-27 15:56:10 <danieli> armv7 is new for us, and it's troublesome
2018-12-27 15:56:17 <ncopa> so i was thinking continue with armhf only for now
2018-12-27 15:56:25 <ncopa> instead of armhf + armv7
2018-12-27 15:56:42 <ncopa> the plan was to drop the armv6 next release (3.10)
2018-12-27 15:57:21 <ncopa> ok i gotta go
2018-12-27 15:57:25 <SpaceToast> but if armhf is armv6hf, wouldn't that mean that we're indeed dropping armv7, and not armv6?
2018-12-27 15:57:36 <ncopa> well
2018-12-27 15:57:45 <ncopa> its more "we wait with adding support for armv7"
2018-12-27 15:57:50 <SpaceToast> sorry if I'm being silly, I did just wake up, but (it appears to me that) you seem to be flip-flopping as to what you say :)
2018-12-27 15:57:53 <SpaceToast> ah, ok
2018-12-27 15:58:01 <ncopa> since we currently have armhf (armv6)
2018-12-27 15:58:15 <SpaceToast> and get it running on 3.10, which is when we drop v6 (hf)
2018-12-27 15:58:40 <ncopa> i was hoping for both v6 and v7 for alpine 3.9
2018-12-27 15:59:03 <ncopa> and with the release of alpine 3.9 we announce that this is the last of armv6
2018-12-27 15:59:18 <ncopa> so people have an overlap release where they can upgrade
2018-12-27 15:59:50 <SpaceToast> armv7 would require a reinstall from v6 (I would imagine)
2018-12-27 16:00:18 <SpaceToast> so I don't think it's necessary to have an overlap release in that case (but v7 must be available once v6 is dropped, then, for sure)
2018-12-27 16:18:17 <mps> huh, armv7 runs fine, 'uptime' 17:18:12 up 33 days,  3:00,  0 users,  load average: 0.15, 0.14, 0.10
2018-12-27 16:18:36 <danieli> not all of world is built for armv7
2018-12-27 16:18:40 <danieli> it isn't officially released
2018-12-27 16:19:16 <mps> know that, but runs fine even unofficially :)
2018-12-27 16:19:34 <danieli> doesn't really change anything, unfortunately
2018-12-27 16:20:21 <mps> have it running on two SBCs without X and one chromebook with X
2018-12-27 16:21:31 <mps> if it will be dropped then I would have to build a lot of packages
2018-12-27 16:22:16 <danieli> we're not dropping armv7, we're waiting with officially adding support for it considering all the strange brokenness
2018-12-27 16:22:18 <mps> is there a url with list of failed builds for armv7
2018-12-27 16:22:29 <danieli> there's always #alpine-commits
2018-12-27 16:22:44 <mps> i'm there
2018-12-27 16:24:08 <mps> and don't have impression that the armv7 to high on failed builds
2018-12-27 16:24:36 <danieli> enough to warrant not releasing it with 3.9
2018-12-27 16:26:18 <mps> `apk search | wc -l` gives 11036
2018-12-27 16:26:45 <danieli> 13146 on an x86_64 edge machine
2018-12-27 16:27:06 <mps> not big difference
2018-12-27 16:27:51 <mps> oh, forgot to tell: main, community and testing
2018-12-27 16:28:54 <ncopa> we have a few weird issues with armv7, we need to solve those
2018-12-27 16:29:06 <mps> and there is number of packages which are excluded from armhf/armv7
2018-12-27 16:29:48 <mps> openjdk7 was big and it is solved, afaik
2018-12-27 16:30:00 <ncopa> yup
2018-12-27 16:30:07 <ncopa> main/lcms
2018-12-27 16:30:27 <ncopa> the testuite fails on the build server
2018-12-27 16:30:32 <ncopa> but not i my dev container
2018-12-27 16:30:47 <mps> ok, will try later on local machine
2018-12-27 16:31:07 <ncopa> i think you can try the v3.9 packages too now
2018-12-27 16:31:32 <mps> instead of edge, you mean
2018-12-27 16:31:38 <ncopa> yes
2018-12-27 16:31:56 <ncopa> majority of the packages should be built now
2018-12-27 16:32:06 <mps> ok, will try later
2018-12-27 16:32:18 <ncopa> so you should be able to replace edge with v3.9 in /etc/apk/repositories and apk upgrade -U -a
2018-12-27 16:33:14 <mps> chromebook with armv7 is not here right now, will be in two hours (my daugther uses it sometimes on faculty)
2018-12-27 16:33:41 <mps> yes, understand. in hour or two will try
2018-12-27 16:34:23 <mps> I have one box but with just 1GB of RAM, slow for builds
2018-12-27 16:35:34 <mps> chromebook have 4GB, fine for building most packages except few which requires a lot of RAM for building
2018-12-27 16:51:46 <mps> armv7 v3.9 testing is not uploaded yet? looked at https://nl.alpinelinux.org/alpine/v3.9/
2018-12-27 16:53:50 <clandmeter> Testing not ready yet i suppose
2018-12-27 16:54:23 <clandmeter> Oh that's stable
2018-12-27 16:54:32 <clandmeter> There is no testing in stable
2018-12-27 16:56:45 <danieli> yup, testing is only in edge @ mps
2018-12-27 16:56:53 <mps> ah, then i can'combine' v3.9 main and community with edge testing. although I do that for x86_64, just rhetorical question of the some sort
2018-12-27 16:57:11 <danieli> it should work for now, but mixing stable and edge is a recipe for disaster
2018-12-27 16:57:41 <_ikke_> mostly because different dependency versions
2018-12-27 16:57:44 <danieli> indeed
2018-12-27 16:58:02 <SpaceToast> if you mix stable and edge, be ready for abi and api mismatches and other such failures
2018-12-27 16:58:08 <SpaceToast> you can do it, but expect to have to fix it on your own
2018-12-27 16:58:11 <PureTryOut[m]> sadly a lot of perfectly fine working software is stuck in testing, so they'll never get into a stable release...
2018-12-27 16:58:39 <danieli> PureTryOut[m]: if the software has active maintainers and it's confirmed to work, moving it to community should be fine
2018-12-27 16:58:41 <SpaceToast> PureTryOut[m]: wanna maintain them, test them, get them promoted out of stable, and enter an at-least-6-month-long comittment to keeping them working? :)
2018-12-27 16:59:03 <danieli> and then there's the issue of actually reviewing and moving all of it, with all the other things to do
2018-12-27 16:59:07 <_ikke_> PureTryOut[m]: letting the maintainer know whould help a lot as well
2018-12-27 16:59:17 <mps> I always have edge/testing on stable installs, tagged although
2018-12-27 16:59:52 <PureTryOut[m]> danieli: yeah but the maintainer should do that ;)
2018-12-27 17:00:30 <PureTryOut[m]> I often wonder if maintainers don't use the software they maintain and thus never see it works well enough for community
2018-12-27 17:01:19 <SpaceToast> I only maintain things I use, but that also means it's like ~10 packages :)
2018-12-27 17:01:39 <PureTryOut[m]> Same
2018-12-27 17:01:48 <SpaceToast> (most of which aren't even in testing/ right now though, getting things included is hard while there's a rush to get 3.9 out)
2018-12-27 17:04:33 <PureTryOut[m]> That makes me remember, I should change a PR of mine
2018-12-27 17:46:56 <mps> ncopa: main/lcms builds fine on armv7 locally
2018-12-27 17:56:41 <danieli> mps: the problem is the test
2018-12-27 17:56:44 <danieli> try abuild check
2018-12-27 18:00:15 <mps> tried with 'abuild -r', doesn't it runs check, also
2018-12-27 18:00:27 <danieli> fcolista: is there a specific reason we don't have qt5-qtspeech available?
2018-12-27 18:00:33 <danieli> I'm working on pyside2
2018-12-27 18:01:27 <mps> danieli: now with 'abuild deps unpack prepare build' and 'abuild check' it passes tests
2018-12-27 18:02:43 <[[sroracle]]> what about `abuild check_fakeroot`
2018-12-27 18:03:58 <mps> [[sroracle]]: also passed
2018-12-27 18:04:37 <danieli> odd
2018-12-27 18:05:33 <mps> btw, I noticed that some packages builds fine locally but build.a.o have promblems with them
2018-12-27 18:05:56 <danieli> it might be something cpu-specific, but that sounds unlikely
2018-12-27 18:06:20 <mps> last tried community/shards on aarch64, locally works
2018-12-27 18:06:49 <danieli> on which builder?
2018-12-27 18:07:19 <mps> http://build.alpinelinux.org/buildlogs/build-3-9-aarch64/community/shards/shards-0.8.1-r0.log
2018-12-27 18:07:57 <mps> i've built it locally with 'abuild'
2018-12-27 18:13:56 <danieli> looks like there will be no pyside for now, qt is a bit of a disorganized mess
2018-12-27 20:16:58 <andypost> ncopa, https://github.com/alpinelinux/aports/pull/5925 blocks 3.9 builders
2018-12-27 22:09:04 <danieli> mps: unless you need the change tracked to get into a stable release, it shouldn't be necessary to create an issue for it
2018-12-27 22:09:15 <danieli> especially for fairly trivial patches
2018-12-27 22:14:45 <mps> danieli: ncopa told me few days opposite
2018-12-27 22:15:01 <mps> s/few days/few days ago/
2018-12-27 22:15:01 <alpine-meetbot> mps meant to say: danieli: ncopa told me few days ago opposite
2018-12-27 22:15:03 <danieli> i think i was present, i vaguel remember it
2018-12-27 22:15:09 <danieli> s/vaguel/vaguely/
2018-12-27 22:15:09 <alpine-meetbot> danieli meant to say: i think i was present, i vaguely remember it
2018-12-27 22:15:33 <mps> this blocks builds on armv7, and is simple patch
2018-12-27 22:15:48 <danieli> armv7 isn't an immediate priority if we're delaying it until after 3.9
2018-12-27 22:17:15 <mps> don't think it is bad to fix bugs, which is irrelevant to release imo
2018-12-27 22:17:43 <danieli> oh no, that's not an issue at all, don't get me wrong :)
2018-12-27 22:18:16 <danieli> i meant the bugs.a.o issue
2018-12-27 22:19:01 <mps> well, I have split mind about it like you, but trying to follow core devs advice
2018-12-27 22:19:16 <danieli> fair enough, the gods will decide
2018-12-27 22:19:58 <danieli> i initially suggested creating issues for patches you need tracked into a stable release, not really sure if that applies to stuff lik ethis
2018-12-27 22:20:00 <mps> and absolutely agree with, this doesn't deserve to be at bugs.a.o
2018-12-27 22:20:10 <danieli> s/lik ethis/like this/
2018-12-27 22:20:10 <alpine-meetbot> danieli meant to say: i initially suggested creating issues for patches you need tracked into a stable release, not really sure if that applies to stuff like this
2018-12-27 22:22:15 <mps> other idea I have is to be tiresome on #alpine-devel
2018-12-27 22:22:54 <danieli> if you really *must* get it into a stable release and cannot set up your own mirror or self-build, it's pretty much either repeatedly posting here, or tracking via bugs.a.o
2018-12-27 22:24:19 <mps> no, my intention is to solve bug which blocks builders
2018-12-27 22:24:35 <danieli> ah. they get blocked every once in a while if they are configured to
2018-12-27 22:25:22 <mps> yes, and just trying to help where I can and have a free time
2018-12-27 22:29:38 <mps> for example, libzen build fails because checksum in APKBUILD must be updated, and I hesitate to send such simple patch or post issue
2018-12-27 22:30:12 <mps> and libzen is 'stuck' at builders
2018-12-27 22:30:47 <danieli> during daytime, you could probably post `git am`able patches here for the most trivial issues (like a bad checksum), but don't quote me on that
2018-12-27 22:32:11 <mps> I promise  :)
2018-12-28 02:31:54 <ddevault> so
2018-12-28 02:31:55 <ddevault> textrels
2018-12-28 02:31:58 <ddevault> what the fuck are they
2018-12-28 02:34:21 <Xe> something we can probably answer with a nicer asked question
2018-12-28 02:34:53 <ddevault> sorry for disturbing your fine channel folks but I was wondering if you could shed some light on this "textrels" issue
2018-12-28 02:35:54 <SpaceToast> ddevault: I'd need some further details, but in general, a textrel (aka .TEXT RELocation) is when you have a relocation in an assembly's .TEXT section
2018-12-28 02:36:12 <SpaceToast> while you have textrels, your code isn't *TRULY* position-independent, basically
2018-12-28 02:36:21 <ddevault> I keep hitting that abuild linter failure when compiling nghttp2 for risc-v
2018-12-28 02:36:28 <ddevault> been trying to put it off but I can't avoid it
2018-12-28 02:36:37 <ddevault> afaict it's going to be hell to fix
2018-12-28 02:36:45 <SpaceToast> yes, yes it is.
2018-12-28 02:36:53 <ddevault> woo
2018-12-28 02:37:06 <SpaceToast> you may find https://wiki.gentoo.org/wiki/Hardened/Introduction_to_Position_Independent_Code useful
2018-12-28 02:37:15 <ddevault> thx
2018-12-28 02:37:29 <SpaceToast> no idea re: RISC-V specifics though
2018-12-28 02:37:32 <SpaceToast> so... expect hell :(
2018-12-28 02:42:23 <sorear> when I was doing the early Fedora work we hit an issue with lapack where 1 of the thousand-odd .o files was being built without -fPIC
2018-12-28 02:43:44 <sorear> the x86 GNU toolchain is designed to be tolerant of this: if you have a small amount of position-dependent code in a shared object, the dynamic loader will fix that up on startup, and the only cost is lost sharing (a few KB of memory and a few more microseconds to load)
2018-12-28 02:44:17 <sorear> the riscv toolchain is less tolerant and failed linking until we had the build system fixed to properly -fPIC *everything*
2018-12-28 02:44:55 <sorear> the previous Fedora MIPS port hit the same issue for the same reason
2018-12-28 02:45:01 <ddevault> thanks sorear
2018-12-28 02:45:05 <ddevault> that's a useful lead
2018-12-28 02:46:21 <sorear> the specific case relevant to lapack was a double constant; on most ISAs the best way to load a general double (not 0 or 1 or similar) is for the compiler to create an invisible read-only global variable and load it from memory
2018-12-28 02:49:21 <SpaceToast> ddevault: apparently there's also a page on how to fix it on x86 (in case it helps): https://wiki.gentoo.org/wiki/Hardened/Textrels_Guide
2018-12-28 02:49:28 <ddevault> cheers
2018-12-28 02:50:40 <kaniini> keep in mind that without additional hardware (that can be dedicated to the project) the riscv64 port won't pass architecture qualification
2018-12-28 02:51:03 <ddevault> can you elaborate
2018-12-28 02:51:33 <kaniini> as part of each alpine release cycle, all ports have to be qualified for inclusion in the release
2018-12-28 02:52:28 <kaniini> 1 person with 1 board that is not even a dedicated build machine does not meet the requirements for qualification
2018-12-28 02:52:48 <ddevault> what are the requirements for qualification?
2018-12-28 02:52:58 <kaniini> 24x7 dedicated builder
2018-12-28 02:53:13 <kaniini> multiple interested alpine developers
2018-12-28 02:53:45 <kaniini> porting machines
2018-12-28 02:53:46 <ddevault> if the build demand is smaller than a dedicated board would provide, why leave it cold when other distros or projects could use it?
2018-12-28 02:54:07 <kaniini> i assure you the build demand is larger than you believe it to be
2018-12-28 02:54:21 <kaniini> the slower boards have a hard time keeping up
2018-12-28 02:54:22 <ddevault> I doubt this one board setup scales to the demand, to be clear
2018-12-28 02:54:34 <ddevault> but I intend to get more boards, and SiFive already offered to provide them
2018-12-28 02:54:40 <kaniini> okay
2018-12-28 02:54:44 <ddevault> this board isn't that slow, tbh
2018-12-28 02:54:51 <kaniini> well
2018-12-28 02:55:00 <kaniini> even aarch64 struggles to keep up
2018-12-28 02:55:02 <kaniini> and
2018-12-28 02:55:03 <ddevault> especially once I set up gigabit nbd
2018-12-28 02:55:06 <kaniini> that is thunderx2
2018-12-28 02:55:12 <kaniini> soooooooo
2018-12-28 02:55:48 <ddevault> as for porting machines (I assume that's for maintenance of the port?)
2018-12-28 02:56:11 <kaniini> porting machines are so that alpine developers & maintainers can debug their packages on real hardware
2018-12-28 02:56:12 <ddevault> qemu on your workstation should be fine for working locally, and pushing the QA/live build to a hardware worker can be done periodically
2018-12-28 02:56:19 <kaniini> qemu is not acceptable
2018-12-28 02:56:31 <ddevault> my CI environment supports a fairly straightforward ad-hoc job submission
2018-12-28 02:56:38 <kaniini> CI is not acceptable
2018-12-28 02:56:45 <ddevault> qemu is totally acceptable if you can reproduce your problem there, though naturally the final build would have to happen on hardware
2018-12-28 02:57:02 <ddevault> I mean, I'm interested in getting this port upstream if you guys want it, and we should work through the concerns and problems
2018-12-28 02:57:12 <ddevault> but you're not coming off as very open to that
2018-12-28 02:57:13 <kaniini> there is no working through concerns
2018-12-28 02:57:18 <kaniini> it either qualifies or it doesn't
2018-12-28 02:58:00 <kaniini> all other ports in alpine have these things
2018-12-28 02:58:05 <ddevault> what you're saying is "buy everyone on the alpine team a $1,000 board, plus a few extras for builders, then we can talk"
2018-12-28 02:58:08 <ddevault> well, you're not getting that
2018-12-28 02:58:13 <kaniini> no i am not
2018-12-28 02:58:15 <ddevault> so if you're interested in the port let's talk about other ways
2018-12-28 02:58:31 <kaniini> i am saying that you need two boards
2018-12-28 02:58:38 <kaniini> 1 for building
2018-12-28 02:58:52 <kaniini> 1 for shell access for developers & maintainers on request
2018-12-28 02:58:59 <kaniini> they technically could be the same machine
2018-12-28 02:59:19 <kaniini> but the point is, if an alpine package maintainer has a problem with ppc64le for example
2018-12-28 02:59:25 <ddevault> out of curiosity, have you tried builds.sr.ht?
2018-12-28 02:59:28 <kaniini> they can go to whoever they are working with
2018-12-28 02:59:42 <kaniini> and whoever they are working with can get them a shell
2018-12-28 02:59:47 <kaniini> on an ppc64le machine
2018-12-28 02:59:57 <kaniini> a real one, not qemu emulation
2018-12-28 03:00:04 <ddevault> nothing beats a shell, for sure
2018-12-28 03:00:06 <kaniini> this is also possible for arm, aarch64 etc
2018-12-28 03:00:12 <kaniini> yes
2018-12-28 03:00:13 <kaniini> well
2018-12-28 03:00:17 <kaniini> that is the requirement
2018-12-28 03:00:31 <kaniini> directing people to a proprietary service
2018-12-28 03:00:32 <ddevault> but I want you to consider giving the design I have in mind a try
2018-12-28 03:00:41 <ddevault> sr.ht is 100% open source, LGPL+MIT
2018-12-28 03:00:47 <kaniini> it does not matter
2018-12-28 03:00:53 <kaniini> it is external to the project
2018-12-28 03:01:01 <ddevault> so is github, etc
2018-12-28 03:01:14 <kaniini> yes ,and we do not use github exclusively
2018-12-28 03:01:20 <ddevault> in any case, I have volunteered to be an alpine developer before, offer still stands
2018-12-28 03:01:36 <ddevault> I work a lot on Alpine and I'm fond of it and happy to volunteer my time and resources
2018-12-28 03:01:48 <kaniini> well, that is another topic entirely
2018-12-28 03:01:49 <AinNero> oh, while you mention it
2018-12-28 03:02:02 <AinNero> ncopa: my offer still stands to take maintainership for mkinitfs
2018-12-28 03:02:22 <kaniini> if you want to be an alpine developer you should ask the person who you are working with as a maintainer to nominate you for being a dev
2018-12-28 03:02:57 <ddevault> I don't work with anyone in particular afaict, I just send patches to alpine-aports@lists.alpinelinux.org and periodically bump them if they don't get merged
2018-12-28 03:03:12 <ddevault> but this is indeed a separate topic
2018-12-28 03:03:28 <kaniini> but that does not change the reality that if riscv64 is to be an accepted arch for releases that it must behave in the same way as the other archs wrt building & shell access
2018-12-28 03:03:29 <ddevault> I need to build out more of this infrastructure to maintain my own third-party apk repo and some other goals
2018-12-28 03:03:48 <ddevault> so once it's set up and we have something to look at and poke holes in, let's look at it and poke holes in it then
2018-12-28 03:03:56 <SpaceToast> kaniini: I'm working on alpine's docs - so re: development etc; should I take a note that people that want to do maintenance seriously have to pick a developer to work with, and that that's the primary/only way to promotion to dev status?
2018-12-28 03:04:01 <kaniini> it doesn't matter that you have some PPA thing
2018-12-28 03:04:05 <ddevault> shell access can probably be arranged tbh, it just requires me to put some thought into it
2018-12-28 03:04:07 <SpaceToast> (I was going to ask once I got to it, but since it got mentioned already...)
2018-12-28 03:04:23 <kaniini> there are procedures already in place and we're not going to make exception for riscv
2018-12-28 03:04:37 <kaniini> when every other arch meets these requirements
2018-12-28 03:04:38 <ddevault> the reason the "PPA thing" is interesting/useful is because I built some automation infrastructure for its maintenance which is likely applicable to alpine upstream
2018-12-28 03:04:54 <ddevault> there has already been some discussion on how to improve/overhaul the alpine build infrastructure
2018-12-28 03:05:04 <kaniini> sure
2018-12-28 03:05:11 <ddevault> most alpine devs seem to be interested in builds.sr.ht as an option
2018-12-28 03:05:27 <kaniini> i'm not interested in it unless it is controlled by us
2018-12-28 03:05:37 <ddevault> well, it's open source after all
2018-12-28 03:05:41 <AinNero> i'd prefer to stay on the alpinelinux.org infra
2018-12-28 03:06:07 <ddevault> but if you want access to my boards you'll have to go through my infrastructure somehow
2018-12-28 03:06:13 <ddevault> ¯\_(ツ)_/¯
2018-12-28 03:06:29 <kaniini> i don't know what alpine devs you have been talking to, but the alpine devs i talk to believe that our signing keys shouldn't be under the control of a third party
2018-12-28 03:07:00 <ddevault> which brings the discussion back around to "maybe I can join the team"
2018-12-28 03:07:04 <ddevault> but there were also some other ideas tossed around
2018-12-28 03:07:29 <ddevault> but again, if I can touch the hardware I can theoretically get the keys, so we have to set up some degree of trust if you want to use my boards for builders
2018-12-28 03:07:51 <kaniini> becoming an alpine developer does not mean you get to control the master signing keys ;)
2018-12-28 03:07:51 <ddevault> I don't think any of this is important/hard enough to sort out now and/or abandon the port
2018-12-28 03:07:57 <ddevault> I have a lot more work to do between now and then
2018-12-28 03:08:21 <kaniini> ddevault: sure, i am not even saying to abandon it.  i am just advising you of the requirements for it to be accepted as viable
2018-12-28 03:08:29 <ddevault> veering off-topic again, but master signing keys seems a bit weird to me
2018-12-28 03:08:31 <ddevault> why not a keyring
2018-12-28 03:08:51 <kaniini> each arch has it's own master signing keys
2018-12-28 03:08:59 <SpaceToast> ddevault: apk supports arbitrary amounts of keys in /etc/apk/keys (as I'm sure you know, since you sign packages). I suspect it's because builder machines are a thing.
2018-12-28 03:09:04 <kaniini> they are in fact distributed by a keyring
2018-12-28 03:09:06 <ddevault> oh, well it would naturally make sense for me to maintain the riscv64 port
2018-12-28 03:09:13 <kaniini> sure
2018-12-28 03:09:21 <ddevault> so if we sign them with my key on my hardware then nbd
2018-12-28 03:10:01 <kaniini> anyway
2018-12-28 03:10:09 <ddevault> I intend to let users hook up third-party build boxen to the canonical builds.sr.ht management interface et al, so that'll help if we're talking about overhauling the build process as a whole
2018-12-28 03:10:10 <kaniini> if you want to become an alpine developer
2018-12-28 03:10:24 <kaniini> i would recommend
2018-12-28 03:10:33 <kaniini> finishing up the riscv64 port
2018-12-28 03:10:39 <kaniini> that would make justification easy
2018-12-28 03:10:47 <kaniini> assuming you can find some other people to sign off on it
2018-12-28 03:10:48 <sorear> and this is also why I’m interested in turnkey bootstraps, because whatever riscv’s future is there will always be arches with ten users that want to be able to build a port on demand but cannot guarantee porting hw
2018-12-28 03:11:08 <ddevault> turnkey is on my todo list
2018-12-28 03:11:15 <ddevault> but honestly the effort/reward ratio is pretty rough
2018-12-28 03:11:35 <kaniini> sorear: sure, and i think there's an area for "unofficial" ports, much like debian-ports.org
2018-12-28 03:11:53 <kaniini> but it does not change the fact that getting a new port into alpine requires some level of commitment
2018-12-28 03:12:16 <ddevault> are the requirements for a new port written up anywhere?
2018-12-28 03:12:21 <ddevault> writing up a wiki page is on my todo list as well
2018-12-28 03:12:28 <kaniini> new architectures officially supported by the distribution is a large ask of the entire community too
2018-12-28 03:12:44 <kaniini> because you are asking us, as package maintainers, to support your new arch
2018-12-28 03:12:45 <SpaceToast> ddevault: it's on my list to add to the dev manual
2018-12-28 03:12:51 <ddevault> aye
2018-12-28 03:12:56 <kaniini> that's why we ask for porting hw
2018-12-28 03:12:57 <ddevault> improving the process for package maintainers is also on my list
2018-12-28 03:13:00 <SpaceToast> what exactly they are I've no idea right now, but now I know exactly who to ask ;)
2018-12-28 03:13:17 <ddevault> I want to, for example, run automated builds against all arches in a nice fresh alpine installation
2018-12-28 03:13:19 <kaniini> SpaceToast: i just wrote what they are
2018-12-28 03:13:24 <ddevault> whenever a patch lands in alpine-aports
2018-12-28 03:13:28 <kaniini> - dedicated builder (24x7 uptime)
2018-12-28 03:13:53 <ddevault> but this could be done by anyone anytime by just pushing a few knobs, no special access or permissions required
2018-12-28 03:13:57 <kaniini> - porting access (could be on same machine as builder if need be, but needs to be jailed in that case)
2018-12-28 03:14:06 <ddevault> so the loop on testing should be small and require little intervention from anyone else
2018-12-28 03:14:16 <ddevault> getting a shell in this environment is an interesting idea that should be possible, too
2018-12-28 03:14:19 <kaniini> - interested alpine developers (NOT maintainers)
2018-12-28 03:14:31 <SpaceToast> kaniini: lots of unresolved issues - for example, how/where should the control of the system be (given that master keys exist)? Does the person maintaining the port need to be a developer at the time of inclusion? How many developers need to sign off on it? So on
2018-12-28 03:14:41 <SpaceToast> it's ok, I'll get to it once I'm actually writing that section.
2018-12-28 03:14:53 <ddevault> in fact I think I should try to make that work
2018-12-28 03:15:03 <kaniini> SpaceToast: there has never been a formal requirement on number of developers signing off on the port
2018-12-28 03:15:16 <kaniini> SpaceToast: and yes, obviously the people maintaining the port must be developers themselves
2018-12-28 03:15:18 <ddevault> https://todo.sr.ht/~sircmpwn/builds.sr.ht/172
2018-12-28 03:15:41 <SpaceToast> if there isn't a formal requirement, it's kind of hard to draw the line appropriately
2018-12-28 03:15:59 <kaniini> SpaceToast: since the maintainers of the port are developers, we trust them to make appropriate decisions about control of the system
2018-12-28 03:17:11 <kaniini> SpaceToast: historically, the minimum has been 2 devs signing off on it (who can be maintainers of the port themselves), more is better
2018-12-28 03:17:31 <SpaceToast> ok, that should be formal enough
2018-12-28 03:18:27 <kaniini> ddevault: the problem is, having to go through sr.ht to requistion a shell on a riscv porting machine is not going to pass the test
2018-12-28 03:18:36 <ddevault> why?
2018-12-28 03:18:46 <kaniini> ddevault: because you could get bored and quit working on the port tomorrow
2018-12-28 03:18:59 <ddevault> I get paid to maintain sr.ht's infrastructure
2018-12-28 03:19:01 <kaniini> ddevault: meaning that new hardware will have to be found to keep the port viable etc
2018-12-28 03:19:09 <ddevault> and that includes RISC-V support
2018-12-28 03:19:18 <kaniini> that is not relevant to us
2018-12-28 03:19:32 <ddevault> I don't understand how the risk is different for any other alpine developer who loses interest
2018-12-28 03:19:35 <kaniini> you could, of course, use sr.ht to manage requisitions internally
2018-12-28 03:19:46 <kaniini> but the procedure must remain generic
2018-12-28 03:20:08 <kaniini> for alpine developers (either acting on behalf of maintainers or themselves)
2018-12-28 03:20:09 <ddevault> wouldn't it be strictly better if there was a hands-off way for any maintainer (or any volunteer who has never contributed but wants to fix something) to get a shell quickly?
2018-12-28 03:20:28 <kaniini> it would be, but
2018-12-28 03:20:39 <kaniini> the problem is
2018-12-28 03:20:44 <ddevault> updated this with more detail on how I see this panning out https://todo.sr.ht/~sircmpwn/builds.sr.ht/172
2018-12-28 03:20:44 <kaniini> if you have this other procedure
2018-12-28 03:20:52 <kaniini> then people will want it from the other archs
2018-12-28 03:20:57 <kaniini> who will not provide it
2018-12-28 03:21:02 <ddevault>  why not do it for the other arches?
2018-12-28 03:21:23 <kaniini> because
2018-12-28 03:21:27 <ddevault> also, if one arch could do it better why let the others spoil the fun?
2018-12-28 03:21:29 <kaniini> that either locks the project into sr.ht
2018-12-28 03:21:38 <ddevault> (which is open source and self hostable)
2018-12-28 03:21:44 <kaniini> or that imposes undue burden on other archs
2018-12-28 03:22:13 <kaniini> but either way
2018-12-28 03:22:15 <ddevault> well, I'm not interested in burdening anyone with something they'll find burdensome/not useful
2018-12-28 03:22:16 <SpaceToast> ddevault: if we consider the theoretical situation that you "get bored and move on", this means that we'll need to maintain sr.ht on top of the things running on it, right?
2018-12-28 03:22:26 <kaniini> ^^^^^^^^^^
2018-12-28 03:22:35 <kaniini> 99% of porting requisitions
2018-12-28 03:22:35 <SpaceToast> I do find this rather unlikely (you've a relatively decent track record), but I can see this as being a legitimate concern
2018-12-28 03:22:39 <ddevault> SpaceToast: sure, and cgit, hypermail, bugzilla...
2018-12-28 03:22:39 <kaniini> the admin contact
2018-12-28 03:22:43 <kaniini> just creates an lxc jail
2018-12-28 03:23:20 <SpaceToast> cgit is quite small, patchwork/redmine are bigger issues in that regard (and, interestingly, the parts that seem to have people excited to leave behind)
2018-12-28 03:23:35 <ddevault> well, to put to rest the requisition issue
2018-12-28 03:23:45 <ddevault> in the hypothetical world where the riscv64 port is completed and I'm the maintainer
2018-12-28 03:24:00 <kaniini> i don't personally care how the riscv64 team handles requisitions as long as they get handled
2018-12-28 03:24:01 <ddevault> I'll use a "generic process" to give people a shell using this design or something similar to it
2018-12-28 03:24:07 <sorear> so you're looking for hardware that can run a sshd while in alpine custody, but the details of the hardware are less important?  (fedora steering has tighter rules and specifically wants something rack-mounted)
2018-12-28 03:24:09 <kaniini> and they don't have to sign up
2018-12-28 03:24:10 <ddevault> and then if other arches find it useful
2018-12-28 03:24:12 <kaniini> for some special thing
2018-12-28 03:24:13 <ddevault> I'll help them set it up
2018-12-28 03:24:31 <SpaceToast> ddevault: I believe the true solution is for you to talk to the sifive people once the port is completed and see if they want to donate a system to alpine (rather than to you personally) :)
2018-12-28 03:24:54 <kaniini> ^^^^^^^^^^^
2018-12-28 03:25:00 <SpaceToast> I'm sure that with a full on port already existing they won't have an issue with sharing one board (esp. since this'll happen later, at which point their build process will be better)
2018-12-28 03:25:00 <ddevault> sure, that'd be nice too
2018-12-28 03:25:17 <ddevault> but since I have my own reasons to build out this infrastructure, I'm just offering it to Alpine if you guys find it useful when it's done
2018-12-28 03:25:27 <SpaceToast> either way, this can all be discussed closer to the port's completion, right now we lack too much information (on all sides)
2018-12-28 03:25:28 <ddevault> so this stuff is getting built if alpine wants it or not
2018-12-28 03:25:39 <kaniini> that's all fine
2018-12-28 03:26:00 <kaniini> i am just saying that we're not going to place our repos under the control of a service not operated by the alpine sysadmins
2018-12-28 03:26:01 <sorear> fyi the current sifive boards with the current kernels lock hard every few days for fedora, so you'll want some way to remotely power-cycle them
2018-12-28 03:26:07 <ddevault> they're a little starved for boards fwiw
2018-12-28 03:26:20 <ddevault> "I'm going to share this with anyone who wants it" sounds a lot better than "we want to use this for alpine"
2018-12-28 03:26:39 <ddevault> sorear: yeah, they're going to be rebooted very frequently with the design I'm working on
2018-12-28 03:26:42 <ddevault> after each build
2018-12-28 03:27:27 <ddevault> kaniini: I understand, and I'm saying there are ways to fix that
2018-12-28 03:27:30 <SpaceToast> ddevault: well, I'm not expecting the port to be completed for at least another 4ish months (highly optimistic, based on historical precedents in, say, gentoo)
2018-12-28 03:27:37 <ddevault> oh yeah that's super optimistic
2018-12-28 03:27:45 <SpaceToast> so hopefully by the time that it *is* ready for inclusion, I believe they'll be better set :)
2018-12-28 03:27:50 <sorear> like, with an actual relay, or are you relying on the boards to respond to anything over the network
2018-12-28 03:27:55 <ddevault> I have a bunch of shit on my plate
2018-12-28 03:28:08 <ddevault> sorear: an actual relay, I have one here in my apartment I've been experimenting with
2018-12-28 03:28:18 <ddevault> I'm also going to use it possibly to disconnect the microSD card post-boot
2018-12-28 03:28:25 <kaniini> just get some of those
2018-12-28 03:28:28 <ddevault> if I can't get a kernel-based solution I'm reasonably confident in
2018-12-28 03:28:28 <kaniini> usb rebooter things
2018-12-28 03:28:31 <kaniini> that OVH has
2018-12-28 03:28:34 <SpaceToast> lolovh
2018-12-28 03:28:56 <kaniini> or whatever it is
2018-12-28 03:28:58 <kaniini> that they use
2018-12-28 03:29:12 <SpaceToast> sorry, reflex, I have to deal with OVH at work, and they're the third worst provider I've ever had to work with
2018-12-28 03:29:20 <kaniini> i wouldn't know
2018-12-28 03:29:40 <ddevault> the plan is more or less to put a few hifive unleashed into a 1U chassis with a 4x USB power relay switch and a raspberry pi to oversee them over serial
2018-12-28 03:29:48 <ddevault> but I'm still a ways from that
2018-12-28 03:29:51 <sorear> (reboot over usb/jtag might work; you might also be able to disable write access to the SD card using PMP)
2018-12-28 03:29:57 <kaniini> just get
2018-12-28 03:29:59 <kaniini> sifive
2018-12-28 03:30:01 <kaniini> to put ipmi
2018-12-28 03:30:03 <kaniini> on their bullshit
2018-12-28 03:30:04 <kaniini> duh
2018-12-28 03:30:06 <ddevault> lol
2018-12-28 03:30:16 <kaniini> god
2018-12-28 03:30:20 <kaniini> even my thunderx2 machines
2018-12-28 03:30:22 <kaniini> have ipmi
2018-12-28 03:30:24 <SpaceToast> just make an open source risc-v-based ipmi that communicates through usb :^)
2018-12-28 03:30:28 <kaniini> even my IBM POWER8 machines
2018-12-28 03:30:29 <ddevault> this is literally the first commercially available risc-v hardware EVER
2018-12-28 03:30:30 <kaniini> have ipmi
2018-12-28 03:30:32 <ddevault> cut them some slack
2018-12-28 03:30:41 <kaniini> like ipmi blows
2018-12-28 03:30:43 <kaniini> but
2018-12-28 03:30:45 <kaniini> it works
2018-12-28 03:30:53 <SpaceToast> kaniini: except when it doesn't
2018-12-28 03:30:56 <SpaceToast> supermicro \o/
2018-12-28 03:31:17 <ddevault> I might also just desolder the power button and wire it into some GPIO somewhere
2018-12-28 03:31:17 <kaniini> wouldn't know
2018-12-28 03:31:23 <kaniini> we ported openbmc
2018-12-28 03:31:26 <kaniini> to our supermicro boards
2018-12-28 03:31:38 <kaniini> life is good
2018-12-28 03:32:42 <SpaceToast> kaniini: imagine when your ipmi requires a boot cycle every ~4 hours, but at least you can talk to it through ipmitool . . . unless it's been 2 days since last boot cycle, at which point it becomes unresponsive
2018-12-28 03:32:54 <SpaceToast> (until completely cutting power and restarting the entire board)
2018-12-28 03:32:55 <kaniini> sounds quality
2018-12-28 03:32:58 <SpaceToast> it's 10/10
2018-12-28 03:33:00 <kaniini> probably why we ported openbmc
2018-12-28 03:33:06 <SpaceToast> sounds about right
2018-12-28 03:33:13 <kaniini> actually it is not why
2018-12-28 03:33:19 <kaniini> we just did that to be standard
2018-12-28 03:33:22 <kaniini> since everything else
2018-12-28 03:33:24 <kaniini> is openbmc
2018-12-28 03:34:29 <kaniini> anyway
2018-12-28 03:34:33 <kaniini> beta silicon, beta cpu
2018-12-28 03:34:38 <kaniini> beta toolchain
2018-12-28 03:34:41 <kaniini> sounds fun
2018-12-28 03:34:55 <SpaceToast> fully open hardware is nice though :)
2018-12-28 03:35:21 <kaniini> i'll take fully working hardware over fully open hardware, it's more useful
2018-12-28 03:35:41 <ddevault> fwiw I haven't really had any issues with this board
2018-12-28 03:35:45 <SpaceToast> I believe the hope is that the latter merges with the former at some point
2018-12-28 03:35:55 <ddevault> if I could get my hands on one of those expansion boards, whoo-ee
2018-12-28 03:37:09 <kaniini> uptime(1) output pls
2018-12-28 03:37:24 <ddevault> 5 days
2018-12-28 03:37:29 <ddevault> I don't keep any of my computers on for long
2018-12-28 03:37:36 <kaniini> whoo-ee you're beating fedora
2018-12-28 03:37:38 <kaniini> ;)
2018-12-28 03:37:58 <ddevault> I left this one on while I was travelling for the holidays so I could SSH in and run builds
2018-12-28 03:38:05 <SpaceToast> is beating fedora supposed to be hard? :)
2018-12-28 03:38:22 <ddevault> it hasn't been working very hard though
2018-12-28 03:38:31 <ddevault> I'm going to hazard a guess that fedora's issues are more related to nbd than to risc-v
2018-12-28 03:38:37 <kaniini> time to bust out
2018-12-28 03:38:38 <kaniini> prime95
2018-12-28 03:39:58 <ddevault> gonna go with "no" on that one
2018-12-28 03:40:05 <kaniini> coward
2018-12-28 03:40:12 <ddevault> it's not in aports and I'm lazy
2018-12-28 03:40:15 <ddevault> s/lazy/busy/
2018-12-28 03:40:15 <alpine-meetbot> ddevault meant to say: it's not in aports and I'm busy
2018-12-28 03:40:22 <kaniini> excuses
2018-12-28 03:40:27 <ddevault> put it in aports
2018-12-28 03:40:30 <kaniini> it
2018-12-28 03:40:31 <ddevault> then I'll run it for you :)
2018-12-28 03:40:34 <kaniini> is non-free software
2018-12-28 03:40:38 <kaniini> so we can't
2018-12-28 03:40:40 <ddevault> oh, even better
2018-12-28 03:40:43 <ddevault> then I won't run it for you in any case
2018-12-28 03:40:51 <kaniini> just
2018-12-28 03:40:53 <kaniini> compile
2018-12-28 03:41:06 <kaniini> void main() { while (1) {}; }
2018-12-28 03:41:09 <kaniini> and run it
2018-12-28 03:41:13 <kaniini> and see how long before kpanic
2018-12-28 03:41:14 <kaniini> ;)
2018-12-28 03:41:24 <ddevault> it compiles musl on 4 cores in about 4x the time my x86_64 machine takes on 4 cores
2018-12-28 03:41:27 <ddevault> uh
2018-12-28 03:41:44 <ddevault> Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz
2018-12-28 03:41:46 <ddevault> vs
2018-12-28 03:41:49 <SpaceToast> kaniini: why go through all that trouble when forkbombing exists? :)
2018-12-28 03:42:00 <kaniini> well
2018-12-28 03:42:03 <kaniini> i want to see
2018-12-28 03:42:08 <kaniini> how beta this silicon is
2018-12-28 03:42:08 <ddevault> 1.5GHz riscv64
2018-12-28 03:42:13 <kaniini> yeah
2018-12-28 03:42:14 <kaniini> just do
2018-12-28 03:42:18 <ddevault> fwiw I've compiled gcc on this thing
2018-12-28 03:42:23 <kaniini> :() { :|:& }; :&
2018-12-28 03:42:23 <ddevault> no problems
2018-12-28 03:42:26 <ddevault> no
2018-12-28 03:42:26 <kaniini> on it
2018-12-28 03:42:49 <kaniini> coward
2018-12-28 03:42:54 <SpaceToast> I suspect ddevault would be more willing to run stability measurements once he has more than one board
2018-12-28 03:43:08 <ddevault> we don't learn anything from forkbombs
2018-12-28 03:43:13 <ddevault> it'll probably just crash
2018-12-28 03:43:18 <ddevault> no interesting numbers from that
2018-12-28 03:43:18 <kaniini> eh true
2018-12-28 03:43:30 <kaniini> i guess building gcc
2018-12-28 03:43:33 <ddevault> give me a real benchmark and I'll run it
2018-12-28 03:43:33 <SpaceToast> ddevault: sure there are - "how long until it crashes"
2018-12-28 03:43:35 <kaniini> is a decent stress test
2018-12-28 03:44:02 <kaniini> (this is going to be a part of qualifying riscv64 for the first time)
2018-12-28 03:44:10 <ddevault> what, running a forkbomb?
2018-12-28 03:44:15 <kaniini> no
2018-12-28 03:44:17 <ddevault> or benchmarking the board
2018-12-28 03:44:21 <ddevault> the latter seems fine to me
2018-12-28 03:44:31 <kaniini> proving that the port is stable
2018-12-28 03:44:36 <ddevault> lemme run a fresh gcc build and time it
2018-12-28 03:44:36 <sorear> most of the brokenness is in I/O so prime95 is maybe not the best way to expose that (does prime95 even work on weird architectures?)
2018-12-28 03:44:42 <kaniini> its not benchmarking
2018-12-28 03:44:46 <kaniini> so much as
2018-12-28 03:44:55 <kaniini> proving it's not going to violently explode
2018-12-28 03:45:08 <SpaceToast> sorear: source is supposedly published, but I haven't unzipped it (or whatever they use) to see
2018-12-28 03:45:15 <kaniini> or to put it in meme form
2018-12-28 03:45:28 <kaniini> riscv64 needs to be more solid than misskey
2018-12-28 03:45:31 <ddevault> time abuild -r
2018-12-28 03:45:36 <ddevault> now we wait
2018-12-28 03:45:54 <kaniini> i'm seriously confused as to why
2018-12-28 03:45:56 <ddevault> fwiw whenever I have it doing something particularly difficult
2018-12-28 03:46:00 <kaniini> they wouldn't have included
2018-12-28 03:46:00 <sorear> when I saw the Raven-3 demo in 2016 they were rebooting it every 15 minutes due to cache coherency bugs
2018-12-28 03:46:03 <ddevault> I stick my finger next to the heatsink
2018-12-28 03:46:04 <kaniini> usb
2018-12-28 03:46:07 <ddevault> and it's always running cool
2018-12-28 03:46:13 <ddevault> you can overclock it but I'm not going to
2018-12-28 03:46:16 <kaniini> like
2018-12-28 03:46:22 <kaniini> why run off nbd at all
2018-12-28 03:46:27 <kaniini> why not just get external hdd
2018-12-28 03:46:28 <kaniini> and use that
2018-12-28 03:46:29 <ddevault> because mmc is slow as utter shit
2018-12-28 03:46:34 <kaniini> no
2018-12-28 03:46:34 <ddevault> and external hdd requires usb, sata, etc
2018-12-28 03:46:38 <kaniini> yes
2018-12-28 03:46:42 <kaniini> why dont they have that
2018-12-28 03:46:42 <ddevault> which isn't present
2018-12-28 03:46:44 <ddevault> ¯\_(ツ)_/¯
2018-12-28 03:46:46 <kaniini> why do all these embedded fuckwits
2018-12-28 03:46:50 <kaniini> make boards
2018-12-28 03:46:54 <kaniini> that do not have usb or sata
2018-12-28 03:46:55 <ddevault> the expansion board has sata
2018-12-28 03:47:02 <kaniini> well
2018-12-28 03:47:03 <ddevault> but that's another 2 grand I don't intend to spend
2018-12-28 03:47:05 <sorear> because the FU540's I/O is half a dozen NIH things and things from opencores, plus the absolute bare minimum of licensed interfaces
2018-12-28 03:47:08 <ddevault> cannot spend*
2018-12-28 03:47:11 <ddevault> because they're out*
2018-12-28 03:47:11 <kaniini> why the fuck does it cost 2 grand
2018-12-28 03:47:14 <kaniini> to get sata
2018-12-28 03:47:20 <SpaceToast> "first ever", new build process, etc
2018-12-28 03:47:33 <ddevault> it's an FPGA that just happens to be flashed/provisioned as a hifive expansion board
2018-12-28 03:47:35 <SpaceToast> can you imagine how much today's i3 would cost around the dawn of x86?
2018-12-28 03:47:49 <kaniini> ddevault: this just raises even more questions
2018-12-28 03:47:58 <ddevault> what SpaceToast said
2018-12-28 03:48:12 <ddevault> I was going to use nbd anyway
2018-12-28 03:48:13 <kaniini> SpaceToast: except sifive
2018-12-28 03:48:21 <ddevault> it fits more closely with the system already used for non-riscv64 on builds.sr.ht
2018-12-28 03:48:22 <kaniini> SpaceToast: have extensive motivation
2018-12-28 03:48:28 <ddevault> and is easier to deploy updates on
2018-12-28 03:48:31 <ddevault> esp considering no kvm
2018-12-28 03:48:37 <kaniini> SpaceToast: to get hardware into the hands of devs
2018-12-28 03:48:46 <kaniini> SpaceToast: so making sure the hardware is viable
2018-12-28 03:48:48 <SpaceToast> kaniini: yes, that's how ddevault got his piece, after all
2018-12-28 03:48:50 <ddevault> the expansion boards were actually a third party thing
2018-12-28 03:48:56 <ddevault> SpaceToast: to be clear I paid for my board
2018-12-28 03:49:04 <kaniini> ddevault: this raises EVEN MORE questions
2018-12-28 03:49:06 <SpaceToast> ddevault: oh, ok, I thought that was one of the ones they offered to send in
2018-12-28 03:49:37 <ddevault> I imagine this gcc build is going to be I/O bound, and mmc is slow as shit
2018-12-28 03:49:40 <ddevault> so this benchmark might suck
2018-12-28 03:49:44 <ddevault> well, gcc is C++, not C
2018-12-28 03:49:46 <ddevault> so nevermind
2018-12-28 03:50:01 <sorear> the way this worked back when it was a UC Berkeley project is they would make a batch of chips with exactly one very low-level interface, then connect it to a FPGA they had lying around which would proxy access to everything else
2018-12-28 03:50:17 <ddevault> this isn't far from that
2018-12-28 03:50:25 <sorear> because they had research funding to prove that they had a working core, but everything else was out of scope
2018-12-28 03:50:26 <ddevault> they have a high-speed interface for plugging your FPGA into
2018-12-28 03:50:38 <ddevault> but also an on-board mmc and ethernet and some GPIO
2018-12-28 03:50:52 <ddevault> that's about it
2018-12-28 03:50:56 <ddevault> not even an RTC
2018-12-28 03:51:01 <sorear> it's not even MMC, it's just SPI
2018-12-28 03:51:21 <ddevault> dear god
2018-12-28 03:51:24 <ddevault> that's why it's so slow
2018-12-28 03:51:41 <ddevault> they also stuck 8G of RAM on the board
2018-12-28 03:51:54 <ddevault> other than the CPU I think that's pretty much it
2018-12-28 03:52:02 <kaniini> that's the other thing
2018-12-28 03:52:05 <kaniini> why can't they just have
2018-12-28 03:52:07 <kaniini> ram slots
2018-12-28 03:52:12 <ddevault> ¯\_(ツ)_/¯
2018-12-28 03:52:19 <kaniini> like this is the same bullshit
2018-12-28 03:52:20 <kaniini> as ARM
2018-12-28 03:52:30 <kaniini> at least with edgerouter you can get octeon board
2018-12-28 03:52:35 <sorear> apparently nobody likes RAM slots
2018-12-28 03:52:36 <ddevault> just wait till you hear about the boot process
2018-12-28 03:52:36 <kaniini> and expand it to 16gb or more
2018-12-28 03:52:46 <kaniini> well surely that is just
2018-12-28 03:52:47 <kaniini> u-boot
2018-12-28 03:52:48 <kaniini> no?
2018-12-28 03:52:51 <ddevault> nope
2018-12-28 03:53:03 <ddevault> the firmware loads a partition with a magic GPT UUID into RAM and jumps to it
2018-12-28 03:53:17 <ddevault> the only bootloader that exists just jumps into the kernel
2018-12-28 03:53:20 <ddevault> no command line, no initrd
2018-12-28 03:53:30 <kaniini> ddevault: i am going to go back to working on getting pleroma into a packageable state now
2018-12-28 03:53:35 <kaniini> i have heard enough
2018-12-28 03:53:40 <ddevault> I'm going to have to work on the bootloader before this port is viable
2018-12-28 03:53:43 <ddevault> s/port/board/
2018-12-28 03:53:44 <alpine-meetbot> ddevault meant to say: I'm going to have to work on the bootloader before this board is viable
2018-12-28 03:53:46 <ddevault> kaniini: later, then
2018-12-28 03:53:48 <ddevault> o/
2018-12-28 03:53:50 <SpaceToast> kaniini: are we gonna see a pleroma aport eventually then?
2018-12-28 03:53:52 <SpaceToast> that's exciting!
2018-12-28 03:53:59 <kaniini> SpaceToast: yes, as soon as OTP releases are ready
2018-12-28 03:54:02 <SpaceToast> nice!
2018-12-28 03:54:04 <ddevault> OTP?
2018-12-28 03:54:07 <kaniini> SpaceToast: we also need a way of configuring it
2018-12-28 03:54:09 <ddevault> like encryption?
2018-12-28 03:54:12 <kaniini> ddevault: no
2018-12-28 03:54:13 <SpaceToast> /etc? :)
2018-12-28 03:54:17 <kaniini> ddevault: open telephony platform
2018-12-28 03:54:29 <SpaceToast> ddevault: fancy term for "how erlang/beam works"
2018-12-28 03:54:42 <ddevault> is this like some PSTN shit
2018-12-28 03:54:51 <kaniini> ddevault: basically an "OTP release" is the technical term for compiling down to a set of binaries
2018-12-28 03:55:06 <ddevault> sounds like they suck at naming things
2018-12-28 03:55:31 <sorear> it's an erlang thing
2018-12-28 03:55:43 <kaniini> SpaceToast: my intention is to not only have an aport for pleroma, but also make it possible to run in leader/follower mode for high performance clustering
2018-12-28 03:55:52 <SpaceToast> ic
2018-12-28 03:56:35 <kaniini> ddevault: anyway OTP releases are kind of annoying because they are basically statically-linked binaries
2018-12-28 03:56:45 <ddevault> statically linked binaries are cool
2018-12-28 03:56:59 <kaniini> not when you want to use the system erlang packages
2018-12-28 03:57:00 <kaniini> ;)
2018-12-28 03:57:08 <SpaceToast> static linking is good (in most/many cases), but annoying in cases like .... kaniini beat me to it
2018-12-28 03:57:20 <ddevault> yeah aside from annoying distro maintainers static linking is pgreat
2018-12-28 03:57:28 <ddevault> I wish I had time to work on that fully static distro I was making...
2018-12-28 03:58:38 <kaniini> ic
2018-12-28 03:59:11 <ddevault> I eventually realized I was in for a shit-ton of work, alpine was 80% of what I wanted anyway, and if I contributed I might be able to bring that up to 90-95% and call it good enough
2018-12-28 03:59:12 <SpaceToast> ddevault: contribute to stali /s
2018-12-28 03:59:42 <SpaceToast> roughly same here, though I suspect the things we want differ a bit
2018-12-28 03:59:50 <kaniini> ddevault: http://erlang.org/doc/design_principles/release_structure.html
2018-12-28 03:59:54 <kaniini> ddevault: read the manpage :D :D :D
2018-12-28 04:01:02 <ddevault> both projects are just a holdover until I have time to realize The Glorious Dream of Plan 9
2018-12-28 04:05:26 <kaniini> ddevault: so say you realize the glorious dream of plan 9
2018-12-28 04:05:52 <kaniini> how does that effect riscv64 arch on alpine
2018-12-28 04:06:08 <ddevault> the soonest I'm going to realize the glorious dream of plan 9
2018-12-28 04:06:11 <ddevault> is like 20 years from now
2018-12-28 04:06:14 <ddevault> so don't sweat it
2018-12-28 04:06:38 <ddevault> certainty about anything, least of all riscv64 on alpine, approaches zero on that timeline
2018-12-28 04:08:47 <kaniini> lol ok
2018-12-28 05:37:34 <AinNero> is there an exhaustive list of possible CARCH'es somewhere in abuild or aports?
2018-12-28 05:41:44 <AinNero> actuallt, i just want to know if there is an 64-bit variant of mips, and if yes, what its CARCH string?
2018-12-28 05:44:54 <sorear> is functions.sh.in what you want?
2018-12-28 05:45:45 <AinNero> yes
2018-12-28 05:45:46 <AinNero> thanks.
2018-12-28 06:12:47 <AinNero> the libc6-compat code is incomplete and incorrect, having broken symlinks for mips and ppc64el
2018-12-28 06:13:05 <AinNero> and im really infurated that the fixes were attributed to be necessary for go
2018-12-28 06:13:16 <AinNero> because go is unrelated
2018-12-28 06:13:48 <AinNero> i grabbed the official glibc documentation and now we can have correct interpreter paths with PR aports#5926
2018-12-28 10:56:59 <_ikke_> git.a.o will be briefly unavailable in about 30 minutes
2018-12-28 14:08:19 <esy9> Hi, I'm unable to mount fs in Alpine with -o mand flag. It says operation is not permitted, even though I'm root.
2018-12-28 14:08:36 <esy9> Here is the strace screenshot https://transfer.sh/fRiqk/screenshot.png
2018-12-28 14:08:48 <esy9> Any ideas?
2018-12-28 14:15:41 <danieli> you don't happen to have a paste rather than a screenshot?
2018-12-28 14:16:02 <danieli> also, note that this is #alpine-devel, the development channel
2018-12-28 14:20:11 <esy9> https://hastebin.com/yiwusewohu
2018-12-28 14:21:19 <esy9> well, I though this might be related to alpine kernel, so I felt that dev channel might be more appropriate
2018-12-28 14:21:48 <SpaceToast> esy9: I don't think tmpfs supports MANDLOCK, further, you're not usually supposed to use it (it's not POSIX, and subject to lots of race conditions under linux)
2018-12-28 14:22:02 <SpaceToast> so this sounds like an xy problem - care to elaborate *why* you want to do this?
2018-12-28 14:25:20 <SpaceToast> might also be CAP_SYS_ADMIN but idk if you wanna actually use that either ;)
2018-12-28 14:32:14 <esy9> Nothing in particular, I'm trying to really enforce a file write lock while my program is running. On ubuntu mandlock works for tmpfs, the same exact script works correctly.
2018-12-28 14:32:17 <esy9> Might this be an issue with busybox mount?
2018-12-28 14:34:58 <SpaceToast> I just tried on a different system (arch-based) with util-linux same result
2018-12-28 14:35:05 <SpaceToast> seriously though, *why* are you trying to do that?
2018-12-28 14:35:16 <SpaceToast> again, MS_MANDLOCK is full of scary race conditions on linux
2018-12-28 14:35:54 <SpaceToast> (and you still have to enable locks manually with chmod because of course you do)
2018-12-28 14:36:08 <SpaceToast> are you running into issues where your write lock isn't being honored?
2018-12-28 14:36:18 <esy9> I'm actually thinking of a CTF challenge
2018-12-28 14:36:53 <esy9> related to mandlock
2018-12-28 14:37:45 <SpaceToast> ah, so you want to use it *because* it's broken ;)
2018-12-28 14:37:50 <esy9> yes
2018-12-28 14:38:20 <SpaceToast> well, I do believe it's against the spirit of CTF to receive outside help, so good luck :)
2018-12-28 14:38:48 <SpaceToast> if you think it's the kernel, you can modify the linux-vanilla abuild (or, more specifically, config file) to your heart's desire and build your own with abuild(1)
2018-12-28 14:39:49 <esy9> ok, thx anyway
2018-12-28 14:51:36 <esy9> Figured it out. There is kernel option for this, disabled by default in alpine vanilla.
2018-12-28 14:57:22 <TBB> silly question... if I were to build a package that contains suid binaries in an user mode container of sorts, would that cause building such a pckage to fail?
2018-12-28 14:58:59 <danieli> ctf even, I create and participate in them quite a lot
2018-12-28 15:23:47 <AinNero> TBB: setsuid can be set if you own the file
2018-12-28 15:24:18 <AinNero> if you are in a userns environment, and your user is mapped to uid 0, you can have setuid binaries for "root"
2018-12-28 16:44:32 <[[sroracle]]> TBB: you need to add options=“suid” though or abuild will complain
2018-12-28 21:20:09 <danieli> ???
2018-12-28 21:20:33 <SpaceToast> very interesting bug, informative and insightful
2018-12-28 21:23:34 <danieli> indeed
2018-12-28 21:23:51 <danieli> oh, he updated it 3 mins ago
2018-12-29 20:01:46 <PureTryOut[m]> how far along is 3.9?
2018-12-29 20:05:52 <danieli> i'm digging into apk and i'm really mad it's so poorly documented, didn't even compile on my arch box without some patches here and there
2018-12-29 20:08:50 <danieli> most of it seems not to have been touched in 8-10 years
2018-12-29 22:20:27 <hatramatra> i made first package which i would actually consider to push to aports, here is APKBUILD http://tpaste.us/O1qb?hl=true
2018-12-29 22:20:54 <hatramatra> i would appreciate any comments
2018-12-29 22:51:32 <mps> hatramatra: maybe builddir="$srcdir/$pkgname-$pkgver" instead of builddir="$srcdir/minidyndns-$pkgver"
2018-12-29 22:52:30 <mps> and, needn't to post tpaste url with hl=true
2018-12-29 22:52:52 <hatramatra> mps: thanks and sorry :-)
2018-12-29 22:53:33 <mps> don't worry, just noted
2018-12-29 22:54:58 <mps> to me it looks ok, but have one quustion. shouldn't sha512sums be at the bottom of APKBUILD?
2018-12-29 22:55:03 <hatramatra> there is README.md file which goes to -doc subpackage, shall i try to convert it to text only?
2018-12-29 22:55:59 <hatramatra> it was generated like that by newapkbuild, but it's good point, i've moved it to the bottom.
2018-12-29 22:57:19 <mps> not needed becasue markdown is readable with text viewers but would be better if it is converted to plain text, imo
2018-12-29 22:57:42 <mps> although not sure about that
2018-12-29 22:58:28 <mps> and, i presume you tried to build it with 'abuild -r'
2018-12-29 22:58:56 <hatramatra> yes, i tried ... also installed.
2018-12-29 23:00:39 <mps> happy aporting, then :)
2018-12-29 23:09:41 <hatramatra> mps: i will try if I can get that markdown as plain text with something (pandoc?) and then send a patch
2018-12-29 23:10:07 <hatramatra> mps: and thank you!
2018-12-29 23:11:05 <mps> you are welcome
2018-12-30 09:35:17 <hatramatra> does anyone know what happends after $pkgname-openrc is removed/purged? what if it was still running?
2018-12-30 09:36:12 <hatramatra> i tried to find any inspiration in existing aports, if i should deal with removal in .pre-deinstall script, but none of the packages seems to bother.
2018-12-30 09:49:04 <mps> hatramatra: ideally .pre-deinstall should stop running service (if i understood your question) but, yes, seems no one bother about that
2018-12-30 09:55:46 <hatramatra> mps: the problem with .pre-deinstall for me is, that it's part of main package on part of -openrc subpackage
2018-12-30 09:57:01 <hatramatra> there seems to be something called subpackage's split function, but i can't grasp how it works.
2018-12-30 09:57:34 <hatramatra> in other words, i need to make .pre-deinstall script part of -openrc subpackage for it to work reliably
2018-12-30 09:58:39 <mps> yes, that idea to split package to -openrc subpackage sound as not well thought out
2018-12-30 09:59:41 <mps> why I need to have nginx-openrc if I deleted nginx?
2018-12-30 10:01:46 <hatramatra> was it decided in the anticipation of other init/supervisor mechanisms?
2018-12-30 10:02:15 <hatramatra> nginx nginx-openrc nginx-systemd (oh nooo!!!) :-)
2018-12-30 10:03:04 <mps> probably, but I'm not sure if that needed to go to separate packages
2018-12-30 10:05:36 <mps> if runit or s6 becomes new default init 1 then their init script could be added to main package without need to split package to three subpakages (-openrc, -s6, -runit for example)
2018-12-30 10:09:35 <hatramatra> the openrc() function is defined in /usr/bin/abuild script
2018-12-30 10:10:14 <hatramatra> it defines install_if there, so if openrc is installed and main package is installed, it shall add also -openrc subpackage
2018-12-30 10:10:25 <mps> these are my superficial observation, didn't analyze it deeply to judge what is right solution
2018-12-30 10:12:40 <hatramatra> it might be enough to call it $pkgname-openrc.pre-deinstall and it will be picked for the subpackage, let me test
2018-12-30 10:14:43 <hatramatra> yep, that did the trick!
2018-12-30 10:16:16 <hatramatra> also, if i apk added just main package, it automatically installed also -openrc subpackage
2018-12-30 10:16:17 <mps> nice to know, i have to write that in my notes
2018-12-30 10:16:48 <mps> mostly, in my experience
2018-12-30 10:19:13 <hatramatra> right, also --purge del worked just perfectly now, it stopped the service before removal
2018-12-30 10:25:46 <mps> my feeling it that the --purge is to aggresive, or could be, so usualy i don't use it
2018-12-30 10:26:17 <hatramatra> i just failed captcha while creating wiki account, i'm a bloody robot!
2018-12-30 10:26:46 <hatramatra> mps: --purge is just to test all options, service is stopped and removed from all runlevels also without it of course
2018-12-30 10:26:49 <mps> only when want to clean after i make big mess
2018-12-30 10:28:59 <mps> apk del --help says: --purge   Delete also modified configuration files (pkg removal) and uninstalled packages from cache (cache clean)
2018-12-30 10:51:32 <hatramatra> mps: do you think i should update the APKBUILD reference page in the wiki?
2018-12-30 10:59:27 <mps> hatramatra: if it is wrong it should be updated, but who should have to do that idk
2018-12-30 11:00:28 <mps> better to not have guide/info than have a wrong one
2018-12-30 11:24:44 <hatramatra> mps: Orson Teodoro is listed as the one with heavy updates of that page, perhaps i should check with him first, if i knew who that is :-)
2018-12-30 11:27:01 <hatramatra> i'll post email to the mailing list
2018-12-30 11:51:36 <mps> huh, you remembered me maybe is the time for me to register at Alpine wiki
2018-12-30 11:53:40 <mps> i'm not native speaker and not good in writing english so hesitate to write docs but maybe i should with hope that someone change semantic errors after me
2018-12-30 12:01:41 <hatramatra> mps: i'm not native speaker either, my biggest problem is that i struggle to write short and concise text.
2018-12-30 12:02:30 <hatramatra> often i have to rewrite it a few times before i think it's without any ballast
2018-12-30 12:02:41 <hatramatra> but then i hope it gets better over the time
2018-12-30 12:04:23 <mps> i hope for you but not have a big hope that i will become better at that, my experience shows that to me
2018-12-30 12:08:50 <mps> it is not that the english is hard to learn (at least for me) but it's semantic and grammar doesn't fit (fall) in my 'state of thinking'
2018-12-30 12:10:21 <mps> hatramatra: we are OT now, there is a #alpine-offtopic channel for such discussion
2018-12-31 10:52:43 <kunkku> ncopa: re: DAD script getting stuck
2018-12-31 10:52:50 <kunkku> was it the old or the new version?
2018-12-31 12:52:38 <ncopa> i think it was the new
2018-12-31 13:20:03 <fcolista> I'm stucked with lxd
2018-12-31 13:21:20 <SpaceToast> fcolista: did you figure out why the libs are installed as separate files? I still suspect that's a part of the problem
2018-12-31 13:22:09 <fcolista> these libs are shipped withing lxd because are patched with cluster support
2018-12-31 13:22:14 <fcolista> *within
2018-12-31 13:22:39 <fcolista> there are basically two libs needed:
2018-12-31 13:22:47 <fcolista> sqlite with this "clustering" support
2018-12-31 13:22:55 <fcolista> dqlite (distributed sqlite)
2018-12-31 13:23:06 <SpaceToast> fcolista: no, I get that, but in pkg/ they end up not symlinking to each other's SONAME - see https://bugs.alpinelinux.org/issues/9780 where I take a look at the issue and find where the strange behavior is from
2018-12-31 13:23:19 <fcolista> ah ok
2018-12-31 13:23:25 <fcolista> that was the thing you are referring
2018-12-31 13:23:41 <fcolista> no, I haven't figure that yet
2018-12-31 13:23:44 <SpaceToast> yeah - since it only happens to the .so one, not .so.0 or .so.0.8.6
2018-12-31 13:24:14 <SpaceToast> we basically either need to strip before we patchelf, and figure out why they're separate (or overwrite ourselves, but that's an obvious pain re: versioning)
2018-12-31 13:24:15 <fcolista> SpaceToast, we need to figure a way to hanlde this in the long term
2018-12-31 13:24:40 <SpaceToast> aye
2018-12-31 13:24:42 <fcolista> we can put as otions="!nostrip" and patchelf on package()
2018-12-31 13:24:47 <fcolista> wondering if this might work
2018-12-31 13:25:20 <SpaceToast> I think nostrip isn't a long term solution, but that probably would (no time to test right now, leaving for work soon, but I will this pm)
2018-12-31 13:25:25 <fcolista> always in package() the we can do what strip() does..
2018-12-31 13:25:44 <fcolista> SpaceToast, agree that is not a long term solution..
2018-12-31 13:25:55 <SpaceToast> another solution could be to have an option that performs stripbin() before package()
2018-12-31 13:26:03 <SpaceToast> and then enforce patchelf only be called in package()
2018-12-31 13:26:12 <fcolista> another option is building separate sqlite specifically for lxd
2018-12-31 13:26:22 <fcolista> calling in sqlite-lxd() which conflicts with sqlite()
2018-12-31 13:26:25 <fcolista> *sqlite
2018-12-31 13:26:36 <fcolista> dunno why I've putted () :D
2018-12-31 13:26:57 <fcolista> anyway, this will make sqlite-lxd build (havin conflicts=sqlite)
2018-12-31 13:27:09 <fcolista> dqlite requires sqlite to build
2018-12-31 13:27:26 <SpaceToast> do you know if the lxd build process will actually detect that and avoid building the bundled one?
2018-12-31 13:27:39 <SpaceToast> if we need to patch the build system to use system libs it's a pain
2018-12-31 13:27:54 <fcolista> no it does not
2018-12-31 13:28:15 <fcolista> tbh since it uses go, it might be that it does, and I've not seen it
2018-12-31 13:28:26 <fcolista> I'm not acquainted with go
2018-12-31 13:32:46 <Xe> fcolista: it depends on what sqlite library they are using
2018-12-31 13:33:21 <Xe> most of the time people embed the sqlite library in the go libraries because system level linking as a library author is platform specific
2018-12-31 13:33:37 <Xe> (and people just want it to work when you `go get` the package)
2018-12-31 13:33:38 <fcolista> that might be the case
2018-12-31 13:36:09 <SpaceToast> fcolista: setting !strip, and calling stripbin() in package() before running patchelf (with *) fails on the linter
2018-12-31 13:36:22 <SpaceToast> for some reason the linter checks for rpath in $builddir as well
2018-12-31 13:36:39 <SpaceToast> but now I do need to go \o
2018-12-31 13:36:52 <fcolista> thx SpaceToast
2018-12-31 13:41:25 <danieli> fcolista: stuck on dqlite?
2018-12-31 13:43:11 <ncopa> packages in x86 that fails to build for v3.9: http://tpaste.us/ronj
2018-12-31 13:44:42 <fcolista> danieli, not really
2018-12-31 13:45:10 <fcolista> dqlite APKBUILD is easy, but it needs "patched" sqlite  to be built
2018-12-31 13:45:20 <fcolista> "patched" sqlite does not build
2018-12-31 13:46:49 <danieli> i see
2018-12-31 13:46:50 <danieli> why not
2018-12-31 13:46:52 <danieli> ?
2018-12-31 13:47:41 <fcolista> 'cause is not able to find sqlite3.h even if is there...
2018-12-31 13:47:45 <mps> ncopa: libzen fails on other archs to?
2018-12-31 13:49:43 <mps> because sha512sum is invalid. I posted patch  https://patchwork.alpinelinux.org/patch/4349/
2018-12-31 13:51:37 <danieli> fcolista: https://github.com/CanonicalLtd/dqlite#build the Build part was vital for me to build it
2018-12-31 13:51:45 <danieli> it uses the manifest[.uuid] files to generate sqlite3.h
2018-12-31 13:52:11 <fcolista> wth
2018-12-31 13:52:31 <danieli> i think i told you this when we first had a look at it in #alpine-linux
2018-12-31 13:53:01 <fcolista> yes, but I wouldn't go ahead on that path
2018-12-31 13:53:14 <fcolista> having different packages built for lxd
2018-12-31 13:53:15 <ncopa> mps: thanks. that seems to fix it
2018-12-31 13:53:33 <danieli> yeah, but it solves this part -> 14:45:20 <@fcolista> "patched" sqlite does not build
2018-12-31 13:53:53 <danieli> separate package or not, the manifest files are necessary for it to build
2018-12-31 13:53:56 <mps> and dcron site is dead, I can put source from somewhere else if it is ok for you
2018-12-31 13:54:42 <fcolista> yes, thx danieli. Still hoping of having all that stuff in the same APKBUILD, but it seems not easily doable
2018-12-31 13:54:55 <mps> Debian archive, maybe
2018-12-31 13:57:58 <mps> dcron is moved to github, will make APKBUILD patch and post in a hour, i hope
2018-12-31 14:13:07 <mps> ncopa: here is the patch for dcron https://patchwork.alpinelinux.org/patch/4354/
2018-12-31 14:15:10 <danieli> it's new year's eve, i'm surprised it's this active
2018-12-31 14:15:46 <mps> danieli: which year ;)
2018-12-31 14:17:38 <ncopa> mps: is dobiousjim the new maintainer?
2018-12-31 14:19:01 <mps> i don't know, really. don't like to touch maintainer field to not offend someone
2018-12-31 14:20:40 <ncopa> i mean upstream maintainer
2018-12-31 14:20:52 <ncopa> seems he is the upstream maintainer
2018-12-31 14:21:02 <ncopa> the name is familiar. he used to contribute to alpine
2018-12-31 14:21:31 <ncopa> mps: applied it. thanks!
2018-12-31 14:26:05 <mps> yaw, now working on cloc fix
2018-12-31 14:38:30 <mps> ncopa: fix for cloc is here https://patchwork.alpinelinux.org/patch/4355/
2018-12-31 14:39:32 <ncopa> mps: i thought i just pushed the fix?
2018-12-31 14:39:45 <ncopa> yeah
2018-12-31 14:39:48 <ncopa> commit 1898000c94c1b3f2909908f358e5b76040e3ad60
2018-12-31 14:39:48 <ncopa> Author: Natanael Copa <ncopa@alpinelinux.org>
2018-12-31 14:39:48 <ncopa> Date:   Mon Dec 31 13:48:54 2018 +0000
2018-12-31 14:39:48 <ncopa>     community/cloc: update source url
2018-12-31 14:41:47 <mps> ah, ok, never mind. duplicate work
2018-12-31 14:42:31 <mps> anyway, do you have a list of packages which need fixes
2018-12-31 14:51:45 <danieli> ncopa: yara patch to bump it, it's trivial, and i tested that it works http://tpaste.us/P0jQ
2018-12-31 14:52:07 <danieli> removed some patches (seems to have gotten fixed upstream) and bumped the version
2018-12-31 14:52:12 <danieli> tests also ran, so i re-enabled them
2018-12-31 15:06:12 <ncopa> mps: this is for x86: http://tpaste.us/65En
2018-12-31 15:23:05 <mps> volatility fails on x86_64 also, but needs change source only
2018-12-31 15:23:28 <kunkku> ncopa: it would be interesting to see the output of "ip address" when the DAD script gets stuck
2018-12-31 15:24:09 <kunkku> is there an env where the issue can be easily reproduced?
2018-12-31 15:24:10 <mps> ncopa: should I post patch or copy-paste new url here
2018-12-31 16:01:23 <mps> ncopa: community/volatility fix is here https://patchwork.alpinelinux.org/patch/4356/
2018-12-31 16:04:39 <fcolista> what is this error?
2018-12-31 16:04:39 <fcolista> ERROR: sqlite-lxd: builddeps failed
2018-12-31 16:05:28 <fcolista> neverminf
2018-12-31 16:05:32 <fcolista> fixed
2018-12-31 16:06:10 <danieli> lol
2018-12-31 16:08:17 <fcolista> i got sqlite packaged
2018-12-31 16:08:52 <fcolista> https://dpaste.de/jv63/raw
2018-12-31 16:09:04 <fcolista> I've called it sqlite-lxd
2018-12-31 16:34:49 <mps> ncopa: community/wireshark fix patch is here https://patchwork.alpinelinux.org/patch/4358/
2018-12-31 19:48:08 <fcolista> danieli, you around?
2018-12-31 19:53:02 <fcolista> https://dpaste.de/4aHY/raw
2018-12-31 20:16:13 <jwh> o/
2018-12-31 20:16:15 <jwh> hello
2018-12-31 21:33:28 <ddevault> \o
2018-12-31 21:33:50 <ddevault> bah, I have too many -devel channels open, this isn't the one with recent activity