2018-12-01 01:10:09 heh 2018-12-01 01:10:47 so go finally got a build in dep manager 2018-12-01 01:49:56 SpaceToast, did you have a working apkbuild for hugo? 2018-12-01 01:51:34 clandmeter: yes, over at https://github.com/5paceToast/aports/blob/master/toast/hugo/APKBUILD 2018-12-01 01:51:52 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 (that applies to anything there, mind you) 2018-12-01 18:40:54 it's been quiet here today 2018-12-01 18:56:02 <_ikke_> yes 2018-12-01 19:25:44 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 u ever watch that old black and white clip of them playing it live 2018-12-01 19:41:39 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 yeah thats it 2018-12-01 19:52:17 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 yeah 2018-12-02 17:28:47 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 SpaceToast, pushed fix 2018-12-02 19:42:44 thx for the reminder :) 2018-12-02 19:42:47 <_ikke_> clandmeter: nice 2018-12-03 11:59:50 i wonder if boot.alpinelinux.org is broke? 2018-12-03 11:59:53 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 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 maybe its qemu thats broken 2018-12-03 12:01:33 might be, have you ran that command before, and it worked? 2018-12-03 12:02:05 ncopa, i moved the container, maybe i broke something. 2018-12-03 12:02:16 looks ok from here 2018-12-03 12:02:29 jwh: did you actually test with the range header? 2018-12-03 12:02:38 [jwh@pyxis ~]$ curl -s --head -C10 https://boot.alpinelinux.org/alpine-ipxe/x86_64/ipxe.iso | grep range 2018-12-03 12:02:41 accept-ranges: bytes 2018-12-03 12:02:41 content-range: bytes 10-1048575/1048576 2018-12-03 12:03:04 -r 0-500 works for me 2018-12-03 12:03:08 he is probably using a different httpd :) 2018-12-03 12:03:09 must be broken qemu 2018-12-03 12:04:23 ncopa, what does boot.a.o resolve to? 2018-12-03 12:05:47 nld3 here, fwiw 2018-12-03 12:05:50 same 2018-12-03 12:06:22 he is probably using an infra container 2018-12-03 12:06:24 it uses local dns 2018-12-03 12:07:22 ah 2018-12-03 12:07:36 ncopa, i updated unbound 2018-12-03 12:07:50 should now resolve to the proxy instead of the container directly. 2018-12-03 13:25:55 no, i think its qemu or curl that is broken 2018-12-03 13:28:12 what is your qemu version? 2018-12-03 13:28:24 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 QEMU emulator version 2.12.0 2018-12-03 13:28:56 qemu-2.12.1-r2 2018-12-03 13:29:11 aha, from edge 2018-12-03 13:30:11 boots with http instead of https 2018-12-03 13:32:59 could be gnutls problem, but I'm not sure i.e. didn't test that 2018-12-03 13:38:32 ncopa, you are not using it on your infra container? 2018-12-03 13:38:33 btw, qemu upstream stable is 3.0 while AL in edge is 2.12 2018-12-03 13:40:08 mps, its not ;-) 2018-12-03 13:40:23 http://dup.pw/aports/d5172d82 2018-12-03 13:42:21 heh, need to 'git pull' local aports 2018-12-03 13:43:51 maybe put cron job to pull it wvery few hours :) 2018-12-03 13:44:26 you can also listen on mqtt and pull when needed. 2018-12-03 13:44:48 apk add mqtt-exec 2018-12-03 13:45:00 i just git pull whenever i'm working with it 2018-12-03 13:45:44 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 you noticed ':)' at the end of my post ;) 2018-12-03 13:48:39 looked at mqtt-exec but didn't tried, yet 2018-12-03 16:59:00 ncopa: sure 2018-12-03 16:59:20 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 mkinitfs generates initramfs-${version}, which is not in the hardcoded list 2018-12-03 17:00:21 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 but in general, we probably want our initrd to be detected "normally" 2018-12-03 17:00:54 the fix is relatively simple, just add "initramfs-${version}" and "initramfs-${alt_version}" to that list 2018-12-03 17:01:14 i think we can carry patch for that in our grub package 2018-12-03 17:01:18 (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 okay, I'll re-poke here if/when it gets patched upstream :) 2018-12-03 20:41:17 hmm, we don't have a py3 mysql driver in aports? 2018-12-03 22:09:48 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 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 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 morning ncopa 2018-12-04 07:29:38 anyone figure out aarch64 gdb yet? 2018-12-04 07:29:54 linux-headers / musl-dev header conflict 2018-12-04 08:35:50 morning 2018-12-04 08:36:00 danieli: yes its a problem in linux-headers 2018-12-04 08:36:20 nsz in #musl said he knew someone that had a patch for it 2018-12-04 08:36:44 for gdb? 2018-12-04 08:36:51 i fixed it in another package, but i practically monkey patched it 2018-12-04 08:37:56 yes, it should solve gdb 2018-12-04 08:38:20 lemme test, 1 sec 2018-12-04 09:24:55 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 AinNero: yeah. should do that before 3.9.0_rc1 2018-12-04 10:14:13 speaking of mkinitfs 2018-12-04 10:15:17 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 I guess we want the command line override the config 2018-12-04 11:21:36 who is work on it? 2018-12-04 11:21:40 s/is/will/ 2018-12-04 11:24:06 patches are welcome. im not going to work on that anytime soon 2018-12-04 12:13:15 ncopa: hm, how come gdb fails on aarch64 but not any other arch? 2018-12-04 12:13:17 seems a bit odd 2018-12-04 14:22:03 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 danieli: because the linux headers are arch specific 2018-12-04 14:39:36 aha 2018-12-04 14:40:23 seems odd for sigcontext to be different though? 2018-12-04 14:50:57 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 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 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 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 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 instead of trying to get it merged into our own build processes 2018-12-04 15:30:36 yeah; I've been doing stuff with lxd for a while now so I could have a look 2018-12-04 15:39:37 lxd is quite nice :) 2018-12-04 15:40:08 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 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 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 (and then, still inside of it, tries to mount what it coldplugged, and looks for apkovl) 2018-12-04 15:44:29 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 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 yeah, that's another part of why I dislike it 2018-12-04 15:47:43 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 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 can somebody with commit rights to main look at this https://github.com/alpinelinux/aports/pull/5591 ? 2018-12-05 05:06:59 HRio: try during daytime in europe, you'll probably have better luck then 2018-12-05 05:07:17 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 heh. 2018-12-05 08:59:42 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 ncopa: "mark" as in, approve it? 2018-12-05 09:16:06 I'm guessing to label them 2018-12-05 09:17:49 yeah, we should probably label them with v3.9 or similar 2018-12-05 09:34:57 ncopa: do you have url for these PRs? will look but I'm not promising anything 2018-12-05 09:36:10 although noticed on $alpine-commits some which repeatedly fails to build 2018-12-05 09:36:31 s/$/#/ 2018-12-05 09:42:13 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 installed. 2018-12-05 09:42:29 never mind, found PRs on github 2018-12-05 10:04:40 hello, what are your mail server recommendations? thanks 2018-12-05 10:05:57 opensmtpd 2018-12-05 10:06:45 milliardo: ok, what about imap? 2018-12-05 10:07:03 I don't use it. 2018-12-05 10:07:18 milliardo: how to retrieve mail then? what do you use? 2018-12-05 10:07:30 ssh 2018-12-05 10:07:58 okay, we have other requirements here, thanks for your answers 2018-12-05 10:09:44 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 #alpine-linux perhaps? 2018-12-05 10:10:33 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 Please move this conversation 2018-12-05 10:10:39 what danieli said :) 2018-12-05 10:12:36 sorry 2018-12-05 11:03:06 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 tboerger[m], hi 2018-12-05 11:04:36 lo :) 2018-12-05 11:04:51 you can override the dev function if you dont agree with it. 2018-12-05 11:05:26 you could do default_dev and then move it back to $pkgdir 2018-12-05 11:06:59 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 you can grep aports for "^dev() {" 2018-12-05 11:08:04 tboerger[m], abuild has a default_dev function defined. 2018-12-05 11:08:22 ok, thanks... will try to find more out on that way. 2018-12-05 11:08:24 it does some logic we thing is logical. but it doesnt always do whats needed. 2018-12-05 11:08:44 it gets called by the dev function 2018-12-05 11:09:13 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 *so 2018-12-05 11:11:27 ok cool 2018-12-05 14:07:43 ncopa, about 3.9 would be great to accept https://github.com/alpinelinux/aports/pull/5569 2018-12-05 14:29:59 ok 2018-12-05 14:30:28 i wonder what we do with edge users? 2018-12-05 14:30:35 when they start complain 2018-12-05 14:31:55 ncopa: edge users? complain about PHP 5? 2018-12-05 14:32:01 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 ^^^ 2018-12-05 14:32:17 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 security support for 5.6 is over the 31st 2018-12-05 14:32:55 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 you might as well go for RHEL or ancient debian 2018-12-05 14:33:47 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 that project is isolated to an alpine release specifically because of that 2018-12-05 14:34:53 a rolling release (distro|branch) doesn't sound like a good choice for legacy software like that 2018-12-05 14:35:32 yeah precisely 2018-12-05 14:37:04 ncopa: reminds me, you should upgrade jenkins in 3.8 to 2.121.3 (from .1) 2018-12-05 14:37:08 https://jenkins.io/security/advisory/2018-12-05/ 2018-12-05 14:37:23 (...) 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 some new releases will be pushed pretty quickly i think 2018-12-05 14:59:21 alright, make some progress getting the A+ to boot 2018-12-05 15:00:07 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 however i can't seem to get any UART output past the bootloader 2018-12-05 15:00:55 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 made a bit more progress: http://ix.io/1viH 2018-12-05 19:35:32 why is `sane` only built for x86 and x86_64? the APKBUILD says nothing about it? 2018-12-05 19:35:58 also, why does its $license not make sense at all? someone half-assed SPDX 2018-12-05 19:41:39 Because licensing has only recently been taken seriously 2018-12-05 19:42:07 With help of spdx 2018-12-05 20:41:53 danieli: sure, I was done though :) 2018-12-05 20:45:13 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 yes, iirc that was mostly affecting docker 2018-12-05 20:47:11 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 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 what we do have control over is our own mirrors 2018-12-05 20:50:29 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 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 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 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 signatures :) 2018-12-05 20:52:11 sure, but what do signatures have to do with the argument being applied? 2018-12-05 20:52:22 those will exist whether or not we have tls 2018-12-05 20:52:32 mirrors aren't insecure, either they are or aren't 2018-12-05 20:52:50 yes, which makes the whole "false sense of security" argument all the more silly, imo 2018-12-05 20:52:50 if you consciously install someone else's public key into your /etc/apk/keys, that's on you 2018-12-05 20:52:57 most people don't look at their mirror list to begin with 2018-12-05 20:53:00 it's more about https in general 2018-12-05 20:53:29 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 alternative, if the inconsistency you introduce is that we have less desireable things - is that good? 2018-12-05 20:54:27 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 I never said it's a blocking priority issue 2018-12-05 20:54:45 I said it's something that would be desireable to have 2018-12-05 20:54:52 very different, statement, isn't it? 2018-12-05 20:55:09 I'm elaborating on the argument, a detail I missed 2018-12-05 20:56:11 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 Wouldn't https make it harder to use something like squid for caching? 2018-12-05 20:56:42 (I'm not sure if anyone does that though) 2018-12-05 20:56:59 fastly does cache, iirc the origin server for fastly is dl-5 or dl-4 2018-12-05 20:57:02 and some mirrors cache 2018-12-05 20:57:09 GrantM11235: I don't think anyone does that, and squid has a mode for https proxying 2018-12-05 20:57:45 anyway, for caching, it'd have to terminate ssl and re-encrypt towards the origin server 2018-12-05 20:57:58 you could use a CONNECT tunnel but squid won't touch the contents 2018-12-05 21:03:32 https://whydoesaptnotusehttps.com/ 2018-12-05 21:04:04 good one! 2018-12-05 21:04:29 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 "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 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 we have a large amount of worldwide mirrors, but we don't control them 2018-12-05 21:05:38 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 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 *optional* https would be nice for alpine mirrors 2018-12-05 21:05:55 to which I say... so what if users feel safe when using your (controlled) mirror? 2018-12-05 21:06:16 this is under the assumption that such users even look at mirrors in detail to begin with 2018-12-05 21:09:21 and I don't mind it being optional, sure :) 2018-12-05 21:10:02 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 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 I don't see it as much extra work, at least with LE-equipped systems 2018-12-05 21:11:23 (in fact, my webserver of choice (caddy) defaults to having https enabled, and can synchronize accross clusters) 2018-12-05 21:11:42 so my PoV is more that it has a very low cost, and no real disadvantages 2018-12-05 21:12:13 we don't run caddy, and consistently deploying / maintaining LE (for little or no gain) is extra work 2018-12-05 21:13:05 with a sufficiently large amount of mirrors, there likely is (or at least should be) automation in place 2018-12-05 21:13:15 in which case the cost is one-time, to set up said extra automation bit 2018-12-05 21:13:30 with a lower amount of mirrors (where it's all done by hand), the cost is similarly lower 2018-12-05 21:13:39 we're working on the automation part, most is manual now 2018-12-05 21:13:43 but my point isn't "everyone start running and deploying TLS!" 2018-12-05 21:13:57 my point is "it is good to have it be available, if that is feasible" 2018-12-05 21:14:09 (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 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 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 (or did we come up with a different solution) 2018-12-07 06:11:13 geosmin: i think that issue category is automatically assigned to me, so its ok 2018-12-07 07:27:35 SpaceToast, i talked to ncopa, i think he wanted a different approach. 2018-12-07 07:31:36 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 i think you should post it on alpine-devel and we can discuss it there 2018-12-07 08:31:04 i need to go out for a few hours 2018-12-07 08:31:20 would be good if we could try fix the v3.9 builds 2018-12-07 09:03:00 ncopa: got a list of them? 2018-12-07 09:03:10 ugh, nevermind, I don't even have a 3.9 system to test on 2018-12-07 09:12:17 danieli, 3.9 is same as edge 2018-12-07 09:12:22 fair enough 2018-12-07 09:12:24 thanks clandmeter 2018-12-07 09:12:32 got a list of broken stuff? 2018-12-07 09:12:55 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 i cannot access the x86 builders 2018-12-07 09:13:36 _ikke_, could maybe provide those. 2018-12-07 09:14:13 i can give you the list of armv7, but thats probably a mix of different cases. 2018-12-07 09:14:43 indeed, there are some arm-only edge cases in there too 2018-12-07 09:14:57 and you dont have an arm builder :) 2018-12-07 09:15:01 but that can be fixed 2018-12-07 09:15:11 I only have x86_64 2018-12-07 09:15:30 we can set one up. but not right now. 2018-12-07 09:19:44 clandmeter: I noticed one or two failed builds on armv7 for which I have fix 2018-12-07 09:20:19 to post these fixes to alpine-devel 2018-12-07 09:20:22 ? 2018-12-07 09:23:22 mps, you can also send them to alpine-aports 2018-12-07 09:23:34 if they are aports diffs 2018-12-07 09:24:04 or just tpaste them here 2018-12-07 09:24:10 whatever you prefer 2018-12-07 09:26:03 <_ikke_> danieli: http://tpaste.us/ba4e 2018-12-07 09:26:19 _ikke_: .. context? 2018-12-07 09:26:21 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 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 I'm really confused 2018-12-07 09:30:20 <_ikke_> ok, feel free to ignore then 2018-12-07 09:31:52 haha 2018-12-07 09:32:06 _ikke_, i was meaning build errors of v3.9 2018-12-07 09:32:12 <_ikke_> ah, sorry :-/ 2018-12-07 09:32:16 np 2018-12-07 09:33:09 _ikke_, in the aports dir of v3.9 please ls the src dirs 2018-12-07 09:33:25 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 _ikke_: swi-prolog and mercury aren't in alpine 2018-12-07 09:35:28 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 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 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 aports@lists.a.o actually 2018-12-07 10:04:25 er 2018-12-07 10:04:29 alpine-aports@lists.a.o 2018-12-07 10:06:59 danieli: ok, have it written somewhere but not in head 2018-12-07 10:12:15 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 now remember that we talked here about removing jemalloc from some packages 2018-12-07 10:13:53 sory for noise 2018-12-07 14:28:01 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 ncopa: scratch that it works just fine :) 2018-12-07 14:41:54 geosmin: good! thank you for a good bug report 2018-12-07 15:23:45 ncopa, yesterday php has 4 security releases but CVEs not filed yet, I prepared PRs 2018-12-07 15:24:11 how to schedule backports? 2018-12-07 15:24:38 another problem is https://github.com/alpinelinux/aports/pull/4843 2018-12-07 15:24:51 on 3.7 we have tests enabled and they fail 2018-12-07 15:26:27 should I disable them? because different tests fail on differenrent arches 2018-12-07 15:37:54 hum... i think the intl and time related testa can be disabled 2018-12-07 15:38:02 they likely has some GNU specific test 2018-12-07 15:38:14 would be good to confirm though 2018-12-07 15:38:22 the otherone is more worrisome 2018-12-07 15:38:34 posix_getpwuid 2018-12-07 15:38:48 i dont see any reason to why that would fail 2018-12-07 15:39:17 andypost: in general, it would be good to investigate why the tests fail 2018-12-07 15:41:28 intel-ucode fails to build on aarch64, is it needed for that arch 2018-12-07 15:46:49 ncopa, intl & time yes, they always flux, the rest will dig 2018-12-07 15:49:12 thanks 2018-12-07 15:49:38 mps: really? 2018-12-07 15:49:42 ok, I'll enable it 2018-12-07 15:49:54 i thought intel-ucode was an intel only thing 2018-12-07 15:50:55 I think so, imo it should be disabled for aarch64 2018-12-07 15:52:32 mps: sorry, i read your wrong. i read "it is needed forthat arch" 2018-12-07 15:52:44 i have already disabled it 2018-12-07 15:53:35 ok, maybe I wasn't clear enough, language barrier 2018-12-07 16:05:07 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 we only provide security fixes for community for latest stable (currently v3.8) 2018-12-07 16:06:43 ah... then it much easy! 2018-12-07 16:08:39 it means only 3.5 needs update & 5770 + 5771 PRs) 2018-12-07 16:09:39 so I will rework https://github.com/alpinelinux/aports/pull/5487 2018-12-07 16:11:40 how long it takes for patch posted to alpine-aports to appear on patchwork.a.o 2018-12-07 16:12:06 andypost: i can push https://github.com/alpinelinux/aports/pull/4843 since you done the work already 2018-12-07 16:12:41 sorry 2018-12-07 16:12:45 i meant the one for v3.5 2018-12-07 16:13:06 ncopa, let me update it to latest release 2018-12-07 16:13:13 this one: https://github.com/alpinelinux/aports/pull/5163 2018-12-07 16:13:31 im ready to push PR 5163 2018-12-07 16:13:44 yep, this fine 2018-12-07 16:13:55 done 2018-12-07 16:13:56 3.5 nbackport I will prepare soon 2018-12-07 16:24:43 ncopa, merge error in https://github.com/alpinelinux/aports/commit/d7284ad8b85e17a80a84f29d6c297c71391c4dd4 2018-12-07 16:24:57 ugh... 2018-12-07 16:25:02 i need a weekend... 2018-12-07 16:25:15 also https://github.com/alpinelinux/aports/pull/5770 this need to be ported to 3.8 as well 2018-12-07 16:26:57 it says in comment that https://github.com/alpinelinux/aports/pull/5487 is the backport? 2018-12-07 16:27:00 5.6.38 => 5.6.39 2018-12-07 16:27:05 which I merged 2018-12-07 16:27:17 oh, ok 2018-12-07 16:27:25 you pushed faster then I rebased changes) 2018-12-07 16:27:57 lucky is that it was last php5 and 7.0 upgrades! 2018-12-07 16:29:04 im working on php5-5.6.39 for v3.8 2018-12-07 16:29:15 will just run a test build and then I'll push 2018-12-07 16:31:18 on my side trying to get how to emable testing 2018-12-07 16:31:46 it runs too long so we disbled it for travis 2018-12-07 16:32:39 but posix_getpwuid is really strange failure 2018-12-07 16:33:48 which branch was it that got the test failure? 2018-12-07 16:34:41 3.7 2018-12-07 16:44:09 problem does not appear on edge? 2018-12-07 16:45:10 yep, because we disabled a lot of tests to allow fit then in travis run 2018-12-07 16:46:14 in 3.6 & 3.7 we used mostly whole test suite 2018-12-07 16:46:31 SKIP_SLOW_TESTS=1 SKIP_ONLINE_TESTS=1 2018-12-07 16:47:09 i think its reasonablei think those are reasonable 2018-12-07 16:49:42 yes, online ones fails randomly 2018-12-07 16:52:06 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 maybe travis also should run full tests 2018-12-07 16:52:36 i'm not sure that's such a good idea ncopa 2018-12-07 16:52:38 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 many packages have tests that fail only on certain architectures 2018-12-07 16:53:02 and those packages can get royally f*cked on those architectures 2018-12-07 16:53:06 hum 2018-12-07 16:53:12 right, thats a good point 2018-12-07 16:53:52 oh... we dont run tests at all currently for x86_64 2018-12-07 16:54:08 and we allow test failures on some other arches 2018-12-07 16:54:21 but they're explicitly allowed to fail, are they not? 2018-12-07 16:54:36 sadly yes, we allow them fail 2018-12-07 16:54:54 i think they were allowed to fail due to lack of resources to fix those 2018-12-07 16:55:53 well, shit.. that's not a good sign 2018-12-07 16:56:04 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 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 grep FIXME .... 2018-12-07 16:57:08 125 2018-12-07 16:57:14 andypost: that's not as bad as I expected 2018-12-07 16:57:27 thing is, I won't be able to do anything about anything else than x86_^4 2018-12-07 16:57:34 s/^4/64/ 2018-12-07 16:57:45 oh there is grep XXX too 2018-12-07 16:58:02 I got scaleway arm8 so will check on it 2018-12-07 16:58:08 FIXME, XXX, HACK, TODO, OPTIMIZE 2018-12-07 16:58:11 common ones 2018-12-07 16:58:24 some times also WTF 2018-12-07 16:59:04 we have a few TODO 2018-12-07 16:59:58 and yes, i think we are in a not too bad shape 2018-12-07 17:00:03 i think s390x is the worst 2018-12-07 17:00:16 do we even have anyone working on s390x anymore? 2018-12-07 17:00:21 no 2018-12-07 17:00:26 what do we do about it? 2018-12-07 17:00:35 do we have access to administrate the actual VM? 2018-12-07 17:00:35 i havent heard from tmh1999 for ages 2018-12-07 17:00:38 yes 2018-12-07 17:00:39 iirc no, because z/VM 2018-12-07 17:00:50 well, thats true 2018-12-07 17:00:55 we cannot admin the vm itself 2018-12-07 17:01:08 I used to try chroot with s390 but it mostly not working 2018-12-07 17:01:38 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 as far as i understand, he was in the open mainframe project internship program 2018-12-07 17:01:53 and those usually aren't permanent 2018-12-07 17:02:09 it's odd he went completely MIA 2018-12-07 17:02:34 do we even have any heavy alpine s390x users? 2018-12-07 17:05:34 ibm wanted alpine on s390x because docker told them they needed it to run docker 2018-12-07 17:05:52 that was my understanding at least 2018-12-07 17:05:59 right, yeah, alpine is the basis for moby too iirc 2018-12-07 17:06:06 correct 2018-12-07 17:06:07 docker on various platforms use 'moby vm' 2018-12-07 17:06:20 i'm just vaguely-ish familiar with it 2018-12-07 17:06:58 but i dont think there are any users on s390x that runs anything without commercial contract 2018-12-07 17:07:06 well, it's IBM, that part is fairly obvious 2018-12-07 17:07:08 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 s390x is basically banks and insurance companies 2018-12-07 17:07:58 yup, I've done mainframe hacking (security work) 2018-12-07 17:08:26 danieli: i completely agree, and I have tried tell them that 2018-12-07 17:08:36 i have met some of the IBM people 2018-12-07 17:08:47 ppc64le is a different story 2018-12-07 17:08:53 that's unicamp, isn't it? 2018-12-07 17:09:28 yes, i think so 2018-12-07 17:09:33 unicamp br, yeah 2018-12-07 17:09:33 it is 2018-12-07 17:09:44 is there a tangible reason why we support ppc64le? 2018-12-07 17:09:57 same. ibm wanted docker 2018-12-07 17:10:04 ah, all right, same reason 2018-12-07 17:10:15 strange they haven't been able to get musl to utilize power9 properly yet 2018-12-07 17:10:17 but ppc64le users are different. its more x86 like 2018-12-07 17:10:27 yeah, s390x cpus are quite different 2018-12-07 17:10:37 more normal people runs ppc 2018-12-07 17:10:58 you buy the machine and run whatever you want on it 2018-12-07 17:11:19 yeah, it's more commodity hardware 2018-12-07 17:11:26 *more* commodity anyway 2018-12-07 17:11:33 yeah 2018-12-07 17:11:57 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 but then again, you're probably the only contact point ibm has with us 2018-12-07 17:12:23 yes 2018-12-07 17:12:25 you're the BDFL 2018-12-07 17:12:34 or at least that's the implicit role 2018-12-07 18:00:55 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 well, you did say email on it was screwy clandmeter 2018-12-07 18:17:00 mps: I haven't received your patch on the ML 2018-12-07 18:17:12 did you maybe send it while l.a.o was down or buggy? 2018-12-07 18:17:28 some changes were made to patchwork 2018-12-07 18:17:33 aha 2018-12-07 18:17:41 or so i believe, anyway 2018-12-07 18:18:58 SpaceToast: I've got reply from the alpine-aports ML 2018-12-07 18:19:21 not reply actually, but resent message 2018-12-07 18:20:00 searching for "wiri" in my Alpine/Aports folder has no results 2018-12-07 18:20:05 again I'm not saying *you*'re at fault 2018-12-07 18:20:13 I'm saying that this may have happened during a period of instability 2018-12-07 18:21:12 no problem, I didn't thought that you say I'm at fault. 2018-12-07 18:23:11 mps: i'll commit it, but it needs to bump pkgrel i think 2018-12-07 18:23:17 i'll fix that 2018-12-07 18:23:48 yes, right, forgot bump 2018-12-07 18:24:17 i am slightly in doubt if it is strictly needed 2018-12-07 18:25:05 and commit message needs to be prefixed with community/wiringpi 2018-12-07 18:25:29 maybe not, because it works fine is on armhf without that fix 2018-12-07 18:25:50 the question is if the built binary is modified by the change or not 2018-12-07 18:26:00 i bumped it, just in case 2018-12-07 18:26:18 ok, tnx 2018-12-07 18:26:53 only change is added '-fpic' to make 2018-12-07 18:28:22 btw, it works with that fix about two weeks on armv7 without problem 2018-12-07 18:38:00 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 kpcyrd: i am not aware of any prior work for full encryption support to the alpine installer 2018-12-07 18:40:24 if we're opinionated about FDE, we have to make sure it's technically correct and waterproof 2018-12-07 18:42:29 i would also want it to be implemented without any extra questions (unless you actually want encryption) 2018-12-07 18:43:22 so we dont want a question like: "Do you want enable encryption? (y/n) [n]" 2018-12-07 18:43:32 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 mps, if it doesn't pop up on the list then it's not pw issue 2018-12-07 18:44:24 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 i'm ok to only support FDE for "sys" install initially 2018-12-07 18:45:10 ncopa: maybe as an additional option during the disk setup? that should be possible without breaking existing answerfiles 2018-12-07 18:45:12 ncopa: +1 2018-12-07 18:45:27 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 mps: if you have an apkbuild that works on edge and uses openssl, i can test it out 2018-12-07 18:46:19 no, i've upgraded it on stable 2018-12-07 18:46:40 im thinking: How would you like to use ? ('sys', 'data', 'lvm', 'crypt' or '?' for help) [?] 2018-12-07 18:46:49 if you can make it work on edge, it'll pretty much work on 3.9 2018-12-07 18:47:02 ncopa: that's what I had in mind, yes 2018-12-07 18:47:19 danieli: understand that, but have to setup edge build localy 2018-12-07 18:47:30 that is true, shouldn't take long though 2018-12-07 18:47:44 assuming you're somewhat used to setting up build environments 2018-12-07 18:48:10 last time it was chroot for aarch64 2018-12-07 18:48:16 mps: or you can test it in docker 2018-12-07 18:48:21 ^ 2018-12-07 18:48:23 that's what i do locally 2018-12-07 18:48:45 don't have experience with docker :( 2018-12-07 18:48:50 and bind mount the dir where you have the aports tree 2018-12-07 18:48:57 doesn't have to be docker though, it was just an example 2018-12-07 18:49:27 chroot is what used to, and sometimes lxc 2018-12-07 18:49:38 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 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 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 ncopa: ok, will try. it is time for me to learn about docker :) 2018-12-07 18:51:32 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 when you exit the shell it will destroy your container 2018-12-07 18:52:18 will try this night 2018-12-07 18:52:40 the above also mounted /path/to/aports on the host to /aports in the container 2018-12-07 18:52:50 so whatever you store there is preserved 2018-12-07 18:53:02 uff. destroy? there is no way to use it another time without all that setups 2018-12-07 18:53:16 you can build your own docker image 2018-12-07 18:53:28 it's the --rm flag to `docker run`, removes it when the entrypoint process ends 2018-12-07 18:53:37 yeah 2018-12-07 18:54:07 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 there is tons of good docks on docker 2018-12-07 18:54:22 would be nice to have persistent build system 2018-12-07 18:54:32 then you skip the --rm 2018-12-07 18:54:40 aha, ok 2018-12-07 18:54:48 I just have a docker container running, without rm 2018-12-07 18:54:56 you can have long lived docker containers 2018-12-07 18:55:14 that's what i like to have 2018-12-07 18:55:54 btw, that works for all archs 2018-12-07 18:55:57 ? 2018-12-07 18:56:07 i don't see how this is arch specific? 2018-12-07 18:56:11 we're talking about docker here 2018-12-07 18:56:18 docker is docker 2018-12-07 18:56:51 nice, then I could have it for aarch64 and armv7 2018-12-07 18:57:09 if you have a docker host running on aarch64 and armv7 hosts, then sure 2018-12-07 18:57:12 er 2018-12-07 18:57:12 yes 2018-12-07 18:57:19 s/docker host/docker instance/ 2018-12-07 18:57:32 maybe there is no official armv7 image yet 2018-12-07 18:57:42 but aarch64 should work at least 2018-12-07 18:57:46 anyway, try `docker run -dit --name some_name alpine:edge` then `docker exec -it some_name sh` 2018-12-07 18:58:23 Supported architectures: amd64, arm32v6, arm64v8, i386, ppc64le, s390x 2018-12-07 18:58:25 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 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 mps: also, heads up, ncopa works there (docker) :P 2018-12-07 19:00:04 'apk search docker' on armv7 'says' that it is not found 2018-12-07 19:00:27 ncopa: did we build world on armv7 and offiically release it? 2018-12-07 19:00:39 nvm, will try it first on x86_64 2018-12-07 19:00:41 danieli: not yet 2018-12-07 19:01:04 that's what i thought 2018-12-07 19:01:20 how come it's still not working? 2018-12-07 19:03:05 ncopa, any idea why edge docker image points to 3.7 repos? https://gist.github.com/andypost/f4c7edc33dcf92eed1a405c2309aa303 2018-12-07 19:03:17 I mean arm8 image 2018-12-07 19:03:44 ... uh? 2018-12-07 19:03:54 what's your /etc/apk/repositories ...? 2018-12-07 19:04:20 andypost: no. sounds like a bug 2018-12-07 19:04:32 we need clean up that 2018-12-07 19:04:35 danieli, as apk points http://dl-cdn.alpinelinux.org/alpine/v3.7/main 2018-12-07 19:04:58 that didn't really clarify it to me 2018-12-07 19:05:16 the edge image is pretty old 2018-12-07 19:05:26 probably because we don't publish snapshots very often 2018-12-07 19:05:28 danieli: the edge image has v3.7 in repos 2018-12-07 19:05:42 aaah, gotcha 2018-12-07 19:05:46 now it makes sense 2018-12-07 19:05:47 it should still have edge in repos though :/ 2018-12-07 19:05:50 the edge image was probably built using the v3.7 release tarball 2018-12-07 19:05:50 why though? 2018-12-07 19:06:01 oh I already used to comment on it https://github.com/gliderlabs/docker-alpine/issues/375 2018-12-07 19:06:22 because we don't make release snapshots from edge as we should 2018-12-07 19:06:42 it was one of the reasons i started a releng thread on alpine-devel list recently 2018-12-07 19:07:01 who exactly is gliderlabs, and how come that's the alpine 'offical repository'? 2018-12-07 19:07:17 we need make snapshots monthly or so from edge 2018-12-07 19:07:34 gliderlabs is a small company that created alpine docker image early 2018-12-07 19:07:39 and maintained it for long time 2018-12-07 19:07:53 before i got interested in docker 2018-12-07 19:08:02 but 'official repository' seems a bit strange? 2018-12-07 19:08:05 so they built the official docker images 2018-12-07 19:08:12 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 it just requires docker to recognize it 2018-12-07 19:08:29 fair enough, i don't really use docker that much anyway 2018-12-07 19:08:33 but they also have my blessing for it 2018-12-07 19:08:39 so i have git push access to the repo 2018-12-07 19:08:45 it was more or less just morbid curiosity 2018-12-07 19:08:50 and have been doing the work lately 2018-12-07 19:09:05 but we should move it to alpinelinux org 2018-12-07 19:09:26 we should build the docker images as a part of the release process 2018-12-07 19:09:39 considering that's what most alpine users use alpine for, yeah, i'd say so 2018-12-07 19:09:40 eg a job for releng "team" to figure out 2018-12-07 19:09:49 i can imagine the majority of the alpine user base use it in docker 2018-12-07 19:09:53 yes 2018-12-07 19:10:27 ok, its weekend 2018-12-07 19:10:37 oh well, at least alpine isn't "owned" by docker 2018-12-07 19:10:44 lol, have a good one 2018-12-07 19:10:58 i will likely be away most of next week 2018-12-07 19:11:15 will attend the reproducible builds in paris 2018-12-07 19:11:29 enjoy :) 2018-12-07 19:11:31 reproducible builds summit 2018-12-07 19:11:37 merci 2018-12-07 19:12:11 i'm not sure we have fully deterministic compilation 2018-12-07 19:12:16 do we? 2018-12-07 19:12:46 we dont 2018-12-07 19:12:52 not yet 2018-12-07 19:13:13 which is why i though it would be interesting to attend the summit 2018-12-07 19:13:48 have a nice weekend everyone 2018-12-07 19:13:53 considering how much control of its own ecosystem alpine lacks, it's gonna be a bumpy ride 2018-12-07 19:15:14 danieli: ncopa: started build crystal under docker, thank you for help 2018-12-07 19:17:41 danieli: could be more cpus assigned to docker to have abuild with -j X (X > 1) 2018-12-07 19:17:50 it's just a container 2018-12-07 19:17:52 not a VM 2018-12-07 19:19:25 so, it is enough to set 'export JOBS=4' in /etc/abuild.conf 2018-12-07 19:19:27 ? 2018-12-07 19:19:35 check ncpu 2018-12-07 19:19:36 yes, unless you explicitly enabled CPU namespacing 2018-12-07 19:19:40 yup 2018-12-07 19:19:42 in docker image 2018-12-07 19:19:46 it just reflects the resources the docker host has 2018-12-07 19:21:53 changed 'export JOBS=4' but it uses just one cpu 2018-12-07 19:22:53 export JOBS=48 2018-12-07 19:22:53 export MAKEFLAGS="-j$JOBS -l$JOBS" 2018-12-07 19:24:58 will remeber, for now just want to see if crystal could be built 2018-12-07 20:58:46 Hey all, i've been refered here cause i'm trying to run deluge and getting this error 2018-12-07 20:59:21 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 Sorry for the formating 2018-12-07 21:24:31 Anyone ? 2018-12-07 21:53:35 ncopa: danieli: built sucessfully crystal lang 0.27 on edge, without libressl, made some tests, looks ok 2018-12-07 21:54:04 need to fix one of the patches 2018-12-08 00:39:29 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 clandmeter: Could you take a look at why unit for armhf isn't building please? :) 2018-12-08 03:27:34 mpmc: you sent that message at 2 am, better luck next time 2018-12-08 03:28:16 anyway, edge/armhf/community/unit seems to have built fine 2018-12-08 03:28:18 http://build.alpinelinux.org/buildlogs/build-edge-armhf/community/unit/unit-1.6-r0.log 2018-12-08 09:42:06 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 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 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 it really just came off the wrong way, I didn't think the sentence through 2018-12-08 09:47:06 No harm done :) 2018-12-08 09:48:56 looks like the last time it was built was uh 2018-12-08 09:48:59 Nov 23rd 2018-12-08 09:49:52 and the last commit to it was Nov 17th 2018-12-08 10:38:38 mpmc, i did try to fix it at 2:00 ;-) 2018-12-08 10:38:48 Not sure i did 2018-12-08 11:03:50 clandmeter: Well as danieli said it's there now, so ty :) 2018-12-08 11:04:32 it should've been there already, it hasn't been rebuilt for a while 2018-12-08 11:05:31 I don't think it was 2018-12-08 11:05:36 how come? 2018-12-08 11:05:50 seems odd if it's been there for a few weeks already 2018-12-08 11:05:58 i mean, if it was built a few weeks ago 2018-12-08 11:05:58 All pkgs need to be build before sync 2018-12-08 11:06:32 I had to unblock the builder 2018-12-08 11:06:52 It also took a long time to upload 2018-12-08 11:07:03 aaah, so it doesn't sync unless world is built? 2018-12-08 11:10:48 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 It got pushed with some other changes i think of which a later broke the builder. 2018-12-08 11:11:07 here I am brebs 2018-12-08 11:13:03 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 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 ok 2018-12-08 12:12:39 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 Myhro: thanks, but I installed edge under chroot and build crystal already 2018-12-08 12:27:53 btw, is jirutka active on any irc AL channel or mailing list 2018-12-08 12:36:38 Oh, OK. I undestood you did that through Docker. 2018-12-08 12:49:18 mps: as far as I've understood, he now only maintains packages for personal use 2018-12-08 12:54:02 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 I have long-running docker containers for building locally, I just treat them as if they were VMs 2018-12-08 12:55:05 from a user perspective, they appear *largely* the same way anyway 2018-12-08 12:55:07 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 mps: sure, but my impression is that you would like to get used to it. No problem. 2018-12-08 12:55:32 mps: aha, well, you can probably find his email pretty easily 2018-12-08 12:56:55 danieli: yes, until you need to test a daemon, then its no use. :-( 2018-12-08 12:57:18 good point, that can be painful 2018-12-08 12:57:19 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 consider lxc in that case 2018-12-08 12:57:44 danieli: I use lxc 2018-12-08 12:58:02 have one debian running all the time 2018-12-08 12:59:28 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 if it's related to a change he just made to aports, i cannot imagine he minds 2018-12-08 13:00:55 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 i do agree there, unless there's no other choice 2018-12-08 13:01:09 s/tpld/told/ 2018-12-08 13:01:19 abdc 2018-12-08 13:01:21 s/dc/cd/ 2018-12-08 13:01:31 alpine-meetbot, where art thou 2018-12-08 13:02:02 is that a irc channel 2018-12-08 13:05:02 it's a bot 2018-12-08 13:05:30 looks like it is bot but wasn't sure. thanks 2018-12-08 14:24:00 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 you are talking about jirutka? 2018-12-08 14:31:29 <_ikke_> alpine-meetbot 2018-12-08 14:31:41 ah, so. 2018-12-08 14:37:52 <_ikke_> .uptime 2018-12-08 14:37:52 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 i didn't realize #alpine-meetings was a channel 2018-12-08 16:04:19 Shiz, looks you patch for rust no longer applicable https://github.com/alpinelinux/aports/pull/5781 2018-12-08 16:09:44 wip https://sr.ht/J5by.png 2018-12-08 16:15:38 danieli, it was in one of my emails 2018-12-08 16:16:09 ddevault, nice! 2018-12-08 16:16:19 (running on real RISC-V hardware, not emulated) 2018-12-08 16:16:40 ddevault: nice! Can I have one? :D 2018-12-08 16:16:51 if you have a grand to spend on it, sure 2018-12-08 16:17:03 https://www.crowdsupply.com/sifive/hifive-unleashed 2018-12-08 16:17:08 :( yeah I saw that one 2018-12-08 16:17:17 I want it but I do *not* have a grant to spend on one ^^;; 2018-12-08 16:17:24 the bootstrapping process for a new Alpine port is super smooth 2018-12-08 16:17:50 I'm about 10 hours in 2018-12-08 16:22:07 ddevault: nice! I wanted to do that but I couldn't get a hold of hardware very easily 2018-12-08 16:22:28 once I have this working I'm going to make it available to the generic public for CI 2018-12-08 16:22:38 and use that to automate porting the most of Alpine 2018-12-08 16:22:42 i have some emails to acquaintances to get some mips hardware 2018-12-08 16:22:45 mips and mips64 2018-12-08 16:22:48 so if you want to run some code on it just keep in touch :) 2018-12-08 16:23:12 adding it to your build site? 2018-12-08 16:23:14 hifive offered to send me more of these if the demand is high 2018-12-08 16:23:17 yeah 2018-12-08 16:23:19 sifive* 2018-12-08 16:23:32 god damn, I want a couple 2018-12-08 16:23:55 it'd be really nice to set up a small riscv build farm and get world built 2018-12-08 16:24:10 I'm going to gut one of my 1Us and convert it into a RISC-V farm 2018-12-08 16:24:25 the hard part is my build system is designed for KVM which is not supported on riscv yet 2018-12-08 16:24:45 what language did you write the backend for it in? I haven't really looked into the seams 2018-12-08 16:24:50 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 python and Go 2018-12-08 16:25:04 neat 2018-12-08 16:25:11 https://git.sr.ht/~sircmpwn/builds.sr.ht 2018-12-08 16:25:57 god damn, it'd be nice to get a builder set up on riscv and get world built 2018-12-08 16:26:16 well, that's the plan 2018-12-08 18:01:03 so I've run into a couple of weird issues 2018-12-08 18:01:22 just in case they seem familiar to anyone 2018-12-08 18:02:31 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 ruled out filesystem driver issues, can reproduce from tmpfs and ext4 2018-12-08 18:03:00 glibc busybox on buildroot can ls just fine outside of the chroot 2018-12-08 18:03:29 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 actually I get the same behavior if libz.so.1 is a regular file 2018-12-08 18:26:24 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 hi folks - would this be the right forum for abuild internals-related questions? 2018-12-08 18:38:30 I suppose, yeah 2018-12-08 18:42:03 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 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 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 hah, neat 2018-12-08 18:44:53 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 it's pretty much between brew and macports isn't it? 2018-12-08 18:45:57 And the idea is to make it even faster 2018-12-08 18:46:00 @_ikke_ Amen 2018-12-08 18:46:05 shitty meme: sanic.exe 2018-12-08 18:46:46 @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 is ruby fast yet 2018-12-08 18:47:57 <_ikke_> they are working on it 2018-12-08 18:48:02 hah, yeah, it's just a meme 2018-12-08 18:48:22 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 yeah, that's a pet peeve of mine, some tools are ridiculously slow 2018-12-08 18:49:16 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 @_ikke_ Yes, pet peeve of mine as well 2018-12-08 19:35:50 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 porting Alpine to riscv64 2018-12-08 19:36:52 <_ikke_> s/5dd/ddevault/ 2018-12-08 19:36:52 _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 https://git.sr.ht/~sircmpwn/abuild/commit/4a9838b9976919453bd530bbd06635fcc89976a9 2018-12-08 19:37:44 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 the apk-tools patch is similar 2018-12-08 19:39:05 I'll be putting up a repo once I complete the bootstrapping process 2018-12-08 19:39:19 which should be pretty soon, once I figure out the libc issues 2018-12-08 19:39:31 @ddevault is sr.ht your creation? 2018-12-08 19:39:34 yes 2018-12-08 19:39:39 @ddevault this looks awesome 2018-12-08 19:39:42 thank you! 2018-12-08 20:55:56 fixed the main weird issues :D 2018-12-08 21:51:03 ACTION coughs 2018-12-08 21:51:06 pr #5607 2018-12-08 21:51:07 :D 2018-12-08 21:51:48 uh, 5706 2018-12-08 21:52:55 #5706 2018-12-08 21:53:01 oh right, PR, not bug, silly me 2018-12-08 21:53:13 aports tooo 2018-12-08 21:53:25 haven't woken up yet 2018-12-08 21:53:37 https://github.com/alpinelinux/aports/pull/5706 [?] 2018-12-08 21:53:43 ye 2018-12-08 21:54:06 would be handy for some people considering how popular docker is in that community 2018-12-08 21:54:14 ya 2018-12-08 21:54:28 I'm not using docker, but I use it standalone with consul 2018-12-08 21:54:36 it's late on a saturday evening, so you should probably repeat it tomorrow roughly during daytime 2018-12-08 21:54:42 or monday, even 2018-12-08 21:54:46 ye 2018-12-08 21:55:39 still haven't got cockroach fixed, but making progress.. 2018-12-09 01:20:08 hm 2018-12-09 01:20:23 should maintainer be me? or do I have to get someone with commit access to volunteer? 2018-12-09 01:24:00 maintainer should be you, as far as I'm aware 2018-12-09 01:24:20 mmk 2018-12-09 01:24:49 it should 2018-12-09 22:15:35 hm 2018-12-10 09:41:51 hmph, litespeed package doesn't work ootb :( 2018-12-10 09:46:14 jwh: what's broken? 2018-12-10 09:46:39 php, cgi examples 2018-12-10 09:46:51 even though it *looks* like at least php should work 2018-12-10 09:47:04 but its just dumping phpinfo.php out 2018-12-10 09:47:34 theres also: 2018-12-10 09:47:35 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 emplates/rails.conf0" -mUpdate "/var/lib/litespeed/conf/templates/rails.conf0" >/dev/null 2>&1 2018-12-10 09:47:42 not sure how relevant that is 2018-12-10 09:47:57 like if thats a rails command or something 2018-12-10 09:48:01 hm, I'll test it out soon enough 2018-12-10 09:48:32 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 I've got next response from 'abuild -r': ERROR: APKINDEX.tar.gz: UNTRUSTED signature 2018-12-10 12:39:58 >>> ERROR: crystal: Failed to create index 2018-12-10 12:40:30 why, because I have set abuild correctly 2018-12-10 12:48:19 mps, it means abuild wasnt able to sign previously, or it cannot find the correct key now. 2018-12-10 12:50:05 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 when build packages on the host I don't had that problem. 2018-12-10 13:08:12 nmeum, did you mention me recently about something? 2018-12-10 13:10:05 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 ah ok 2018-12-10 13:11:11 i never noticed as i never use https on tpaste :) 2018-12-10 13:12:38 clandmeter: forgot to put me as packager in /etc/abuild.conf on edge lxc. problem solved. 2018-12-10 13:43:42 xen in edge/main is still compiled against libressl 2018-12-10 13:47:01 is there option in abuild to make build log, or use 'tee' 2018-12-10 13:55:39 mps, i dont think so 2018-12-10 13:56:46 ok, then the 'tee' will help. thanks 2018-12-10 13:58:57 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 danieli: theres a few things up with the pckage 2018-12-10 14:13:48 package* 2018-12-10 15:18:46 ah there's a bug open.. https://github.com/alpinelinux/aports/pull/5629 2018-12-10 15:19:58 this is a blocker for libvirt upgrade.. 2018-12-10 16:33:19 i looked a bit on it today 2018-12-10 16:33:29 apparently there are more fixes needed for gcc8 2018-12-10 16:33:45 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 oh there is a proposal for a fix on the PR 2018-12-10 16:38:00 danieli: https://github.com/alpinelinux/aports/pull/5811 2018-12-10 16:38:06 just a quick look.... 2018-12-10 16:38:38 dunno what happened to the second bit 2018-12-10 16:38:55 theres also something going wrong with the chown 2018-12-10 16:42:59 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 doesn't* 2018-12-10 19:46:14 ncopa: i'm actually not sure what the right fix is here :) 2018-12-10 20:07:03 ncopa: can't be solved script side, should /etc/hostname be removed from alpine-baselayout? 2018-12-10 20:52:01 geosmin: lots of stuff in -baselayout / -conf are outdated 2018-12-10 20:52:08 I keep coming accross them as I write our installation docs 2018-12-10 20:52:22 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 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 _ikke_: just moment to put it on tpaste 2018-12-10 20:59:51 _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 yes, but removed libressl patches and added some which is needed to pass 'make spec' 2018-12-10 21:15:22 and removed paxmark patch, I think it is not needed in edge 2018-12-10 21:16:26 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 yes, right 2018-12-10 21:19:44 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 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 SpaceToast: is my assumption wrong that the fix here would be to remove /etc/hostname from -baselayout? 2018-12-10 21:22:47 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 geosmin: I don't recall specifics and I'm at home right now :) 2018-12-10 21:23:30 https://crystal-lang.org/ 2018-12-10 21:23:33 _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 ok, sorry then 2018-12-10 21:24:13 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 _ikke_: what you think, is it ok to post it alpine-aports? 2018-12-10 21:37:30 to alpine-aports 2018-12-10 21:37:34 <_ikke_> yes 2018-12-10 21:38:09 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 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 _ikke_: thank you for the help 2018-12-10 21:40:10 <_ikke_> np 2018-12-10 23:02:42 Hey, i've went on #alpine linux and they told me to come here to fix my issue 2018-12-10 23:02:54 I'm trying to start Deluged daemon and getting this error 2018-12-10 23:03:05 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 Traceback (most recent call last): 2018-12-10 23:03:18 File "/usr/lib/python2.7/site-packages/deluge/main.py", line 240, in start_daemon 2018-12-10 23:03:18 from deluge.core.daemon import Daemon 2018-12-10 23:03:18 File "/usr/lib/python2.7/site-packages/deluge/core/daemon.py", line 47, in 2018-12-10 23:03:18 from deluge.core.rpcserver import RPCServer, export 2018-12-10 23:03:19 File "/usr/lib/python2.7/site-packages/deluge/core/rpcserver.py", line 47, in 2018-12-10 23:03:21 from twisted.internet import ssl, reactor, defer 2018-12-10 23:03:23 File "/usr/lib/python2.7/site-packages/twisted/internet/ssl.py", line 59, in 2018-12-10 23:03:25 from OpenSSL import SSL 2018-12-10 23:03:27 File "/usr/lib/python2.7/site-packages/OpenSSL/__init__.py", line 8, in 2018-12-10 23:03:29 from OpenSSL import crypto, SSL 2018-12-10 23:03:31 File "/usr/lib/python2.7/site-packages/OpenSSL/crypto.py", line 16, in 2018-12-10 23:03:33 from OpenSSL._util import ( 2018-12-10 23:03:35 File "/usr/lib/python2.7/site-packages/OpenSSL/_util.py", line 6, in 2018-12-10 23:03:39 from cryptography.hazmat.bindings.openssl.binding import Binding 2018-12-10 23:03:41 File "/usr/lib/python2.7/site-packages/cryptography/hazmat/bindings/openssl/binding.py", line 14, in 2018-12-10 23:03:44 from cryptography.hazmat.bindings._openssl import ffi, lib 2018-12-10 23:03:46 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 ^C 2018-12-10 23:03:51 Any clue where I should look for ? 2018-12-10 23:47:17 anyone ? 2018-12-11 07:49:33 KH405_TV: please don't paste huge text walls in IRC... 2018-12-11 07:49:40 it posts one message for each line 2018-12-11 09:11:44 ncopa: ouch, why is so much of the alpine code unlicensed? 2018-12-11 09:12:15 code without a license is copyrighted and is by default all rights reserved 2018-12-11 09:13:07 also, adding a license does not apply retroactively 2018-12-11 09:13:42 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 it says "GPL-2" 2018-12-11 09:26:02 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 abuild-fetch.c is MIT 2018-12-11 09:26:33 abuild-gzsplit.c has none 2018-12-11 09:27:33 apkbuild-cpan.in has none 2018-12-11 09:27:48 apkbuild-gem-resolver.in is copyrighted to kunkku 2018-12-11 09:27:58 in 2014-2016 anyway 2018-12-11 09:28:05 why is this such a huge clusterf*ck? 2018-12-11 09:28:27 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 lots of different licenses on the files that are licensed, some unlicensed, some copyrighted to specific people 2018-12-11 09:31:50 no LICENSE/COPYING file 2018-12-11 09:32:17 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 it does not apply retroactively 2018-12-11 10:23:09 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 (somethign similar happened with some code in the OCaml community recently i think) 2018-12-11 11:08:22 well, yes, but it does not apply retroactively 2018-12-11 11:15:22 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 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 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 let me find the link ... 2018-12-11 11:17:30 https://github.com/ocaml/opam-repository/issues/955 2018-12-11 11:19:06 (sorry, it looks like when i said "grant of copyright" above, i meant "license under CC0") 2018-12-11 11:56:01 ncopa: I posted new APKBUILD for crystal to alpine-aports 2018-12-11 12:03:07 he's away most of this week 2018-12-11 12:04:12 aha, ok. tab complete shows he is here 2018-12-11 12:06:02 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 he's here but absent 2018-12-11 13:23:41 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 (which was explicitly stated by one contributor with threats of legal action) 2018-12-11 13:24:29 <- not a lawyer either tho 2018-12-11 15:42:15 yangxuan, we use https://release-monitoring.org/ for pkgs.a.o 2018-12-11 15:42:46 but there are other sites that track pkg versions cross distro 2018-12-11 15:49:52 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 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 https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.19-4.20-BLK-MQ-Fix 2018-12-11 15:54:45 and a lot longer: https://bugzilla.kernel.org/show_bug.cgi?id=201685 2018-12-11 15:55:12 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ffe81d45322cc3cb140f0db080a4727ea284661e 2018-12-11 15:57:15 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 _ikke_: right, but alpine should build at least 4.19.8 and not 4.19.6 2018-12-11 16:16:59 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 TBB: which contributor, if I may ask? 2018-12-11 16:26:50 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 erlang 21.2 is out 2018-12-11 18:06:53 hi there 2018-12-11 18:07:10 anyone here familiar with building apk packages? 2018-12-11 18:07:43 <_ikke_> gdanko: reasonably familiar 2018-12-11 18:08:56 me too 2018-12-11 18:09:23 okay. I am building an "fpm" style utility in Go 2018-12-11 18:09:36 I have a pkginfo with some "depend" lines 2018-12-11 18:09:57 pkginfo...? 2018-12-11 18:10:00 when I install the package and I do "apk -a info " the depends are duplicated 2018-12-11 18:10:03 this is alpine linux we're talking about, right? 2018-12-11 18:10:05 .PKGINFO file 2018-12-11 18:10:07 yes 2018-12-11 18:10:08 aha 2018-12-11 18:10:10 <_ikke_> danieli: metadata in the package 2018-12-11 18:10:24 yeah, got it when they said .PKGINFO 2018-12-11 18:10:36 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 let me put on pastebin :) 2018-12-11 18:10:49 I am not using apkbuild as it is in golang. 2018-12-11 18:11:05 I am constructing the control.tar and removing end of tar headers 2018-12-11 18:11:12 aha 2018-12-11 18:11:14 then constructing data.tar and hashing it 2018-12-11 18:11:24 combining the two 2018-12-11 18:11:33 and I can install the package and all 2018-12-11 18:11:39 but info is strange 2018-12-11 18:11:41 one sec 2018-12-11 18:12:04 https://pastebin.com/xbD0vHxk 2018-12-11 18:13:12 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 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 In the first link, the depends are duplicated. 2018-12-11 18:14:41 L10-22 2018-12-11 18:15:13 L24-26, provides are duplicated 2018-12-11 18:15:40 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 but 2018-12-11 18:16:24 "I am not using apkbuild as it is in golang." 2018-12-11 18:16:29 this is in Go, so that it can be used on any unix like OS 2018-12-11 18:16:39 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 1) What if I want to use a non Alpine system to build the package? 2018-12-11 18:17:14 you'll have to build against musl either way 2018-12-11 18:17:19 2) Do not like executing system calls from my OS 2018-12-11 18:17:21 why would you build an apk-specific package outside of an apk ecosystem? 2018-12-11 18:17:27 Automation 2018-12-11 18:17:36 no but again 2018-12-11 18:17:40 apk packages are only relevant 2018-12-11 18:17:43 in apk ecosystems 2018-12-11 18:17:54 right 2018-12-11 18:17:56 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 _ikke_: sure, but we're talking about avoiding APKBUILD, not avoiding alpine specifically 2018-12-11 18:18:22 I understand what you are saying. 2018-12-11 18:18:37 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 when you build deb.. 2018-12-11 18:18:49 <_ikke_> SpaceToast: fpm can build rpms 2018-12-11 18:18:55 There is an rpmbuild port for most platforms 2018-12-11 18:19:04 that I have used 2018-12-11 18:19:12 yes, and nothing is stopping you from building abuild on non-alpine systems 2018-12-11 18:19:21 but I cannot find an apkbuild for darwin or redhat 2018-12-11 18:19:30 you can build it yourself :) 2018-12-11 18:19:35 I'm not aware of any extranious dependencies 2018-12-11 18:19:37 ok let me check that 2018-12-11 18:19:43 where is the source? 2018-12-11 18:19:49 sorry, I am new to Alpine. 2018-12-11 18:19:55 https://git.alpinelinux.org/cgit/abuild/ 2018-12-11 18:19:55 This was put in my lap 2 days ago 2018-12-11 18:19:58 https://git.alpinelinux.org/cgit/abuild/ 2018-12-11 18:20:08 or https://github.com/alpinelinux/abuild 2018-12-11 18:20:44 checking homebrew first 2018-12-11 18:21:00 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 ^ 2018-12-11 18:22:15 i don't know of any non-alpine [derivatives] using apk 2018-12-11 18:22:28 if you're targeting alpine, you'll have to build against musl libc either way 2018-12-11 18:22:44 the idea is this 2018-12-11 18:22:51 and software with musl/alpine-specific patches 2018-12-11 18:23:24 I have a repo in github with specifications about a package (arch, version, release, etc) in yaml files 2018-12-11 18:24:04 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 I have build scripts that i can specify just the version and release of say nginx 2018-12-11 18:24:42 yes! 2018-12-11 18:25:20 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 this script compiles with my config settings, sets permissions, and uploads 2018-12-11 18:25:55 it then creates a sha file 2018-12-11 18:26:08 yep I have an rpm build image and alpine build image 2018-12-11 18:26:24 these artifacts are uploaded to a repository 2018-12-11 18:26:36 so... you don't even need to port abuild? 2018-12-11 18:26:41 your approach seems confusing to me 2018-12-11 18:27:16 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 builds the package and publishes to our internal repo 2018-12-11 18:27:38 yum/deb/apk 2018-12-11 18:27:44 watch 2018-12-11 18:31:19 https://pastebin.com/QMJHcbMw 2018-12-11 18:32:06 <_ikke_> So you are not building anything? 2018-12-11 18:32:27 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 two processes at the moment 2018-12-11 18:33:01 <_ikke_> is there a reason for that? 2018-12-11 18:33:17 for what? 2018-12-11 18:33:27 <_ikke_> seperate build + package step? 2018-12-11 18:33:33 time 2018-12-11 18:33:40 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 It will be consolidated 2018-12-11 18:33:49 same here 2018-12-11 18:34:28 rpm was the first supported format but nfpm was pretty bad IMO 2018-12-11 18:34:37 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 yum remove left stuff scattered all over. symlinks were not processed properly. 2018-12-11 18:35:00 yeah same here 2018-12-11 18:35:25 how do you use oracle java with alpine? I saw a glibc package. Is it reliable? 2018-12-11 18:35:37 over here, the world revolves around Java unfortunately. 2018-12-11 18:36:33 we have client software written in Java, but fortunately we can avoid Oracle's packaging of it 2018-12-11 18:37:16 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 Because of the high profile work we are stuck with oracle. :( 2018-12-11 18:38:55 understandable... can't always get to choose 2018-12-11 18:40:43 right 2018-12-11 18:41:59 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@SDGL141bb265b abuild]$ ./abuildreadlink: illegal option -- fusage: readlink [-n] [file ...] 2018-12-11 18:46:48 close 2018-12-11 18:53:21 okay success 2018-12-11 18:53:39 let me try to build a package now 2018-12-11 18:54:03 if this is the case I will build a homebrew package for abuild and an abuild rpm 2018-12-11 18:54:10 then I can do it in a more sane manner 2018-12-11 18:55:10 can I use pre-compiled binaries in an apkbuild file? 2018-12-11 18:55:18 <_ikke_> sure 2018-12-11 18:55:20 i.e. unpack my tarball 2018-12-11 18:55:22 ok looking 2018-12-11 18:55:26 this is going to be better :) 2018-12-11 18:55:49 mac's readlink sucks 2018-12-11 20:51:39 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 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 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 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 so... looks like it does just that 2018-12-11 22:08:06 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 SpaceToast: thanks! That made me rethink and was very helpful :) 2018-12-11 22:08:54 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 it'd result in a really big APKBUILD though 2018-12-11 22:09:11 ¯\_(ツ)_/¯ 2018-12-11 22:09:22 (and is obviously not the way of doing things, as is in-tree) 2018-12-11 22:10:55 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 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 maybe this is just a lot easier than I expected! 2018-12-11 23:51:30 update on the riscv64 port 2018-12-11 23:51:42 bootstrapping is pretty much done 2018-12-11 23:51:56 I'm fixing some bugs with the musl port before I do anything else 2018-12-11 23:52:27 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 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 a couple weekends of work and I should be able to have a buildbot as well 2018-12-11 23:53:38 it's a shame upstream alpine has no riscv builders 2018-12-11 23:54:08 well, I hope that the port will become official 2018-12-11 23:54:14 and you're welcome to continue using my builder for as long as you like 2018-12-11 23:54:33 I already use builds.sr.ht to maintain my own alpine repo for x86_64 2018-12-11 23:55:16 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 I hope to use it to encourage RISC-V ports for many linux distros 2018-12-11 23:55:39 sifive* 2018-12-11 23:55:55 it's a bit complicated with signing keys, our own build system, and all that 2018-12-11 23:56:03 the port itself being upstreamed would be wonderful though 2018-12-11 23:56:47 well 2018-12-11 23:57:10 I'll be putting together some nice automation and I hope you'll consider it 2018-12-11 23:57:23 easier said than done, but we'll see, it's not up to me at all 2018-12-11 23:57:46 trusting a third party with signing keys is understandably a hard decision 2018-12-11 23:58:05 I've volunteered to be a first party before, offer still stands 2018-12-11 23:58:11 I care a lot about alpine and have invested a lot into it 2018-12-11 23:58:23 ncopa should be back after this week :) 2018-12-11 23:58:45 guess I'll need something to show by then :) 2018-12-11 23:59:56 hah, no worries 2018-12-12 00:00:05 getting world to build is the ultimate goal 2018-12-12 00:05:45 ddevault: your CI is open sauced, right? :) 2018-12-12 00:05:50 yes 2018-12-12 00:05:54 https://git.sr.ht/~sircmpwn/builds.sr.ht 2018-12-12 00:06:13 ah it's python based! 2018-12-12 00:06:30 I'll take a look later, might be interesting in general :D 2018-12-12 00:07:03 postmarketOS is using it now to automate their package maintenance (based on alpine) 2018-12-12 00:07:17 they told me how to stylize the name once, but I can't remember 2018-12-12 00:07:56 based on their site, you seem to have gotten it right 2018-12-12 01:08:11 Anybody has any idea for my deluge issue ? 2018-12-12 01:11:35 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 Damn, alright :S 2018-12-12 01:21:37 Eu daytime is hard for me tough 2018-12-12 01:22:25 similarly, current time is pretty hard for EU devs ;) 2018-12-12 01:22:53 probably just a problem around the switch from libressl to openssl 2018-12-12 01:23:11 that's what I said a while ago, I even recall that specific hazmat file being involved 2018-12-12 01:23:17 I don't recall the resolution to that though 2018-12-12 01:23:29 probably needs recompiling 2018-12-12 01:23:44 the underlying python c library wrapper 2018-12-12 01:24:07 btw hooray for lifting the curse of silence for non-registered users \o/ 2018-12-12 01:29:14 lol ^^ 2018-12-12 01:29:34 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 If someone wanna help out, it'd be very appreciated 2018-12-12 01:31:39 The source of the problem has been identified, but I can't fix it :S 2018-12-12 01:35:47 did you rebuild the py-cryptography package? 2018-12-12 01:36:06 is it at the latest version? 2018-12-12 01:36:10 I sent a patch up http://lists.alpinelinux.org/alpine-aports/5863.html 2018-12-12 01:37:03 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 ah, you might also want to try this patch iiuc 2018-12-12 01:37:17 so perhaps including psk is the right move 2018-12-12 01:37:44 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 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 depends on how you installed it 2018-12-12 01:39:59 Everything should be updated on the latest edge branch right now 2018-12-12 01:42:07 It is updated 2018-12-12 02:38:25 Any other idea? 2018-12-12 04:29:20 I'm still stuck there :S 2018-12-12 07:00:57 installing iptables gives a "BAD signature" error on Alpine edge x86_64 2018-12-12 07:12:01 this doesn't seem to be on every mirror though, nl.alpinelinux.org works 2018-12-12 07:12:42 use dl-cdn? 2018-12-12 07:57:38 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 yes it was and it should be fixed 2018-12-12 08:12:01 a trick to solve cdn cache is using curl -X PURGE $url 2018-12-12 08:12:05 fcolista, ^ 2018-12-12 08:12:51 <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 45min ago.. 2018-12-12 08:13:07 forgot to do that yesterday, sorry /0\ 2018-12-12 08:13:33 fcolista, you can also purge the cache. 2018-12-12 08:13:51 or just bump pkgrel 2018-12-12 10:31:05 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 andypost, if you want travis to be successful (i guess you would) you should use the same PR 2018-12-12 10:40:15 it will also make sure build will succeed on builders 2018-12-12 10:40:37 if PR's are not applied in correct order it would fail. 2018-12-12 10:41:46 ddevault, you build complete x86_64 world or only the packages you need? 2018-12-12 10:41:57 clandmeter, I mean travis can't detect that ABI changed and tells "ok" 2018-12-12 10:42:20 so it is easy to miss ABI change 2018-12-12 10:42:45 ah ok now i get it. 2018-12-12 10:43:12 i was thinking in reverse. 2018-12-12 10:43:49 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 clandmeter, so that means only manual way to detect abi changes for now 2018-12-12 10:46:37 yes, the dev that pushes it should always check if libs have changed. 2018-12-12 10:59:16 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 _ikke_, did you find time to check? 2018-12-12 11:00:54 <_ikke_> Not yet :( 2018-12-12 11:01:25 np 2018-12-12 11:01:28 ill give a quick check 2018-12-12 11:02:37 hmm 2018-12-12 11:02:43 proxy didnt register in dns 2018-12-12 11:36:09 nmeum, how about now? 2018-12-12 11:36:41 <_ikke_> validates here 2018-12-12 11:41:25 clandmeter: yep, works now. thanks! 2018-12-12 12:43:16 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 ddevault, right 2018-12-12 12:43:46 you are not using our build tools i guess 2018-12-12 12:43:58 no, but my setup isn't perfect anyway 2018-12-12 12:44:09 I intend to transition to some happy medium between my tools and alpine's upstream tools 2018-12-12 12:49:08 ddevault, sr.ht is completely running on alpine? 2018-12-12 12:49:19 not completely 2018-12-12 12:49:24 but I'm working on migrating everything 2018-12-12 12:49:34 impressive! 2018-12-12 12:49:55 builds.sr.ht master runs on arch, but the slaves are running on alpine 2018-12-12 12:50:07 dispatch.sr.ht, man.sr.ht, and lists.sr.ht run on arch 2018-12-12 12:50:10 ns1 & ns2 run on debian 2018-12-12 12:50:12 the rest is alpine 2018-12-12 12:50:28 ive been looking over it a bit,, didnt really device into code yet. 2018-12-12 12:50:38 dive* 2018-12-12 12:51:25 what do you think? 2018-12-12 12:52:49 well i like the simplicity (as long it doesnt limit user experience) 2018-12-12 12:53:42 seems like a reasonable constraint 2018-12-12 12:53:57 right now it does limit user experience 2018-12-12 12:54:26 yes, thats my first experiance. but im not really using it so i cant realy judge. 2018-12-12 13:01:22 ddevault, the concept of a pull request is non existent? 2018-12-12 13:01:38 correct, this is the main way in which UX is limited 2018-12-12 13:01:49 we use git send-email and lists.sr.ht to fill that niche 2018-12-12 13:02:01 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 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 understand 2018-12-12 13:03:20 i guess this can be self hosted? 2018-12-12 13:03:59 ddevault: yesterday read your text about workflow using send-email. nice :) 2018-12-12 13:04:17 clandmeter: it can be, yeah: https://man.sr.ht/installation.md 2018-12-12 13:04:28 clandmeter: you can just slap my alpine repo in /etc/apk/repositories and apk add git.sr.ht 2018-12-12 13:04:36 mps: thanks! 2018-12-12 13:04:58 heh nice :) 2018-12-12 13:05:51 what is your experience using py for web based solutions? 2018-12-12 13:06:17 would be nice if it could be somehow 'integrated' to Alpine, IMHO 2018-12-12 13:06:27 i remember pagure never really felt snappy. 2018-12-12 13:06:33 does sr.ht feel snappy to you? 2018-12-12 13:06:46 mps: integrated how? like upstream in world? 2018-12-12 13:07:06 it does, but i guess your customer base is limited atm? 2018-12-12 13:07:22 there are 5,499 users 2018-12-12 13:07:31 python is pretty light if you know what you're doing 2018-12-12 13:07:48 didn't looked deeply in it, but superficially it is something which could be considered 2018-12-12 13:07:56 ah i didnt know you had that many already. 2018-12-12 13:08:09 mps: well, that may be possible but there are several drawbacks 2018-12-12 13:08:25 first, sr.ht is updating too fast right now for it to be practical 2018-12-12 13:08:51 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 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 sure 2018-12-12 13:10:02 we are looking into changing our build system. 2018-12-12 13:10:36 i should check sr.ht a bit more deeper. 2018-12-12 13:11:00 great, let me know if you have any questions 2018-12-12 13:11:08 I did a writeup on bugs.alpinelinux.org a while ago 2018-12-12 13:11:20 https://bugs.alpinelinux.org/issues/9134 2018-12-12 13:11:31 i will look at it just to 'learn' something interesting, at least 2018-12-12 13:11:41 and you are using alpine as a base, thats really attractive :) 2018-12-12 13:11:51 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 yes i remember you mention it a few times, but ive been really busy with other infra things. 2018-12-12 13:13:20 I get it, that wasn't a slight on you 2018-12-12 13:13:24 and ncopa is the one with more deeper knowledge of how are done on the builders 2018-12-12 13:13:51 there are only around a handful of people with access to the alpine builders too 2018-12-12 13:13:54 moin \o 2018-12-12 13:14:07 danieli, you can setup your own builder :) 2018-12-12 13:14:14 you would have lots of access all the time 2018-12-12 13:14:37 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 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 SpaceToast, that was also on my list to ask ;-) 2018-12-12 13:15:15 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 ^^ 2018-12-12 13:15:23 https://github.com/asciidoc/asciidoc-py3 p[robably not too much work 2018-12-12 13:15:27 s/[// 2018-12-12 13:15:27 danieli meant to say: https://github.com/asciidoc/asciidoc-py3 probably not too much work 2018-12-12 13:15:48 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 before I was shilling sr.ht to alpine I was shilling scdoc to alpine :) 2018-12-12 13:16:23 yeah I saw mention of it; have not tried yet 2018-12-12 13:16:30 mostly because I'm very comfortable with asciidoctor 2018-12-12 13:16:36 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 ah, that makes sense - how are you planning to set that up? 2018-12-12 13:16:57 (more like gitlab, or more like github?) 2018-12-12 13:17:10 rsync 2018-12-12 13:17:23 aha, so secrets in CI conf 2018-12-12 13:17:33 builds.sr.ht already supports secrets 2018-12-12 13:17:38 yup :) 2018-12-12 13:17:46 you add secrets on the web UI and get a UUID, which you put in your build manifest 2018-12-12 13:17:52 it only populates the actual secret for authorized builds 2018-12-12 13:18:11 ok, that sounds reasonable once pages.sr.ht is build 2018-12-12 13:18:18 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 s/build/built/ 2018-12-12 13:18:21 SpaceToast meant to say: ok, that sounds reasonable once pages.sr.ht is built 2018-12-12 13:21:56 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 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 which kind of virt does it use? 2018-12-12 13:23:52 kvm 2018-12-12 13:23:58 :) 2018-12-12 13:25:10 how would i set arch? 2018-12-12 13:25:56 arch: aarch64 2018-12-12 13:25:59 but it wouldn't work 2018-12-12 13:26:01 multiarch is a WIP 2018-12-12 13:26:36 you might be able to get the debian/stretch image to boot arm64 2018-12-12 13:27:05 i guess you mean multiarch as in different arch per job? 2018-12-12 13:29:21 aye 2018-12-12 13:29:53 I'm working on a mix of software emulation (qemu) and actual builders running different arches 2018-12-12 13:31:57 ddevault, how fast does it boot to execution? 2018-12-12 13:32:21 within a couple of seconds 2018-12-12 13:36:26 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 *image 2018-12-12 13:36:35 correct 2018-12-12 13:37:06 its just a vanilla alpine image :) 2018-12-12 13:37:14 still only few seconds :) 2018-12-12 13:37:52 yes 2018-12-12 13:37:57 bbiab 2018-12-12 13:37:59 i do miss the log/blame features 2018-12-12 13:38:10 feel free to keep sending questions, I'll see them 2018-12-12 13:38:56 you really did an amazing job, ill be sure to poke ncopa a bit :) 2018-12-12 13:40:24 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 ddevault: nitpick: i had shells error out on [ * == * ], its single '=' in posix 2018-12-12 13:54:13 thanks clandmeter, I appreciate it 2018-12-12 13:54:19 AinNero: good nitpick 2018-12-12 13:54:49 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 ACTION judges 2018-12-12 13:55:42 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 more POSIX even than dash 2018-12-12 13:56:25 dont take away my non posix goodies! :) 2018-12-12 13:56:31 i think there are enough compliant shells, i'd prefer on making scripts compliant 2018-12-12 13:56:44 tbh I disagree 2018-12-12 13:56:55 it's easier to make scripts complaint when your shell gets pissed when you aren't 2018-12-12 13:57:03 and all of the POSIX shells leave a lot to be desired imo 2018-12-12 13:57:11 none of them are really strict on POSIX compliance 2018-12-12 13:57:11 just pick the right shell then :D 2018-12-12 13:57:16 and none of them have a comfortable interactive shell 2018-12-12 13:57:21 and their code all sucks 2018-12-12 13:57:30 https://git.sr.ht/~emersion/mrsh 2018-12-12 13:57:48 comfortable interactive shell is difficult inside of posix specs 2018-12-12 13:58:16 I don't consider POSIX's specifications for the interactive shell to be important 2018-12-12 13:58:22 at some point I'm going to ask the austin group to remove them from the spec 2018-12-12 13:58:29 you are aware that im Nathan? 2018-12-12 13:58:37 s/im/was/ 2018-12-12 13:58:37 AinNero meant to say: you are aware that was Nathan? 2018-12-12 13:58:47 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 hmmm 2018-12-12 13:58:58 no, but I'm also not 100% sure who Nathan is 2018-12-12 13:59:13 oh, Nathan Cladwell? 2018-12-12 13:59:19 oh no 2018-12-12 13:59:23 but im fine with the Situation 2018-12-12 13:59:43 huh. 2018-12-12 14:01:33 having a true_posix_shell:tm: sounds interesting (if at least for development and /bin/sh) 2018-12-12 14:01:46 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 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 I use fish but I hate it 2018-12-12 14:02:05 how exactly are you interfacing with git, by the way? 2018-12-12 14:02:12 pygit2, which is based on libgit2 2018-12-12 14:02:14 implementing it, or wrapping `git` in CLI? 2018-12-12 14:02:15 ah nice 2018-12-12 14:02:38 there are some performance issues I need to sort out 2018-12-12 14:02:41 i've seen some terrible solutions, for instance gitea, which literally wraps `git` on the command line 2018-12-12 14:02:45 do you use asyncio heavily? 2018-12-12 14:02:49 not heavily 2018-12-12 14:02:52 but I do use it in some places 2018-12-12 14:03:04 there are also some performance issues with pygit2 that I need to address 2018-12-12 14:03:09 I have some erm... gripes with fish 2018-12-12 14:03:10 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 would be appreciated 2018-12-12 14:03:23 (it basically lets you inject things into otherwise running shells in a bad way) 2018-12-12 14:03:24 just put the linux kernel in a repo and use the interface 2018-12-12 14:03:32 it'll quickly become obvious what's slow (git log is the worst) 2018-12-12 14:03:44 of course.. considered lazy loading and/or pagination? 2018-12-12 14:03:53 I do both 2018-12-12 14:03:55 and caching! 2018-12-12 14:03:56 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 neat, redis or memcached? 2018-12-12 14:04:03 redis 2018-12-12 14:04:19 hm, perhaps you have a freenode channel I could join instead of polluting this channel? 2018-12-12 14:04:23 #sr.ht 2018-12-12 14:04:37 you cache each commit? 2018-12-12 14:05:02 okay, brb 2018-12-12 14:05:03 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 :) 2018-12-12 14:30:42 2 2018-12-12 14:30:46 oops 2018-12-12 14:38:58 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 gotcha 2018-12-12 16:09:02 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 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 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 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 oh yeah, true 2018-12-12 16:22:48 probs a noop by default, that one 2018-12-12 16:23:42 yup, by default it's just a : 2018-12-12 19:20:29 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 in package() :D 2018-12-12 19:20:37 not unreadable *at all* 2018-12-12 19:21:38 seems fine to me, you just have to know what all those install options do :) 2018-12-12 19:21:42 is kind of STRANGE though 2018-12-12 19:22:07 it needs a case so I can use $arch also 2018-12-12 19:22:49 ACTION shakes fist at people using x86_64 2018-12-12 19:32:58 alpine builders have super large passwd and group files 2018-12-12 19:33:07 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 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 [[sroracle]]: you're the one working on abuildd, right? 2018-12-12 19:35:53 <[[sroracle]]> yeah 2018-12-12 19:36:03 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 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 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 it feels like an ugly solution to be honest 2018-12-12 19:38:30 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 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 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 er, per-install, my bad 2018-12-12 19:41:18 s/per/pre 2018-12-12 19:41:18 danieli meant to say: er, pre-install, my bad 2018-12-12 19:42:30 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 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 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 that is true, that would be an issue 2018-12-12 19:46:55 clandmeter, fcolista, ikke: thanks for explaining and for fixing it 2018-12-12 19:47:31 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 etc 2018-12-12 19:47:43 it can vary a lot 2018-12-12 19:48:37 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 could probably do something along the lines of what gentoo does 2018-12-12 20:29:06 hm, elixir fails on armhf 2018-12-12 20:29:14 13:18:25.365 [error] Can't load module ':lists' that resides in sticky dir 2018-12-12 20:29:53 https://github.com/elixir-lang/elixir/issues/8183 seems relevant 2018-12-12 20:36:40 seems like it isn't *really* failing? that's odd 2018-12-12 23:26:11 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 it does 2018-12-12 23:30:35 edge is the development branch 2018-12-12 23:31:03 either way, you don't need all of aports just to build a few packages 2018-12-12 23:31:13 what matters is the host it's being built on 2018-12-12 23:33:15 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 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 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 ... this the common approach, or is there a more alpine linux-ish way of doing it? 2018-12-12 23:41:10 often custom mirrors, or upstreaming them 2018-12-12 23:41:42 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 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 danieli: indeed! I hadn't thought of that. Thanks. That will work very nicely 2018-12-12 23:42:32 forresten, sen jobbing på en tirsdag, av alle ting? :) 2018-12-12 23:43:26 danieli: Jepp! Dette var alt for gøy og vanskelig å legge fra seg før det funker! 2018-12-12 23:44:04 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 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 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 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 speaking of that aports openssl patch I linked yesterday 2018-12-13 01:57:44 http://lists.alpinelinux.org/alpine-aports/5863.html 2018-12-13 01:57:46 would be nice to see this land 2018-12-13 01:58:13 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 bah, is it still broken? 2018-12-13 02:15:38 yeah 2018-12-13 02:16:29 https://builds.sr.ht/~sircmpwn/job/14663#task-test-102 2018-12-13 08:00:01 ddevault, done 2018-12-13 08:00:01 clandmeter: 2018-12-12 - 16:16:56 <_ikke_> tell clandmeter "Please register #alpine-docs" 2018-12-13 08:00:21 huh? 2018-12-13 08:00:43 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 i did? 2018-12-13 08:33:38 <_ikke_> yes 2018-12-13 08:33:46 i dont think so :) 2018-12-13 08:33:58 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 channel is already regged 2018-12-13 08:34:14 <_ikke_> ah ok 2018-12-13 08:34:19 :p 2018-12-13 08:34:41 but thx for the reminder ;-) 2018-12-13 08:35:05 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 _ikke_: I'll pass that on when clandmeter is around. 2018-12-13 10:10:20 Shiz, are you still working on rust on alpine? 2018-12-13 10:15:30 ^ ping strfry 2018-12-13 10:16:53 AinNero: pong 2018-12-13 10:17:22 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 which is relevent here, i guess 2018-12-13 10:19:55 rustup is to boostrap rust? 2018-12-13 10:22:11 yeah 2018-12-13 10:22:33 mostly to install rust versions you don't get from your package manager 2018-12-13 10:22:43 like beta/nightly channels, or cross-compile targets 2018-12-13 10:22:54 i remember there was some project to make it easier to boostrap rust without rust? 2018-12-13 12:54:09 thanks clandmeter 2018-12-13 17:02:11 hm.... 2018-12-13 17:02:12 [ 325.137686] DVB: Unable to find symbol stb0899_attach() 2018-12-13 17:03:52 stb0899 40960 -1 2018-12-13 17:03:55 -1 huh 2018-12-13 17:04:45 weird, fine after reboot 2018-12-13 21:52:14 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 aah the CARCH variable helps 2018-12-13 21:55:34 it does indeed 2018-12-13 22:32:04 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 ah. found out about ifuncs 2018-12-13 23:11:32 ah, gcc6 apparently works, only gcc8 does not. 2018-12-14 00:54:13 hm, should probably revisit litespeed then 2018-12-14 00:54:17 see whats up 2018-12-14 01:12:16 hm, what am I missing.... 2018-12-14 01:13:53 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 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 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 just added -openrc to subpackages like the example I used (consul) 2018-12-14 01:36:41 it depends on the package 2018-12-14 01:36:55 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 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 ah, the default openrc() includes install_if, I don't think I noticed, ty 2018-12-14 01:45:28 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 SpaceToast: keep in mind that adélie has a wiki too, under CC-BY-SA-4.0 :) 2018-12-14 01:50:04 [[sroracle]]: I'm writing all the docs, for the entirety of alpine, atm 2018-12-14 01:50:21 https://wiki.adelielinux.org/wiki/APK_internals 2018-12-14 01:50:45 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 that's still a distance off 2018-12-14 01:50:56 no worries, just a heads up 2018-12-14 01:51:09 ^^ 2018-12-14 01:51:42 <[[sroracle]]> SpaceToast: very cool 2018-12-14 01:51:56 [[sroracle]]: if you wanna help out (or keep up) feel free to join #alpine-docs :) 2018-12-14 02:20:48 shit, i lost my complete irc logs 2018-12-14 02:21:04 is someone here who has some complete channel logs and could grep something for me? 2018-12-14 02:21:21 you could try this https://dev.alpinelinux.org/irclogs/ 2018-12-14 02:21:25 open the right date and ctrl+f 2018-12-14 02:22:09 danieli, i have no idea when i asked that question 2018-12-14 02:22:10 hehehehe 2018-12-14 02:22:22 well, shit... I'm on Alpine's The Lounge right now 2018-12-14 02:22:35 and I don't have access to the container that is dev.a.o 2018-12-14 02:24:51 hmm, i have an idea 2018-12-14 02:25:11 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 ahhh 2018-12-14 02:34:11 thanks [[sroracle]] 2018-12-14 02:34:21 so I need to figure out why its not picking the files up 2018-12-14 02:35:33 same as one that works... 2018-12-14 02:35:33 install -Dm755 "$srcdir"/$pkgname.initd \ 2018-12-14 02:35:34 "$pkgdir"/etc/init.d/$pkgname || return 1 2018-12-14 02:35:36 looks sane 2018-12-14 02:35:54 the `|| return 1` part is obsolete now afaik 2018-12-14 02:36:08 but yeah, looks sane to me 2018-12-14 02:36:11 jwh: that's in package(), right? 2018-12-14 02:36:17 yeah 2018-12-14 02:37:47 APKBUILD in question is testing/litespeed 2018-12-14 02:38:16 and, to be sure, you have $pkgname-openrc in subpackages and no openrc() defined, right? 2018-12-14 02:38:25 correct 2018-12-14 02:38:34 cartwheel:~/aports/testing/litespeed$ grep -i openrc APKBUILD 2018-12-14 02:38:35 subpackages="$pkgname-openrc $pkgname-snmp::noarch" 2018-12-14 02:38:40 very stange 2018-12-14 02:38:48 I might poke at it later, if I squeeze it in 2018-12-14 02:38:54 :D 2018-12-14 02:39:24 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 but it seemed like a quick win to fix that 2018-12-14 02:39:58 wait till you look at alpine-baselayout and alpine-conf ;) 2018-12-14 02:40:38 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 yup, yup 2018-12-14 02:45:20 even nuked packages/* just in case 2018-12-14 02:45:27 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 well theres a version bump as well, yup 2018-12-14 02:46:36 <[[sroracle]]> very odd 2018-12-14 02:47:08 does openrc() check for specific naming? 2018-12-14 02:47:13 I wonder... 2018-12-14 02:47:17 <[[sroracle]]> naming of? 2018-12-14 02:47:28 files installed to init.d 2018-12-14 02:47:51 theres no conf.d, but surely init.d is enough to trigger -openrc subpackage? 2018-12-14 02:48:31 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 huh, who knows 2018-12-14 02:50:58 because it *creates* the -openrc package, it just doesn't get installed as a dependency 2018-12-14 02:52:54 since it works for packages in the official repo I'm gonna blame something local 2018-12-14 02:54:44 do you have openrc in world? 2018-12-14 02:55:05 I'd hope so :P 2018-12-14 02:55:20 that's the main thing I can think of 2018-12-14 02:55:26 since the install_if is for openrc *and* the main package 2018-12-14 02:55:36 hm 2018-12-14 02:56:00 hang on 2018-12-14 02:56:13 I think I may look foolish very shortly 2018-12-14 02:56:47 yeah I'm just gonna go sit over in the dunce corner 2018-12-14 02:57:51 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 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 could have sworn I did... 2018-12-14 02:59:22 ah, that'd do it :) 2018-12-14 02:59:31 and hey, don't worry, happens to literally everyone (I checked ;) ) 2018-12-14 03:04:06 heh 2018-12-14 03:07:08 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 post means after/behind/subsequent to 2018-12-14 03:08:00 post-up is right 2018-12-14 03:08:21 hmm, then i dont get why is is not executing it 2018-12-14 03:08:30 +x? 2018-12-14 03:08:47 my wireguard configuration on $home_gateway uses post-up (among other things) and it runs fine 2018-12-14 03:08:50 bleh, I have no idea why litespeed doesn't work properly at all ootb 2018-12-14 03:12:03 would really help if the defaults in configure --help actually matched reality 2018-12-14 03:38:27 hm, doesn't rootbld copy resolv.conf? 2018-12-14 03:40:22 I couldn't get rootbld working at all 2018-12-14 03:40:27 I didn't try very long or hard, to be fair 2018-12-14 03:41:03 I've not really investigated but the error is typical of a missing resolv.conf in the chroot 2018-12-14 03:41:37 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 fair enough 2018-12-14 03:44:55 screw this package anyway its a disaster 2018-12-14 03:44:57 :D 2018-12-14 03:45:23 upstream sucks 2018-12-14 06:58:39 Hi all. I've one quick question. What is the state of LXC 3.0 on Alpine? 2018-12-14 07:32:34 ncopa, i'm getting on firefox: 2018-12-14 07:32:36 Sandbox: seccomp sandbox violation: pid 21344, tid 21344, syscall 16, args 36 21523 140729623829272 9259542123273814144 72 18374403900871474943. 2018-12-14 07:32:39 Sandbox: seccomp sandbox violation: pid 21344, tid 21344, syscall 16, args 36 21523 140729623829640 9259542123273814144 72 18374403900871474943. 2018-12-14 07:32:42 [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 [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 [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 [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 any ideas? 2018-12-14 07:40:35 morning fabled, do you have time to check openjdk7 on armv7? 2018-12-14 07:53:52 Hi all, one quick question. Anyone know the state of LXC 3.0 on Alpine? 2018-12-14 07:54:30 non existent yet 2018-12-14 08:37:00 im taking a look at lxc3 2018-12-14 08:39:07 Morning. fabled: i have no clue about Firefox issue 2018-12-14 08:42:31 hum. seems sandbox is doing ioctl(TIOCGWINSZ) 2018-12-14 08:42:40 could be musl or rust/firefox libs 2018-12-14 09:01:43 ok. i have an idea 2018-12-14 09:02:01 clandmeter, looked weird. maybe gcc-java issue still, need to look at it in more detail 2018-12-14 10:23:18 fabled: do you have any opinion on PSK support in openssl: https://github.com/alpinelinux/aports/pull/5829 2018-12-14 10:26:27 i have a feeling abuild is slow than previously. at the stripping binaries part. 2018-12-14 10:29:18 thats quite possible 2018-12-14 10:30:25 are you sure its the stripping part and not the step after? 2018-12-14 10:30:28 ah its not stripbin 2018-12-14 10:31:01 the msg is confiusing like this 2018-12-14 10:31:43 verbose options doesnt make it more clear 2018-12-14 10:33:55 its prepare_metafiles 2018-12-14 10:35:41 ah i already know what it is 2018-12-14 10:35:52 stupid of me, i knew this already :| 2018-12-14 10:36:16 a new aport will be slow to run git log cause there is no history for that path 2018-12-14 10:40:33 indeed 2018-12-14 10:40:51 i wonder if its better with `git rev-list` 2018-12-14 10:40:53 probably not 2018-12-14 10:40:55 we could add a check, but i dont think its worth it. 2018-12-14 10:41:50 so lxc will be split into 4 packages 2018-12-14 10:43:05 ncopa, ill guess ill move those into main directly. we will have to do some tests locally. 2018-12-14 10:46:05 so no more lxc-2? 2018-12-14 10:49:15 you want to keep two vcersions? 2018-12-14 10:51:28 no 2018-12-14 10:52:12 they split py lua and templates out of main 2018-12-14 10:52:20 and included pam 2018-12-14 10:52:44 i guess the idea is to use osi 2018-12-14 11:07:38 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 ncopa, i think libressl never had psk support. it's new openssl feature 2018-12-14 11:11:21 reminds me, our init has libressl traces 2018-12-14 11:11:44 Is anyone here clear on which ARM specific architectures are currently supported? 2018-12-14 11:13:04 armhf armv7( upcoming ) and aarch64 or is that not specific enough? 2018-12-14 11:14:30 clandmeter: I would like to know more about ARMv7 -- what's missing? 2018-12-14 11:14:43 fabled: i think libressl removed PSK support https://github.com/libressl-portable/portable/issues/450#issuecomment-437078113 2018-12-14 11:15:09 clandmeter: And what's the difference between ARMv7 and ARMHF -- Doesn't ARMv7 support ARMHF? 2018-12-14 11:15:18 lag: check the APKBUILD from the main/gcc package 2018-12-14 11:15:18 lag, we have some aports that fail to build. not sure the exact list. 2018-12-14 11:15:19 armhf is armv6 2018-12-14 11:15:24 ncopa, oh. hmm. 2018-12-14 11:15:38 lag: there is the _arch_configure= case switch for all supported arches 2018-12-14 11:15:38 yes armv6 with hard float 2018-12-14 11:15:48 ncopa: That is not correct 2018-12-14 11:16:04 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 ncopa: ARMv6 *can* have ARMHF support, but not always 2018-12-14 11:16:17 ncopa: ARMv7 always has ARMHF support 2018-12-14 11:16:26 ncopa, i think psk is optional feature of tls 1.3 2018-12-14 11:16:41 lag: the alpine arch "armhf" is armv6 with hardware float 2018-12-14 11:17:08 ncopa: I see 2018-12-14 11:17:21 ncopa: clandmeter: So what will the ARMv7 port be called? 2018-12-14 11:17:30 lag, armv7 2018-12-14 11:17:31 armv7 2018-12-14 11:17:58 if you are interested to help, we can send you a list of failed pkgs. 2018-12-14 11:17:59 Maybe armv6 & armv7 will be better, since both support ARMHF 2018-12-14 11:18:26 lag: you are right, but its too much pain to rename "armhf" to "armv6" at this point 2018-12-14 11:18:35 ncopa: Understood 2018-12-14 11:19:02 clandmeter: Not sure I have the bandwidth - but it won't hurt to look 2018-12-14 11:19:59 ncopa, i guess we still want to keep the default alpine template in lxc main pkg? 2018-12-14 11:20:07 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 clandmeter: ncopa: Not a serious suggestion -- just trying to dig into the particulars of the issue 2018-12-14 11:21:03 ARMv7 has better performance, i guess due to float and thumb features 2018-12-14 11:21:39 AinNero: So you wish to build *specifically* for ARMv7 to utilise it's extended features -- makes sense 2018-12-14 11:21:42 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 lag: https://github.com/alpinelinux/aports/blob/a29600791673c2a3ad5cdef65b129a8d8577cf0f/main/gcc/APKBUILD#L217 2018-12-14 11:22:08 AinNero: clandmeter: ncopa: Any idea on timelines? 2018-12-14 11:22:42 ASAP, but not any sooner. 2018-12-14 11:22:50 clandmeter: :D 2018-12-14 11:23:07 we are way behind on rel date 2018-12-14 11:23:11 lag: we are late already 2018-12-14 11:23:22 i think less than 2 weeks is realistic 2018-12-14 11:23:42 but i really really want it out before end of 2018 2018-12-14 11:24:04 that just gave you another 3 days ;-) 2018-12-14 11:25:05 hmm i wonder what to do with lxc. i have packages but no idea if it actually works :| 2018-12-14 11:25:28 clandmeter: from what i saw from upstream docs 2018-12-14 11:25:29 i think ill have to spin it up on some virt 2018-12-14 11:25:50 the lxc-templaces are legacy 2018-12-14 11:26:02 yes 2018-12-14 11:26:05 so i dont think we should ship the alpine template with main package anymore 2018-12-14 11:26:09 ncopa: clandmeter: AinNero: Thanks for the information -- that's good news 2018-12-14 11:26:21 lag: thanks for your patience 2018-12-14 11:26:28 ncopa: clandmeter: AinNero: BTW, who runs the Alpine Docker project? 2018-12-14 11:26:53 lag: depends on how you define "who runs" 2018-12-14 11:27:02 lag: that im present and vocal in this channel does not mean i'm someone of relevance here 2018-12-14 11:27:23 i just have opinions and some knowledge 2018-12-14 11:27:49 ncopa: Gliderlabs ? 2018-12-14 11:28:10 AinNero: That's okay -- you still deserve gratitude 2018-12-14 11:28:17 lag: Gliderlabs have sort of asked that someone else takes over maintenence 2018-12-14 11:28:27 so I guess its me who does it in practice 2018-12-14 11:28:51 ncopa: Ah, maybe you saw my 'Issue'? 2018-12-14 11:29:11 ncopa: Docker images? Because @work, im maintaining alpine base images myself, which we build from scratch 2018-12-14 11:29:23 ncopa: Although the issues do not look as though they have been triaged in quite some time 2018-12-14 11:29:36 ncopa, i think you are right 2018-12-14 11:29:47 it will also clash by name 2018-12-14 11:30:01 so its proably better to rename them to lxc-templates-legacy 2018-12-14 11:33:16 lag: fyi, I run armv7 on two boxes for about month without problem, and yes, performance is better 2018-12-14 11:33:40 ok i need to go. ill keep it in my local repo for now and test it later. 2018-12-14 11:33:44 mps: That's good news -- thank you for the information 2018-12-14 11:33:50 finally. got backtrace on FF sandbox: 2018-12-14 11:33:51 Thread 34 "Web Content" received signal SIGSEGV, Segmentation fault. 2018-12-14 11:33:52 [Switching to LWP 30250] 2018-12-14 11:33:52 0x00007ff8c8b3bc0a in ?? () from /usr/lib/xorg/modules/dri/i965_dri.so 2018-12-14 11:33:52 (gdb) where 2018-12-14 11:33:52 #0 0x00007ff8c8b3bc0a in ?? () from /usr/lib/xorg/modules/dri/i965_dri.so 2018-12-14 11:33:53 #1 0x00007ff8c8b3bfb7 in ?? () from /usr/lib/xorg/modules/dri/i965_dri.so 2018-12-14 11:33:55 #2 0x00007ff8c8b42604 in ?? () from /usr/lib/xorg/modules/dri/i965_dri.so 2018-12-14 11:33:57 had to build some packages locally but nothing serious 2018-12-14 11:33:59 #3 0x00007ff8c8b421d5 in ?? () from /usr/lib/xorg/modules/dri/i965_dri.so 2018-12-14 11:34:01 #4 0x00007ff8e45e995b in start (p=) at src/thread/pthread_create.c:147 2018-12-14 11:34:03 #5 0x00007ff8e45eb844 in __clone () at src/thread/x86_64/clone.s:21 2018-12-14 11:34:07 sounds stack usage 2018-12-14 11:34:16 fabled: Woah!! Pastebin dude! 2018-12-14 11:34:32 hey, it's still under 10 lines 2018-12-14 11:34:35 ncopa: FYI: https://github.com/gliderlabs/docker-alpine/issues/463 2018-12-14 11:34:42 fabled: I think the unofficial rule is 5 2018-12-14 11:35:02 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 ncopa: Will you be the guy who will update the Docker Official Images library file? 2018-12-14 11:35:33 as long fabled keeps fixing things he can paste whatever he wants from me ;-) 2018-12-14 11:35:49 clandmeter: :D 2018-12-14 11:35:58 ncopa: https://github.com/docker-library/official-images/blob/master/library/alpine 2018-12-14 11:42:22 found it, 256k buffer on stack :roll: 2018-12-14 11:42:54 fabled: thats classic... 2018-12-14 11:42:57 in mesa/src/util/disk_cache.c:deflate_and_write_to_disk() 2018-12-14 11:43:02 ncopa, any suggestions how to fix 2018-12-14 11:43:23 problem is in mesa? 2018-12-14 11:43:35 yes 2018-12-14 11:43:50 mesa created threads; and some of them use the 256k buffer on stack 2018-12-14 11:44:50 time to try -Wl,-z,stack-size=N ? 2018-12-14 11:44:58 or just make the deflate buffer smaller 2018-12-14 11:45:15 i'd prefer either use buffer smaller or malloc the buffer 2018-12-14 11:45:46 yeah. probably simplest to make it smaller 2018-12-14 11:46:02 looks like buffer shuold be 128 or 256k according comment 2018-12-14 11:46:10 * From the zlib docs: 2018-12-14 11:46:11 * "If the memory is available, buffers sizes on the order of 128K or 256K 2018-12-14 11:46:11 * bytes should be used." 2018-12-14 11:47:23 it does not matter 2018-12-14 11:47:27 it can be smaller 2018-12-14 11:47:40 though, is suppose it achieves optimal performance 2018-12-14 11:48:10 we could use 32k or 64k to start with 2018-12-14 11:48:37 im not sure 32k buffer on stack is a good idea 2018-12-14 11:49:09 it really depends on the size of extraction is done 2018-12-14 11:49:58 oh, it's used to create some cache stuff 2018-12-14 11:53:30 i think safest is to put it on heap 2018-12-14 11:53:31 the cache files I have are small (under 1kB) 2018-12-14 11:53:33 malloc it 2018-12-14 11:54:07 something like this: http://tpaste.us/xp1r 2018-12-14 11:54:10 2kB buffer? 2018-12-14 11:54:41 8k buffer should probably be ok too 2018-12-14 11:54:56 based on my cache folder, i'd say 4kb is good 2018-12-14 11:55:05 aha 2018-12-14 11:55:27 4k it is then :) 2018-12-14 11:55:32 i think it should be reported upstream 2018-12-14 11:55:36 mileage may vary of course 2018-12-14 11:55:49 nothing breaks. in any case 2018-12-14 11:55:57 it affects only how many times the API call needs to be done 2018-12-14 11:55:58 i have no clue what the typical case is 2018-12-14 11:57:30 can you check you cache item sizes? in ~/.cache/mesa_shader_cache 2018-12-14 11:58:35 http://tpaste.us/yPNn 2018-12-14 11:59:33 ncopa, something like http://sprunge.us/A0Wg8O ? 2018-12-14 11:59:51 yeah, 4k it is 2018-12-14 11:59:52 yup 2018-12-14 11:59:58 i think most files are smaller. 2018-12-14 12:00:25 seems like they are less than 1000 bytes 2018-12-14 12:00:51 i had few around 3kB 2018-12-14 12:01:34 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 understood 2018-12-14 12:02:54 i push http://sprunge.us/rfU7cX ? 2018-12-14 12:03:11 yes please 2018-12-14 12:03:37 so i have 36 files of 1200 that are > 4096 2018-12-14 12:04:00 so 3% 2018-12-14 12:04:50 we should send the patch upstream 2018-12-14 12:04:50 oh. we could bump it to 8k too 2018-12-14 12:05:04 8k would be 100% 2018-12-14 12:05:22 there's also some 10-200 bytes header before the deflated part 2018-12-14 12:06:57 i guess 4k vs 8k doesnt make any diff in practice for performance 2018-12-14 12:07:09 but would need to be benchmarked to know for sure 2018-12-14 12:07:28 i'm pretty happy i got the issue found. it has been bugging me a long time 2018-12-14 12:07:34 there's few websites that kept crashing on me 2018-12-14 12:07:56 and i think also some media player did not work either at all. maybe same reason 2018-12-14 12:08:22 i would expect changing it from 256k to 4k (or 8k) increase perfromance due to fewer cache misses 2018-12-14 12:08:29 cpu cache misses 2018-12-14 12:10:47 also possible. depends on the work load... 2018-12-14 13:02:43 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 i think its reproducible on x86_64 too 2018-12-14 13:03:15 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 ok 2018-12-14 14:09:28 ncopa, seems openjdk7 builds on x86_64 (at least further than on arm) 2018-12-14 14:19:49 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 ncopa: does gcj break because of gcc 8? 2018-12-14 17:22:21 danieli: sort of 2018-12-14 17:22:37 it's the only viable bootstrap path :( 2018-12-14 17:22:53 gcc 7 and later does not support gjc at all, so we needed to add gcc6 2018-12-14 17:23:22 ah right, I forgot about that for a sec 2018-12-14 17:23:42 correction then, does gcc 6 break because of gcc 8? 2018-12-14 17:24:45 not that i know 2018-12-14 18:56:27 hum, perl-io-socket-ssl test suite hangs 2018-12-14 18:56:38 i thought i fixed it, but apparently its sort of random 2018-12-14 20:26:28 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 once that's stable that could be a great way to bootstrap rust :D 2018-12-14 20:57:27 Any idea why in alpine:3.8 does not work dig ANY google.com? (-t ANY) 2018-12-14 21:01:52 muhaha: I get lots of answers - are you sure your resolv.conf is populated? 2018-12-14 21:03:55 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 well I am able to resolve: dig A +short google.com 2018-12-14 21:05:24 SpaceToast: ^ 2018-12-14 21:05:34 do hold on, I'm trying to reproduce 2018-12-14 21:07:12 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 if you remove +short you'll notice that you get some output 2018-12-14 21:07:50 note that this happens on other distros (that I've just tried it on) as well 2018-12-14 21:09:07 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 (and nowhere else) 2018-12-14 21:10:40 well it works in my ubuntu:bionic .. there is systemd-resolved 2018-12-14 21:10:57 it doesn't work on my docker host (arch) with systemd-resolved 2018-12-14 21:11:11 nor on an ubuntu bionic baremetal system at work 2018-12-14 21:11:34 it does work on an ubuntu bionic baremetal system connected to local unbound directly though 2018-12-14 21:11:38 why exactly are you using -t ANY? 2018-12-14 21:13:51 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 ANY is discouraged 2018-12-14 22:02:43 ^ 2018-12-14 22:02:49 most sane nameservers block it 2018-12-14 22:03:29 it has no real use anyway since ANY won't return what you think it will 2018-12-14 22:03:41 and its an amplification vector 2018-12-14 22:05:38 muhaha: but yeah, what exactly are you expecting, and *how* does it not work? 2018-12-14 22:15:01 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 you should not keep zone transfer enabled without a strict whitelist 2018-12-14 22:15:32 I am aware of this 2018-12-14 22:16:03 just making sure 2018-12-15 02:01:59 oh 2018-12-15 02:02:02 how did I not spot this before 2018-12-15 02:02:04 ACTION sighs 2018-12-15 02:02:33 I'm not sure this package ever worked 2018-12-15 02:03:18 that is a commonly-known feeling in the computing industry 2018-12-15 02:03:56 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 :D 2018-12-15 02:04:17 heh 2018-12-15 02:05:42 alright, well thats one thing fixed 2018-12-15 02:06:44 https://github.com/joeholden/aports/commits/litespeed 2018-12-15 02:06:45 o/ 2018-12-15 02:06:56 ugh, typo 2018-12-15 02:39:39 woot woot strange RISC-V musl bugs fixed 2018-12-15 02:39:43 \o\ 2018-12-15 02:39:44 /o/ 2018-12-15 02:39:59 porting packages now resumes 2018-12-15 02:40:50 ddevault: nice! So musl's officially fully ported to RISC-V now then? :D 2018-12-15 02:40:57 well, who knows if I'll hit more bugs 2018-12-15 02:41:08 all the bugs, I hope 2018-12-15 02:41:17 wouldn't be any good if some were to remain unsquashed :) 2018-12-15 02:41:17 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 ah, hope you guys can get it upstreamed soon :) 2018-12-15 02:41:30 https://github.com/riscv/riscv-musl/pull/3 2018-12-15 02:41:32 but \o/ for now 2018-12-15 02:41:39 musl wants to upstream it in the next release iirc 2018-12-15 02:41:51 hmmm, speaking of... are there any tools packaged for bringing up new architectures? 2018-12-15 02:42:34 aports has scripts/bootstrap.sh, which has been indispensible in this effort 2018-12-15 02:42:55 I'll be putting together some improvements to it later and sending them along 2018-12-15 02:43:27 nice, thank you :) 2018-12-15 02:43:36 cool 2018-12-15 02:44:25 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 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 bootstrap.sh basically works 2018-12-15 02:44:53 but I'd like to make some quality-of-life improvements 2018-12-15 02:45:03 e.g. not having to edit it to cross-compile another package with your sysroot 2018-12-15 02:45:05 well yes, but the idea is to give insight into the inner workings/details :) 2018-12-15 02:45:21 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 with fewer risc-v specific details, naturally 2018-12-15 02:45:39 oh just linking the blog post in the channel should be more than enough, thanks :) 2018-12-15 02:45:47 sure thing 2018-12-15 02:46:09 (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 https://drewdevault.com 2018-12-15 02:46:44 you tell me 2018-12-15 02:47:02 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 expect an email on alpine-devel with status/how to help, and a bunch of patches 2018-12-15 02:47:45 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 I probably won't have my weird kernel stuff sorted soon, though 2018-12-15 02:48:21 :/ 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 no worries 2018-12-15 02:48:35 I intend to automate most of the process 2018-12-15 02:49:31 :) 2018-12-15 03:14:10 ... wow 2018-12-15 03:14:12 woot woot woot 2018-12-15 03:14:20 clandmeter: it's a little buggered 2018-12-15 03:15:17 either way, neat @ ddevault 2018-12-15 03:15:30 ^^ 2018-12-15 03:15:36 will be pushing up a new set of patches to my aports tree shortly 2018-12-15 03:16:03 if it doesn't affect anything else, it'd be neat to get it upstream 2018-12-15 03:16:48 looking foward to it 2018-12-15 03:17:06 lots of work ahead though 2018-12-15 03:17:54 if the patches do have any adverse effects, i'd assume we want to review 2018-12-15 03:18:07 I assume you want to review either way 2018-12-15 03:18:29 well yeah, but extra care needs to be taken if they have any adverse side-effects 2018-12-15 03:18:41 I see 2018-12-15 03:18:50 well, so far I don't know of anything which introduces risk to other ports 2018-12-15 03:19:13 risc-v isn't so terribly weird it turns everything it touches into shit, so that's good :) 2018-12-15 03:19:28 in fact, riscv is super cool, this arch is awesome 2018-12-15 03:19:42 this is some of the most fun I've had on a project in recent memory 2018-12-15 03:22:17 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 offer still stands to use my hardware 2018-12-15 03:23:09 I'm going to automate building world on builds.sr.ht 2018-12-15 03:23:28 it would be cool, we'll have to discuss it 2018-12-15 04:12:30 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 its pretty horrible either way due to having to move things around 2018-12-15 04:17:09 https://mirror.sr.ht/alpine/main/ 2018-12-15 04:18:03 I now have apk working and pulling updates/packages from this repo on my hifive unleashed 2018-12-15 04:19:02 nice 2018-12-15 04:20:16 what are you using for the building? 2018-12-15 04:20:19 software that is 2018-12-15 04:20:38 ? 2018-12-15 04:20:52 I have a sysroot on an x86_64 machine based on bootstrap.sh 2018-12-15 04:20:59 working on setting up an abuild thing on the riscv64 machine too 2018-12-15 04:21:02 ah 2018-12-15 04:21:05 need a few other things 2018-12-15 04:21:08 cool 2018-12-15 04:21:22 just porting some quality of life stuff right now 2018-12-15 04:21:46 heh 2018-12-15 04:22:04 so I have a comfortable working environment on this machine 2018-12-15 04:27:23 I also put this up https://mirror.sr.ht/alpine/community/ 2018-12-15 04:41:09 o/ 2018-12-15 04:41:47 self-hosting status: ALMOST works, but I need a newer kernel to get fakeroot to work 2018-12-15 04:51:54 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 but then apparently it can't even build gcc 2018-12-15 05:26:30 what on earth, my serial ports are all messed up 2018-12-15 05:55:07 https://gist.github.com/joeholden/850e6303c9da6f23e9f8c7222d1fc0b2 2018-12-15 05:55:08 P( 2018-12-15 05:55:10 :( 2018-12-15 09:51:52 ncopa, clandmeter : https://dpaste.de/5U6r/raw 2018-12-15 09:52:26 i had to create a py2 dir and slighlty modify the standard py APKBUILD template for this package 2018-12-15 09:52:35 what do you think? 2018-12-15 12:12:41 fcolista, in edge py3-setuptools lives inside of python3, there was some issue to decouple 2018-12-15 13:11:07 clandmeter, would be great to get you POV https://github.com/alpinelinux/aports/pull/5180 2018-12-15 14:53:56 andypost: o/ 2018-12-15 15:00:51 hm actually, no that change is all wrong 2018-12-15 15:00:55 baaad 2018-12-15 15:01:48 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 andypost, good point. 2018-12-15 16:10:22 https://dpaste.de/DMRu/raw 2018-12-15 16:30:55 jwh: pretty sure it fails because you're using the kernel headers for the wrong arch 2018-12-15 16:31:11 struct sigcontext is different on x86 vs mips 2018-12-15 16:33:22 well I dunno, I just ran bootstrap.sh with the target 2018-12-15 16:33:49 unless I misunderstood what bootstrap actually needs 2018-12-15 16:34:15 binutils succeeds, but then gcc fails 2018-12-15 16:58:00 oh that's weird 2018-12-15 16:58:31 lemme try it here 2018-12-15 17:15:39 jwh: works like expected here so far 2018-12-15 17:15:47 are you running edge or stable? 2018-12-15 17:15:54 edge 2018-12-15 17:15:58 master apoerts 2018-12-15 17:15:59 aports* 2018-12-15 17:16:32 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 gave it that, and the tagret 2018-12-15 17:16:40 target* 2018-12-15 17:22:42 the 3.8 minirootfs from the dl page? 2018-12-15 17:23:05 oh, nope, apk --initdb 2018-12-15 17:23:09 edge also 2018-12-15 17:23:35 maybe I should have used the rootfs now its available 2018-12-15 17:28:48 maybe, but you should still be on edge in the build chroot when compilng edge packages iirc 2018-12-15 17:29:07 I'm running the bootstrap in a alpine:edge Docker container 2018-12-15 17:29:19 only installed alpine-sdk in it 2018-12-15 17:29:37 cloned aports and started the bootstrap 2018-12-15 17:30:00 hm 2018-12-15 17:30:05 weird 2018-12-15 17:32:15 lemme start again 2018-12-15 17:57:55 hm 2018-12-15 18:00:28 ncopa: I posted new crystal APKBUILD few days ago, https://patchwork.alpinelinux.org/patch/4273/ 2018-12-15 18:01:09 if you remember, we talked about before your travel 2018-12-15 18:02:52 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 calm down, when it gets to it, 3.9 won't be released without it 2018-12-15 18:08:52 there are still things left to do before that 2018-12-15 18:11:16 danieli: ok, hope so 2018-12-15 18:13:31 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 danieli: in that case i'm appearing as a crystal devs agent, unpaid unfortunately :) 2018-12-15 18:21:07 Lochnair: I must be doing something wrong 2018-12-15 18:22:01 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 or bootstrap, rather 2018-12-15 19:35:44 alpine riscv64 port is officially self-hosting :D 2018-12-15 19:36:08 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 hohoho, nice! 2018-12-15 19:37:10 been able to build world yet_ 2018-12-15 19:37:12 ? 2018-12-15 19:37:18 no longer in a chroot, booting into openrc 2018-12-15 19:37:33 haven't run the full build yet 2018-12-15 19:38:04 I have a few bootstrapping hacks to unhack first 2018-12-15 19:44:58 todo list https://sr.ht/8jZe.txt 2018-12-15 19:58:21 jwh: I mean probably, but I have no clue what that could be 2018-12-15 19:58:32 pretty sure that's abuild itself complaining 2018-12-15 19:58:47 it is ^ 2018-12-15 19:58:57 yeah 2018-12-15 19:59:16 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 nm, got loads of other things I *should* be doing heh 2018-12-15 20:07:03 heh, you and me both 2018-12-15 20:07:18 tho I can dump the resulting packages from my bootstrap somewhere if you want them 2018-12-15 20:07:48 that would be awesome 2018-12-15 20:11:32 there you go: https://dl.lochnair.net/Alpine/mips64-bootstrap/packages/ 2018-12-15 20:11:50 thank you sir 2018-12-15 20:12:12 np 2018-12-15 20:22:47 need to figure out why my serial cable isn't working now :D 2018-12-15 20:38:19 aw, Illegal instruction 2018-12-15 20:38:20 Illegal instruction 2018-12-15 20:38:21 oops 2018-12-15 20:38:43 may need to investigate 2018-12-15 21:14:24 heh, my freshly setup one I did before failed too, wonder what differs 2018-12-15 21:14:32 but anyway at least I got the toolchain 2018-12-15 21:19:35 oohhhh 2018-12-15 21:36:52 did you figure something out? 2018-12-15 21:40:10 I thought I had, but nope 2018-12-15 21:40:41 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 hifive:~$ echo "$(uname -m): $(apk search | wc -l)" 2018-12-16 23:42:42 riscv64: 487 2018-12-16 23:42:51 making pretty good progress 2018-12-17 00:02:04 is the 'riscv64' official arch name for it 2018-12-17 00:02:46 yes 2018-12-17 00:04:28 want to have such machine, but don't think that will happen soon 2018-12-17 00:04:47 they're somewhat difficult to obtain, but super cool and I highly recommend getting one if you can 2018-12-17 00:04:59 this one cost a grand and I had to wait like 5 months for it to be delievered 2018-12-17 00:05:33 though if their latest batch has leftovers there might not be a wait 2018-12-17 00:06:38 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 ddevault: could you give some estimation of the performance 2018-12-17 00:06:55 I only did one crappy "benchmark" 2018-12-17 00:07:13 your personal impression is enough for me 2018-12-17 00:07:46 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 the bottleneck is the very slow mmcblk I/O 2018-12-17 00:08:15 but on the whole I've been impressed with the performance on files which are in the cache 2018-12-17 00:08:57 mmc is slow, I build aarch64 and armhf/armv7 on mmc cards and that is slow job 2018-12-17 00:09:15 I'm going to move to nbd once I start doing automated builds of world 2018-12-17 00:09:22 or just RAM 2018-12-17 00:10:25 i like riscv cpu architecture 2018-12-17 00:11:12 me too 2018-12-17 00:12:19 i'll bye it for sure when it become available in my 'market' 2018-12-17 00:14:45 ddevault: thanks for sharing your impression about riscV, it is late here so good night 2018-12-17 00:14:49 night 2018-12-17 01:25:40 hmph, getting '1 error; 21 MiB in 26 packages', verbose isn't telling me whats wrong 2018-12-17 01:25:47 tried apk fix? 2018-12-17 01:26:04 ahhh, that'll do :D 2018-12-17 01:26:07 thanks 2018-12-17 01:26:24 (1/1) Reinstalling libcrypto1.1 (1.1.1a-r0) 2018-12-17 01:26:25 o/ 2018-12-17 01:26:33 let me guess, you went from stable to edge? 2018-12-17 01:26:36 ye 2018-12-17 01:26:45 yeah, that's related to libressl -> openssl 2018-12-17 01:26:52 also, this is #alpine-devel, the development channel 2018-12-17 01:26:53 yeah I thought it was 2018-12-17 01:26:56 ugh 2018-12-17 01:27:05 both next to each other on my keyboard :( 2018-12-17 02:04:33 the dependency tree for mutt is wild 2018-12-17 02:04:41 I'm almost 50 packages into it 2018-12-17 02:04:56 and that's _after_ disabling some features in various packages 2018-12-17 02:05:16 that seems... excessive 2018-12-17 02:05:25 it's mostly all of the crypto dependencies 2018-12-17 02:05:27 gnupg 2018-12-17 02:05:29 etc 2018-12-17 02:05:37 slightly related: i'm actually working on a new aports/pkgs browser 2018-12-17 02:05:46 dependency trees are cool 2018-12-17 02:05:51 nice 2018-12-17 02:06:24 lots of these crypto-related packages have large, slow test suites too :/ 2018-12-17 02:06:41 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 how does 3.9 matter to that? 2018-12-17 02:07:08 new packages land in edge 2018-12-17 02:07:20 and releases are essentially freezes of edge 2018-12-17 02:07:22 well, presumably thats more of a focus so time is being spent there instead 2018-12-17 02:07:51 edge (master) is where the fun happens 2018-12-17 02:07:54 which is cool, just wondering 2018-12-17 02:08:20 yeah 2018-12-17 02:11:27 >PASS: t-do-exceptions-work-at-all-with-this-compiler 2018-12-17 02:11:30 spiteful test, that one 2018-12-17 02:11:43 lol 2018-12-17 02:11:50 i bet it's there for a reason 2018-12-17 08:05:33 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 ncopa, yeah, x86_64 openjdk7 bootstrap fails because of incorrect code generation in gcc8 2018-12-17 08:55:19 i think erlang (specifically erlang-wx) needs a rebuild against whatever is the latest wxwidgets version 2018-12-17 08:55:26 observer (and probably other things) are breaking 2018-12-17 08:55:58 built against abi 1010, current is 1013 2018-12-17 09:08:29 ncopa, the miscompiled part: http://sprunge.us/1zX1bw ... 2018-12-17 09:10:20 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 ah lol, that gets generated on the fly :| 2018-12-17 12:59:29 hello, everyone~~~ 2018-12-17 12:59:44 Ask a simple question 2018-12-17 13:00:09 I want to develop on Alpine linux. Where can I download the source code? 2018-12-17 13:00:21 Do we have any github? or download scripts? 2018-12-17 13:00:31 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 yes 2018-12-17 13:02:34 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 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 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 https://github.com/alpinelinux/aports 2018-12-17 13:06:12 I think it's this? 2018-12-17 13:06:49 <_ikke_> yes 2018-12-17 13:07:07 okay, Thanks. I will download 2018-12-17 13:22:00 seems use mkimage.sh this script to downlaod sourcecode and compile automatically. 2018-12-17 13:22:10 Am I right? @_ikke_ 2018-12-17 13:23:09 ripplewang888: alpine is built of thousands of packages 2018-12-17 13:23:20 one of those packages is the kernel, linux-vanilla 2018-12-17 13:23:48 the mkimage.sh collects a chosen number of packages and creates a bootable iso image from it 2018-12-17 13:24:52 each package has an APKBUILD, a script that describes how to build it 2018-12-17 13:25:13 okay, I think when system is up. Package also can use apk install? 2018-12-17 13:25:35 So when compile system, just need to build the minimal system? 2018-12-17 13:25:44 the packages built from the APKBUILDs can be installed with `apk add`, yes 2018-12-17 13:25:57 depends a bit what you want to build 2018-12-17 13:26:04 do you want build a bootable iso image? 2018-12-17 13:26:10 yes. 2018-12-17 13:26:13 with uboot 2018-12-17 13:26:15 kernel 2018-12-17 13:26:17 rootfs 2018-12-17 13:26:38 sorry, today is my first day. so lots of question. 2018-12-17 13:26:54 and you want build all the packages shipped on the iso from source? 2018-12-17 13:27:57 no. choose some package. not all package? I think can use make menuconfig to configure? 2018-12-17 13:28:37 I want to build the minimal system, with my own chipset driver. 2018-12-17 13:28:41 no, menuconfig is for kernel modules. not for distro software packages 2018-12-17 13:28:53 okay, 2018-12-17 13:29:49 do you only want build kernel? or do you also want build userspace tools, like apk, libc etc? 2018-12-17 13:30:03 yes, include apk ,libc 2018-12-17 13:30:19 so , use mkimage.sh can reach this? 2018-12-17 13:30:26 no 2018-12-17 13:30:41 you need build each package you want first, using abuild 2018-12-17 13:30:42 mkaimage.sh only for kernel? 2018-12-17 13:31:06 mkimage only builds the bootable iso image, but it dependsn on prebuilt apk packages 2018-12-17 13:32:09 Does this script download kernel sourcecode? 2018-12-17 13:32:26 If I want to change some driver for my own board. 2018-12-17 13:32:43 like clocks. memory controller...etc 2018-12-17 13:32:55 HDMI.. bluetooth 2018-12-17 13:33:43 where is abuild? I can't find in script directory 2018-12-17 13:38:15 Do you have any help document ? or link ? 2018-12-17 13:38:35 documentation is poor. we are working on it. 2018-12-17 13:38:43 About how to set up development environment. 2018-12-17 13:38:48 its best to first look around the repos, then come back and ask questions. 2018-12-17 13:39:18 we have documentation on the wiki. but its not 100$% complete. 2018-12-17 13:39:35 yes. 2018-12-17 13:40:21 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 okay . 2018-12-17 13:43:09 Thanks a lot 2018-12-17 13:43:23 fabled, are you on vpn already? 2018-12-17 13:46:44 I'm not using vpn. can access this chat room directly. 2018-12-17 13:48:58 ripplewang888: last I checked you were ripplewang888, and not fabled :) 2018-12-17 13:50:17 oh... 2018-12-17 23:52:35 who was it that was working on a tool for working with dependency trees 2018-12-17 23:54:28 i'm working on a service that incorporates them, not sure if you're aiming at that 2018-12-17 23:55:07 probably not 2018-12-17 23:55:08 I was wondering about how best to prioritize which packages to build in world 2018-12-17 23:55:16 part of that would be ordering them right 2018-12-17 23:55:27 I could just iterate over everything in order and abuild -R 2018-12-17 23:55:39 it's probably best to just prioritize main/ 2018-12-17 23:56:01 how big is main once compiled? for x86_64 2018-12-17 23:56:24 17.3G ./main 2018-12-17 23:56:25 that's in 3.8 2018-12-17 23:56:42 thanks 2018-12-17 23:56:42 20.6G in edge 2018-12-17 23:56:49 so it's around 20 somewhere 2018-12-17 23:56:51 how about community 2018-12-17 23:57:04 28G in 3.8, 34.7 in edge 2018-12-17 23:57:24 oh right, this is all the architectures, my bad! 2018-12-17 23:57:25 gotcha, thanks 2018-12-17 23:57:29 oh, that helps 2018-12-17 23:57:31 let me check again 2018-12-17 23:57:55 i thought it felt strangely large 2018-12-17 23:57:56 v3.8/main/x86_64 is 3G 2018-12-17 23:58:08 and 3.1G in edge 2018-12-17 23:58:53 so, edge/{main,community}/x86_64 are 3.1G and 6.2G respectively 2018-12-17 23:58:55 nice 2018-12-17 23:59:04 that's a very reasonable size 2018-12-17 23:59:08 agreed 2018-12-17 23:59:33 in other news, ✓ ruby 2018-12-18 03:33:52 for the moment I'm out of packages I need to build for my own ends 2018-12-18 03:34:12 and switching gears to finishing up that ffmpeg upgrade workstream I had going 2018-12-18 03:34:31 in the meantime any suggestions on what to have building so my RISC-V doesn't get cold? 2018-12-18 03:36:10 the largest and most challenging ones, probably 2018-12-18 03:36:15 it'll highlight some potential issues 2018-12-18 03:36:29 I'm looking easy stuff I can build in the background while my focus is elsewhere 2018-12-18 03:36:38 if I hit issues I'll write it down and look later 2018-12-18 03:36:46 ah, fair enough 2018-12-18 03:36:58 you could just have it build everything and skip + log on errors 2018-12-18 03:37:05 I suppose 2018-12-18 03:37:15 I could also do a native gcc build 2018-12-18 03:37:22 that'll take a while 2018-12-18 03:37:49 actually I probably should just recompile everything that was cross compiled 2018-12-18 04:11:30 checking for libcurl soname... Segmentation fault 2018-12-18 04:11:35 building kodi on x86_64 2018-12-18 04:11:45 about what I expected from kodi 2018-12-18 04:11:55 no surprise there 2018-12-18 08:18:21 ncopa: keep an eye on sqlite, bugfixes a' comin 2018-12-18 08:19:33 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 I suppose it wasn't a 10 second exploitable one but "remote code execution" always sounds severe 2018-12-18 08:40:22 I guess the noise was mostly about the fact sqlite is practically everywhere these days 2018-12-18 08:40:31 yeah 2018-12-18 08:40:38 tl;dr upgrade to 3.26.0, context @ https://blade.tencent.com/magellan/index_en.html 2018-12-18 08:41:40 as far as I saw, it has pretty specific requirements for exploitation 2018-12-18 09:39:26 anybody can help figure out whats wrong with perl-net-ssleay? 2018-12-18 09:39:42 the perl-io-socket-ssl test suite seems to hang occationally 2018-12-18 09:40:11 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 hum... maybe the latest patch fixed it 2018-12-18 10:07:06 ncopa: it passed all tests right now, at least on my edge box with 'abuild -r' 2018-12-18 10:07:35 yeah, samae here 2018-12-18 10:07:44 i think problem may be fixed 2018-12-18 10:11:55 and it is linked with openssl, so everything looks ok 2018-12-18 10:15:46 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 ncopa: regarding packages that are hanging seems that: py-pynacl 1.3.0-r0 too 2018-12-18 11:23:39 ncopa: in the ppc64le builder I can see: build-edge-ppc64le main/py-pynacl 1.3.0-r0 2018-12-18 11:23:50 seems it is running since yesterday 2018-12-18 13:50:57 mps: seems like rnalrd pushed your crystal patch. thanks to both of you! 2018-12-18 13:56:20 np 2018-12-18 14:14:49 ncopa, you around? 2018-12-18 14:15:23 What do you think? https://dpaste.de/gNrY/raw 2018-12-18 14:16:22 seems that py-future cannot be built within the same dir 2018-12-18 14:16:47 so I had to create a dir for py2 and build the package from there 2018-12-18 14:17:14 perhaps jirutka[m] or clandmeter have some ideas on that 2018-12-18 14:17:46 arch does something like that 2018-12-18 14:17:46 https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/python-future 2018-12-18 14:19:12 rnalrd: I 2018-12-18 14:19:31 sorry, I'm mostly here if help needed with it 2018-12-18 14:22:03 mps, thank it went through smoothly 2018-12-18 14:29:56 fcolista, looks ok 2018-12-18 14:34:26 thx a lot clandmeter 2018-12-18 15:57:25 fcolista: im here 2018-12-18 15:58:18 hi ncopa 2018-12-18 15:58:18 https://bugs.alpinelinux.org/issues/9136 2018-12-18 15:58:26 wondering if this is enough 2018-12-18 15:58:34 [ $python == "python2" ] is bashism 2018-12-18 15:58:46 aha 2018-12-18 15:58:47 [ "$python" = "python2" ] 2018-12-18 15:59:12 i personally think its more readable with an if .. else 2018-12-18 15:59:15 if [ "$python" ... 2018-12-18 15:59:21 ok good 2018-12-18 15:59:41 yeah, its more lines of code, but the intention is clearer 2018-12-18 16:00:07 i did it to have less lines actually 2018-12-18 16:00:21 but I've not thought that it was a bashism 2018-12-18 16:00:23 ok good 2018-12-18 16:01:13 https://dpaste.de/Gh0a/raw 2018-12-18 16:01:55 == 2018-12-18 16:01:58 use single = 2018-12-18 16:02:12 the double == is bashism 2018-12-18 16:02:30 ah that part was the bashism 2018-12-18 16:02:31 ok 2018-12-18 16:03:07 otherwise it looks good 2018-12-18 16:03:35 ok good. Pushed 2018-12-18 16:04:26 oh... 2018-12-18 16:04:38 shouldprobably have a comment on why the -fno-PIC is needed 2018-12-18 17:29:16 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 i think it hangs because perl-io-ssleay was installed build time 2018-12-18 17:36:16 restarted the builder. lets see if it still hangs 2018-12-18 20:38:53 xf86-video-s3 on armv7? is it needed there 2018-12-19 09:29:21 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 development as in? 2018-12-19 09:30:26 clandmeter: Progress for release 2018-12-19 09:30:47 armv7 will be released for next alpine release. 2018-12-19 09:31:59 its still struggling with building world. 2018-12-19 09:32:56 you can see some progress in alpine-commits channel. 2018-12-19 09:36:36 and you can see current status on build.alpinelinux.org 2018-12-19 10:08:50 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 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 and another one with Xorg running quite fine, when I need it 2018-12-19 10:15:26 mps: I will rely on your good judgement with regards to stability 2018-12-19 10:15:35 mps: I really would like to know when it'll be formally released 2018-12-19 10:15:57 mps: But again, without bugging you guys every week 2018-12-19 10:16:17 mps: Are there any weekly meeting minutes I can go look at (or similar)? 2018-12-19 10:20:16 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 but, some packages (apks) could be missing in it if couldn't be built on armv7 2018-12-19 10:22:47 s/if couldn't/if they couldn't/ 2018-12-19 10:22:47 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 mps: Thanks for the info 2018-12-19 10:28:39 alpine-meetbot: Thanks for the clarification :'D 2018-12-19 18:14:06 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 set ngroups_max = 32 2018-12-19 18:16:41 mtutty: the default on alpine (as far as I can see) is 65536 2018-12-19 18:16:50 you can use sysctl kernel.ngroups_max 2018-12-19 18:16:58 you can set it on boot in /etc/sysctl.d 2018-12-19 18:17:11 Super! Will try that right away. 2018-12-19 18:20:55 @SpaceToast Would the docker image be any different? 2018-12-19 18:20:58 I see this: 2018-12-19 18:20:59 docker run -it --rm alpine getconf NGROUPS_MAX 2018-12-19 18:20:59 32 2018-12-19 18:22:32 docker is a container system 2018-12-19 18:22:42 this means that it runs in a namespace under the host 2018-12-19 18:22:54 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 in terms of getconf I think musl defines NGROUPS_MAX as 32 (and provides getconf) 2018-12-19 18:23:38 but my understanding is that it's the kernel setting that matters 2018-12-19 18:24:12 SpaceToast: It's not host-related. 2018-12-19 18:24:13 docker run -it --rm debian:8-slim getconf NGROUPS_MAX 2018-12-19 18:24:13 65536 2018-12-19 18:24:23 ... you did read *everything* I wrote, right? 2018-12-19 18:25:11 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 So it's really a musl problem, not a kernel config thing. 2018-12-19 18:25:43 ngroups is a kernel thing 2018-12-19 18:25:54 musl defines NGROUPS_MAX as 32 and provides getconf 2018-12-19 18:26:00 try docker run --rm alpine cat /proc/sys/kernel/ngroups_max 2018-12-19 18:26:31 are you actually running into the limit, or are you pre-emptively optimizing? :) 2018-12-19 18:26:45 No optimization yet :) 2018-12-19 18:27:04 We're seeing a failure using nscd and nss-pgsql. 2018-12-19 18:27:35 It works, but we'll get different # of groups on alpine vs debian. 2018-12-19 18:28:07 if you use getconf, which I just explained twice to not be relevant 2018-12-19 18:28:14 or are you *actually* seeing a failure? 2018-12-19 18:28:23 "we're seeing a failure" -> "it works" seems like a strange thing to say 2018-12-19 18:28:55 SpaceToast: "A failure" !== "nothing works" 2018-12-19 18:29:06 ok, so what exactly isn't working? 2018-12-19 18:29:23 We're getting a limited # of groups under alpine vs debian. 2018-12-19 18:29:26 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 are you actually hitting and confirming that limit, or are you assuming that getconf is correct? 2018-12-19 18:31:27 We're trying to figure out why nss-pgsql works differently on alpine vs debian. 2018-12-19 18:31:45 what are the symptoms of it working differently? 2018-12-19 18:33:15 SpaceToast: I'm digging up the specific getent cmds 2018-12-19 18:33:45 also, you may want to note that musl does not actually have (or want) nss 2018-12-19 18:33:50 https://wiki.musl-libc.org/future-ideas.html 2018-12-19 18:34:23 (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 Yes, we got that distinct impression. https://bugs.alpinelinux.org/issues/6711 2018-12-19 18:34:59 So maybe we're wasting time trying to get this working. 2018-12-19 18:36:11 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 but ultimately, neither getconf nor getent are reliable tools for finding out details as to NGROUPS_MAX 2018-12-19 18:36:37 because that is ultimately a kernel setting 2018-12-19 18:37:10 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 as I just mentioned, musl-nscd does not read (and thus does not care) about NGROUPS_MAX 2018-12-19 18:37:33 And we have another bug to fix there anyway, so maybe we should focus on that code. 2018-12-19 18:38:40 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 even though I doubt that's an actual source of your problems 2018-12-19 18:39:12 the likely issue you're actually encountering is that musl-nscd implements a subset of the nss protocol 2018-12-19 18:40:02 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 the only one I'm aware of is https://github.com/pikhq/musl-nscd 2018-12-19 18:44:25 they also have an APKBUILD but it clearly isn't in our world right now 2018-12-19 18:44:40 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 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 either way, alpine uses musl, whose official stance is "we do not have (nor want) NSS" 2018-12-19 18:45:54 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 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 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 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 (and I *still* don't know what failures you encounter) 2018-12-19 21:40:01 don't you just hate it wehn your build vms walk off 2018-12-19 21:40:21 when* 2018-12-19 21:40:31 searched *all* 30 odd screen windows, not a sign 2018-12-19 21:43:37 hm, what should I use for pkgver if the package has no release version? 2018-12-19 21:45:23 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 ultimately what matters is that pkgver increments over time (so rebuilds work), at least as my understanding goes 2018-12-19 21:45:47 yeah I'm not really expecting it to 2018-12-19 21:46:12 just thought it might be useful 2018-12-19 21:48:34 once I figure out how to make it git clone ayway 2018-12-19 21:49:04 anyway 2018-12-19 21:49:43 guess I could just use archive 2018-12-19 21:50:16 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 also snapshot() 2018-12-19 21:51:06 oh, cool 2018-12-19 21:52:32 yeah I don't grok that 2018-12-19 22:46:40 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 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 I've attempted to follow https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package 2018-12-19 22:48:26 erm 2018-12-19 22:48:31 there's already a dovecot package 2018-12-19 22:48:33 you can just modify that 2018-12-19 22:48:44 But it doesn't quite tell me how to build the debug symbols 2018-12-19 22:49:23 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 https://git.alpinelinux.org/cgit/aports/tree/main/dovecot/APKBUILD 2018-12-19 22:50:21 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 muhlemmer|2: subpackages="$pkgname-dbg" 2018-12-19 22:50:36 yup, default_dbg() is a thing 2018-12-19 22:50:59 ok, that'd be cool. 2018-12-19 22:51:12 thansk for the hint 2018-12-19 23:02:24 muhlemmer|2: options="!strip" 2018-12-19 23:02:48 thanks also 2018-12-19 23:07:49 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 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 jwh: https://github.com/OpenRC/openrc/blob/master/service-script-guide.md 2018-12-19 23:12:50 the official docs will have our own guide, but that'll take a bit 2018-12-19 23:12:58 feel free to poke me with what you make, I'll provide feedback 2018-12-19 23:13:16 yeah i'm looking at that 2018-12-19 23:13:33 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 yes, you can 2018-12-19 23:13:54 it's in that link 2018-12-19 23:14:01 you should almost never have a start() at all 2018-12-19 23:14:11 oh hm 2018-12-19 23:14:16 I'm missing it 2018-12-19 23:16:03 theres start_pre(), but no post so I'll have to just have start-stop-daemon in start() 2018-12-19 23:16:08 there is a post 2018-12-19 23:16:13 it's just not on the page :) 2018-12-19 23:16:15 oh 2018-12-19 23:16:26 kinda useless pointing me to the doc I'm already reading then :P 2018-12-19 23:16:43 you were asking if a doc exists 2018-12-19 23:16:50 you said you were reading it after I linked it 2018-12-19 23:17:20 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 coz I do that 2018-12-19 23:17:29 well, yes there is :) 2018-12-19 23:17:42 you can look at /lib/rc/*stuff* 2018-12-19 23:17:43 post works, that'll do 2018-12-19 23:17:51 someone should document it or something 2018-12-19 23:17:57 :D 2018-12-19 23:18:06 as I said, I'm working on it ;) 2018-12-19 23:18:53 :D 2018-12-19 23:37:03 SpaceToast: brebs: mps: All your suggestions are working like a charm! In the end not so difficult. Thanks 2018-12-20 04:42:52 draft https://gist.github.com/ddevault/c6c076f1b975f945c7b72cbfb3654168 2018-12-20 04:43:01 I don't recall exactly who wanted to see this, something about docs 2018-12-20 04:43:20 when I finish updating the bootstrap script I'll probably add a page to the alpine wiki 2018-12-20 04:44:21 ddevault: that'd be me, thanks :) 2018-12-20 04:44:47 np 2018-12-20 04:46:19 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 s/source// 2018-12-20 04:46:30 (draft) 2018-12-20 04:47:21 and the claims about the hifive board are … interesting 2018-12-20 04:47:45 which claims? that it's suprisingly fast? 2018-12-20 04:48:28 that it's the first totally free computer? yeah... it's a stretch 2018-12-20 04:48:34 I should remove that, clarifying it would ruin the point 2018-12-20 04:49:47 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 I can put the hifiveu on an FPGA 2018-12-20 04:50:24 is the same true of the ultrasparc? 2018-12-20 04:50:51 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 yes 2018-12-20 04:51:11 nice 2018-12-20 04:51:41 you probably want to look at openpiton which is an academically maintained fork of Sun's code drop 2018-12-20 04:52:16 but it won't exactly correspond to what's in a T2 chip you can buy 2018-12-20 04:52:25 #alpine-offtopic please :) 2018-12-20 07:14:34 morning ncopa 2018-12-20 08:06:33 danieli: morning 2018-12-20 11:56:15 seems like chromium is broken 2018-12-20 11:56:19 hangs occationally 2018-12-20 12:05:51 works fine for me, on edge 2018-12-20 12:06:04 actually performs way better than on my arch desktop 2018-12-20 12:06:33 i'm gonna try fixing chromium with a different patchset to get 70+ 2018-12-20 12:20:29 i pushed chromium 71 2018-12-20 12:20:32 which hangs 2018-12-20 12:20:36 aha, recently? 2018-12-20 12:20:37 i can try it out 2018-12-20 12:20:59 i have noticed a hang in google search restul page 2018-12-20 12:21:02 and slack 2018-12-20 12:21:21 slack is practically useless in chrome 71 2018-12-20 12:22:53 slack is practically useless period 2018-12-20 12:23:39 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 it works fine in other distros, so it's something related to our patchset or env 2018-12-20 12:28:18 hum, also commenting in PR reviews on github hangs 2018-12-20 12:29:00 it could also be that other distros (eg void) has patch for it and we don't 2018-12-20 12:29:43 it lags and uses a lot of cpu here 2018-12-20 12:30:38 where have you gotten the patchset for 71 from? 2018-12-20 12:33:10 ncopa, chromium needs rebuild against fresh sqlite https://www.sqlite.org/releaselog/3_26_0.html 2018-12-20 12:33:49 does firefox still use sqlite as their db backend? 2018-12-20 12:33:51 separate issue, but yeah 2018-12-20 12:35:21 danieli: from void 2018-12-20 12:35:41 andypost: huh? its not abi compatible= 2018-12-20 12:35:43 ? 2018-12-20 12:35:46 sec issue 2018-12-20 12:36:00 it's pretty bad, can be exploited through websql 2018-12-20 12:36:09 i think i posted it yesterday 2018-12-20 12:37:08 but does chromium need to be rebuilt? is sqlite not linked dynamic? 2018-12-20 12:38:18 if its not linked dynamic, then I would expect chromium to ship a bundled version of sqlite 2018-12-20 12:38:27 we need wait for upstream update in that case 2018-12-20 12:38:47 ncopa, not sure about dynamic linking there was chromium issue about make it work with system sqlite 2018-12-20 12:39:34 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 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 it looks like its not dynamically linked to libsqlite 2018-12-20 12:40:21 indeed 2018-12-20 12:40:25 so they bundle sqlite sources 2018-12-20 12:40:34 it does a lot of custom stuff around it with websql and all 2018-12-20 12:40:58 guess the issue https://bugs.chromium.org/p/chromium/issues/detail?id=22208 2018-12-20 12:41:17 wontfix, nice 2018-12-20 12:41:25 that looks like old issue from 2009 2018-12-20 12:41:38 they probably have a patched version of sqlite bundled 2018-12-20 12:41:51 probably 2018-12-20 12:41:53 so its no just to replace the sqlite source in chromium source tree 2018-12-20 12:42:27 and a simple rebuild wont do anything 2018-12-20 12:45:55 chromium bundles Version: 3.25.3 2018-12-20 12:48:16 i think the same problem is with firefox 2018-12-20 12:48:27 iirc firefox bundles 2 or 3 copies of sqlite :) 2018-12-20 12:48:37 not a big surprise 2018-12-20 12:49:21 ncopa, FF is not affected https://bugzilla.mozilla.org/show_bug.cgi?id=1247329 2018-12-20 12:52:11 looks new key should be used https://news.ycombinator.com/item?id=18686572 2018-12-20 13:00:18 ncopa, please accept secfix for mariadb https://github.com/alpinelinux/aports/pull/5779 2018-12-20 13:04:45 that's a whole lot of CVEs 2018-12-20 13:17:37 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 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 would be nice to be applied to next stable 2018-12-20 13:19:34 mps: is there a bugs.a.o issue for that? 2018-12-20 13:19:48 we generally use that and github to track target versions 2018-12-20 13:20:28 didn't post bug/issue, only sent patch 2018-12-20 13:21:02 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 understand that, but I have had feeling that sending patch to alpine-aports is enough 2018-12-20 13:22:38 it'd require repeated pokes on IRC, and things can slip through the cracks 2018-12-20 13:23:37 I thought that is the preferred to send patch than just made bug report 2018-12-20 13:25:20 340 open PRs, 81 patches in patchwork 2018-12-20 13:26:48 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 ncopa: thoughts? 2018-12-20 14:18:47 um 2018-12-20 14:19:35 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 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 yeah, so it's better to submit issues in only one place 2018-12-20 14:21:39 but should people create a bugs.a.o issue to track patchwork patches? 2018-12-20 14:21:40 github has labels 2018-12-20 14:21:53 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 #" 2018-12-20 14:22:13 and send the patch to either mailing list or github PR (but not both) 2018-12-20 14:22:53 all right, there you go pms 2018-12-20 14:23:04 s/pm/mp/ 2018-12-20 14:23:04 danieli meant to say: all right, there you go mps 2018-12-20 14:23:24 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 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 mm, good both for avoiding duplication and work and for tracking target versions 2018-12-20 14:32:17 ncopa: would you mind check this PR for linux-amlogic: https://github.com/alpinelinux/aports/pull/5831 2018-12-20 14:35:44 yangxuan: merged. thanks! 2018-12-20 14:41:58 ncopa: thanks, if it's possible move linux-amlogic to community? 2018-12-20 14:44:14 after upgrade it's 4.19, LTS 2018-12-20 14:45:06 have you tested that it's not broken? 2018-12-20 14:50:27 do you mean test linux-amlogic? yes, I have tested it on my android box 2018-12-20 14:50:38 all right, then I don't see why it can't be moved to community 2018-12-20 14:53:52 ddevault: hi, are you Drew DeVault? 2018-12-20 14:57:17 yangxuan: yes 2018-12-20 15:00:42 ddevault: I want to do some modification for ibus alpine package 2018-12-20 15:00:51 please, go right ahead 2018-12-20 15:01:10 remove this line: https://github.com/alpinelinux/aports/blob/master/testing/ibus/APKBUILD#L51 2018-12-20 15:01:32 seems fair 2018-12-20 15:01:59 that should be install-pkgconfigDATA, I think 2018-12-20 15:02:16 this probably came from the arch package because I'm dumb 2018-12-20 15:02:57 after remove this will keep pkg file, and some package like ibus-libpinyin need it for compiling 2018-12-20 15:03:09 ack 2018-12-20 15:05:25 if you are ok with this, I will create a PR later 2018-12-20 15:05:48 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 sure 2018-12-20 15:07:05 cheers 2018-12-20 15:27:43 yangxuan: Chinese ? would you like to join the qq group 558299436 ? 2018-12-20 15:28:28 I did not know that group was a thing 2018-12-20 15:32:24 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 yangxuan: i can move linux-amlogic to community but i will depend on someone else maintaning it 2018-12-20 15:33:12 eg, provide patches/bugfixes for the stable branch 2018-12-20 15:35:13 ncopa: what kind of patches 2018-12-20 15:35:37 bugfixes if needed, security fixes 2018-12-20 15:35:41 or general updates 2018-12-20 15:35:51 most linux updates are security updates 2018-12-20 15:36:04 even if there are no CVE 2018-12-20 15:37:07 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 setting up notifications for new releases on my packages is on my todo list... 2018-12-20 15:41:51 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 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 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 (prior to that I was using gitpunch) 2018-12-20 15:43:04 nice 2018-12-20 15:43:55 Hope there is tool like brew bump-formula-pr, can reduce most of work 2018-12-20 15:44:28 cd some/package/, vim APKBUILD, /pkgver, $^a, :wq 2018-12-20 16:15:23 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 it may or may not be trivial to resolve those conflicts 2018-12-20 16:16:14 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 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 i've learned that the hard way... 2018-12-20 16:48:49 ncopa: then maybe it's okay keep linux-amlogic in testing 2018-12-20 17:03:02 who would i speak to about some general questions? or email. thanks 2018-12-20 17:03:43 just ask your questions 2018-12-20 17:03:45 mm9899: #alpine-linux and alpine-user@lists.alpinelinux.org 2018-12-20 17:03:56 if it's related to alpine development, this channel, or alpine-devel@lists.alpinelinux.org 2018-12-20 17:04:54 cool, thank you. 2018-12-20 17:15:55 danieli: ncopa: thanks for explanation about sending patches and adding issues on bugs.d.o 2018-12-20 17:25:47 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 makes it a little harder to track target versions and stuff, but far from impossible 2018-12-20 17:28:51 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 actually I thought to add issue but hesitate just because of that 2018-12-20 20:21:19 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 i normally check the bugs, but i ofetn forgot to check patchwork 2018-12-20 20:24:41 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 will keep in mind that for future 2018-12-20 20:27:03 i mean, *specially* if you dont want your issue be forgotten when i tag stable release 2018-12-20 20:30:16 ah, ok. maybe two bugs, one for stable and one for edge :) 2018-12-20 20:34:14 we copy security bugs for every branch that is affected, but im not too happy with it 2018-12-20 20:34:41 i wish we had a beetter way to tell which branch a given issue affect 2018-12-20 20:37:07 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 yeah 2018-12-20 20:38:35 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 do you by 'lowest branch' mean lowest release version? 2018-12-20 20:39:44 yes, so if you for example have a fix that we need apply to v3.7 2018-12-20 20:39:52 then you sent target to v3.7.x 2018-12-20 20:39:56 set* 2018-12-20 20:40:33 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 commit message in master will have "ref #" 2018-12-20 20:40:59 same with 3.8-stable 2018-12-20 20:41:20 and 3.7-stable i change it to "fixes #" 2018-12-20 20:41:22 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 correct 2018-12-20 20:42:02 but sometimes a fix is required for older 2018-12-20 20:43:21 yes, understand for fixes, it should be backported, but new features are probably examined by their importance 2018-12-20 20:43:35 s/it/they/ 2018-12-20 20:43:35 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 yes, we normally dont backport new features 2018-12-20 20:47:53 ofc, it would require a lot of work. better is for users to just upgrade to newer release 2018-12-20 20:50:21 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 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 looks like git shortlog got a horizontal scrollbar 2018-12-20 21:57:02 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 starting to put together an install procedure https://git.sr.ht/~sircmpwn/alpine-riscv-bootstrap 2018-12-21 04:15:45 argh, i accidentally hit a button in protonmail and it sent some crap to alpine-devel 2018-12-21 04:15:46 oh well 2018-12-21 04:17:17 still not sure what to do about the kernel... 2018-12-21 04:18:15 aside 2018-12-21 04:18:26 this script is POSIX shell, whereas lots of alpine scripts use dash extensions 2018-12-21 04:18:38 in the future it might be wise to refactor those out of the rest 2018-12-21 08:05:51 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 s.h:17:10: fatal error: base/numerics/safe_conversions_arm_impl.h: No such file or directory 2018-12-21 08:05:52 #include "base/numerics/safe_conversions_arm_impl.h" 2018-12-21 08:05:52 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 2018-12-21 10:50:42 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 I have to do "abuild undeps" and then "abuild deps" for newly added each build deps in APKBUILD. 2018-12-21 10:52:13 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 This issue becomes really annoying when making a new package for Alpine. 2018-12-21 10:53:35 danieli: is that about me? 2018-12-21 10:56:50 terra: it might be relevant to it 2018-12-21 10:56:53 perhaps you remember ncopa? 2018-12-21 10:59:10 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 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 I haven’t get annoyed enough to take a look at it myself, yet 2018-12-21 13:38:46 ncopa: thanks for reply. hope we get it fixed. 2018-12-21 15:36:12 i know I'm a real pest, but can someone merge my PR now? :D 2018-12-21 15:37:28 which one...? 2018-12-21 15:37:37 5706 2018-12-21 15:37:42 which is? 2018-12-21 15:37:48 traefik, new aport 2018-12-21 15:37:51 aha 2018-12-21 15:37:52 been approved 2018-12-21 15:38:03 my other one needs review by the maintainer 2018-12-21 15:38:16 333 PRs 2018-12-21 15:38:22 crazy huh 2018-12-21 15:38:39 need more reviewers and stuff 2018-12-21 15:38:40 usually I'd suggest to wait your turn, but it's understandably pretty painful 2018-12-21 15:38:49 I know :( 2018-12-21 15:39:03 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 jwh: go to patchwork and scroll to the bottom, look at the dates and such ;) 2018-12-21 15:39:19 oh patchwork 2018-12-21 15:39:29 you *could* set up a mirror if you must have things in alpine quickly 2018-12-21 15:39:35 that's probably the better option 2018-12-21 15:39:41 googling "alpine patchwork" did not return the expected results 2018-12-21 15:39:44 patchwork.a.o 2018-12-21 15:39:47 however I have founda new duvet 2018-12-21 15:40:10 yeah I was trying to avoid local repos heh 2018-12-21 15:40:34 how come theres so many, just not enough reviewers/committers? 2018-12-21 15:43:12 more or less 2018-12-21 15:43:28 that and the current methodology doesn't scale very well 2018-12-21 15:43:36 oh? 2018-12-21 15:43:37 (which is why changing up the infra comes up relatively often) 2018-12-21 15:44:01 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 yeah 2018-12-21 15:44:09 applying them will take 5 sets of actions 2018-12-21 15:44:16 get patch 1, git am, repeat for 2-5 2018-12-21 15:45:13 traefik runs 2018-12-21 15:45:14 yeah 2018-12-21 15:45:25 danieli: it should do :D 2018-12-21 15:46:03 i like the attitude from it, "Built: I don't remember exactly" 2018-12-21 15:46:10 heh 2018-12-21 15:48:26 jwh, did you check if check runs any tests? 2018-12-21 15:49:18 well, it does stuff... I'm not really a go man 2018-12-21 15:49:33 ? github.com/containous/traefik [no test files] 2018-12-21 15:49:37 yea 2018-12-21 15:49:39 thats it D 2018-12-21 15:49:40 :D 2018-12-21 15:50:17 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 i think it doesnt do anything 2018-12-21 15:50:32 seems like a noop 2018-12-21 15:50:41 so its better to to explicitly mention it 2018-12-21 15:50:58 ill disable them and wrap longer lines 2018-12-21 15:51:02 "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 ah 2018-12-21 15:51:39 I'll test it 2018-12-21 15:52:04 I've tested in semi production, seems ok, but I didn't spot the test-unit target 2018-12-21 15:56:17 jwh, i pushed it. if you can find a way to properly include tests please do. 2018-12-21 15:56:32 jwh: I just did, I'll pass you a patch 2018-12-21 15:56:40 oh cool 2018-12-21 15:56:41 ok 2018-12-21 15:56:46 it does however complain at CGO 2018-12-21 15:57:02 clandmeter: i just disable it [cgo], right? 2018-12-21 15:57:21 go is a total nightmare tbh 2018-12-21 15:57:46 danieli, i dont know what goes wrong. i didnt try the tests 2018-12-21 15:58:01 the CGO thing is a different issue with PIE on alpine iirc 2018-12-21 15:58:11 it was fixed afaik? 2018-12-21 15:58:19 i think we just disabled cgo 2018-12-21 15:58:37 didnt ncopa find some issue with cgo some time ago 2018-12-21 15:58:54 for some reason the issue got resurrected recently-ish, he fixed it in docker i think 2018-12-21 15:59:07 introduced by some local change by one of our devs 2018-12-21 16:00:11 jwh: http://tpaste.us/mZqd 2018-12-21 16:00:33 runs the unit and integration tests successfully 2018-12-21 16:00:40 cool ok 2018-12-21 16:01:02 want me to add those? 2018-12-21 16:01:26 that'd probably be neat, it successfully runs all the applicable tests on my box 2018-12-21 16:06:01 it looks like shadow-4.5-r1 is in aports but r0 is in community 2018-12-21 16:06:04 can someone look into that? 2018-12-21 16:06:50 ? 2018-12-21 16:06:59 err 2018-12-21 16:07:07 that's my local, patched aports, apparently 2018-12-21 16:07:09 disregard 2018-12-21 16:07:59 i didnt see a thing 2018-12-21 16:10:04 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 go for it 2018-12-21 16:13:19 ta. btw, does anyone have/recommend an emacs mode for APKBUILD files? 2018-12-21 16:13:31 I set vim to ft=sh (shell script) 2018-12-21 16:13:32 they're just shell scrits 2018-12-21 16:13:35 scripts* 2018-12-21 16:13:47 so shell mode should be fine 2018-12-21 16:13:57 er, you know what I meant 2018-12-21 16:14:13 sh mode 2018-12-21 16:14:48 clandmeter: thanks 2018-12-21 16:15:19 just need litespeed reviewed and whatnot now then I can move my first project over :D 2018-12-21 16:15:32 and no doubt uncover other things to fix/add 2018-12-21 16:15:51 danieli: oh yes, thanks, will do that. 2018-12-21 16:16:53 jwh: looks like there have been multiple PRs for cockroach, by cockroach devs 2018-12-21 16:16:55 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 danieli: oh? 2018-12-21 16:17:14 #1183 and #2757 2018-12-21 16:17:21 I do have an issue open on cockroach and there are numerous problems 2018-12-21 16:17:24 goddarn it, not bugs, algitbot 2018-12-21 16:17:24 clandmeter: sure; tpaste? 2018-12-21 16:17:36 mort___, its our own paste service 2018-12-21 16:17:40 mort___: http://tpaste.us 2018-12-21 16:17:43 can we consider moving py-beautifulsoup and py-flask-login into community? 2018-12-21 16:17:45 apk add tpaste 2018-12-21 16:17:48 `apk add tpaste` and `cat file | tpaste` 2018-12-21 16:17:52 some are being fixed, others need more work 2018-12-21 16:17:54 ah ok, thanks! 2018-12-21 16:18:04 or redirect :) 2018-12-21 16:18:16 danieli: ah yes, thats the guy 2018-12-21 16:18:50 also, maybe, pygfm 2018-12-21 16:19:43 danieli: https://github.com/cockroachdb/cockroach/issues/32613 2018-12-21 16:19:53 I haven't had time to look at it though 2018-12-21 16:20:26 oh, they're using jemalloc 2018-12-21 16:20:30 clandmeter: http://tpaste.us/RgEr — or did you want it formatted as a patch? 2018-12-21 16:20:31 yup 2018-12-21 16:20:51 but... their binaries build and work just fien 2018-12-21 16:20:54 fine* 2018-12-21 16:20:55 mort___: as patch: git format-patch -1 --stdout | tpaste 2018-12-21 16:21:05 then we can do: curl $url | git am 2018-12-21 16:21:15 ncopa: gotcha thanks 2018-12-21 16:21:17 clandmeter: http://tpaste.us/9gPK 2018-12-21 16:21:25 oh thats convenient 2018-12-21 16:21:34 jwh: :) 2018-12-21 16:21:48 mort___: wonderful! 2018-12-21 16:21:53 clandmeter: i'll push it 2018-12-21 16:22:17 mort___: thanks! 2018-12-21 16:22:28 np, ta! 2018-12-21 16:24:15 danieli: so yeah, theres nothing I can really do for cockroach 2018-12-21 16:24:48 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 we moved it to unmaintained 2018-12-21 16:25:05 they bundle their own jemalloc 2018-12-21 16:25:20 or at least a copy is pulled, it doesn't use system jemalloc 2018-12-21 16:25:22 yeah but i believe it [jemalloc] was broken 2018-12-21 16:25:26 ah, yeah 2018-12-21 16:25:38 supposedly it was fixed at some point 2018-12-21 16:30:58 i think jemalloc failed on some archs 2018-12-21 16:31:17 and there was no pkg depending on it 2018-12-21 16:31:28 i think we prefer musl malloc 2018-12-21 16:31:37 most software seems to bundle it if they use it 2018-12-21 16:34:09 ddevault, do you want to take maintainership? 2018-12-21 16:34:54 not sure what the current status of those ports are 2018-12-21 16:37:40 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 jemalloc is pretty fast and its portable, likely why they chose it 2018-12-21 16:38:25 jwh: I think they bundle it because things like tracking/debug modes are build-time 2018-12-21 16:38:29 yeah 2018-12-21 16:38:34 not portable enough apparently 2018-12-21 16:38:36 so you can't depend on upstream having your debugging setup 2018-12-21 16:38:38 danieli: heh quie 2018-12-21 16:38:41 quite* 2018-12-21 16:39:38 there must be other packages which bundle it though, so 2018-12-21 16:39:57 I think firefox bundles their own copy 2018-12-21 16:40:04 we removed it from the deps of one or two packages and configured them not to use jemalloc 2018-12-21 16:40:17 jemalloc is in unmaintained/ atm 2018-12-21 16:40:17 or maybe they're just using it wrong and it doesn't show up on their build env 2018-12-21 16:40:29 danieli: well I mean bundled copies 2018-12-21 16:40:31 rather than deps 2018-12-21 16:40:46 even then you can often configure the software to use system malloc 2018-12-21 16:40:50 yeah 2018-12-21 16:41:09 clandmeter: sure 2018-12-21 16:41:14 they work, I use them out of testing 2018-12-21 16:41:16 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 if you depend on advanced and implementation-specific detail;s, sure 2018-12-21 16:42:33 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 yes 2018-12-21 16:45:52 jwh: try to replace jemalloc with musl malloc in your package 2018-12-21 16:46:09 nah, we're discussing something else 2018-12-21 16:46:20 ah, sorry then 2018-12-21 17:13:15 man, python 3.7 is going to require a rebuild of so many damn packages 2018-12-21 17:13:28 considering we've gone from libressl to openssl, we can get py3.7 2018-12-21 17:38:40 i dont want to do that til after v3.9 2018-12-21 17:38:46 or 3.9 will never get out 2018-12-21 17:40:45 fwiw am taking a look at smokeping atm (#8777) 2018-12-21 17:41:06 as it looked like it was on the 3.9 list (but tell me if i misinterpreted that!) 2018-12-21 17:44:04 ah, great! 2018-12-21 17:44:15 woudl be great to have that fixed before 3.9 2018-12-21 17:44:41 as you see it was on the 3.8 list too, but got postponed 2018-12-21 17:46:55 mostly builds ok, bloomin' CPAN packages giving me a pain atm 2018-12-21 17:47:34 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 danieli: was your protonmail message just a mistake, or was there something you wanted to say about acf? 2018-12-21 17:51:47 tdtrask: it was just a mistake, they mentioned it here right after sending it by accident 2018-12-21 17:53:42 ok, thanks 2018-12-21 17:56:42 mort___: im not surprised 2018-12-21 17:56:49 be glad its not ruby.... 2018-12-21 17:56:52 :) 2018-12-21 17:57:00 ! 2018-12-21 17:57:02 :) 2018-12-21 17:57:23 we used to package all the deps for redmine 2018-12-21 17:57:31 honestly. 2018-12-21 17:57:33 complete pain to maintain 2018-12-21 17:57:40 …Successfully installed Net-SSLeay-1.85 2018-12-21 17:57:40 ! Installing the dependencies failed: Module 'Mozilla::CA' is not installed, Module 'Net::SSLeay' is not installed 2018-12-21 17:57:40 ! Bailing out the installation for IO-Socket-SSL-2.060. 2018-12-21 17:57:40 Successfully installed Mozilla-CA-20180117 2018-12-21 17:58:19 do you have perl-net-ssleay in depends? 2018-12-21 17:58:35 ooh, no 2018-12-21 17:58:47 or perl-io-socket-ssl 2018-12-21 17:58:49 trying that 2018-12-21 17:59:12 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 but we are currently having issues with those 2018-12-21 17:59:34 ok plausible 2018-12-21 17:59:39 the testsuite for perl-io-socket-ssl hangs 2018-12-21 17:59:42 occationally 2018-12-21 17:59:57 this is for the thirdparty subdir in smokeping 2018-12-21 18:00:07 which installs dependent CPAN modules with `—notest` 2018-12-21 18:00:35 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 we had other perl package that also hung 2018-12-21 18:00:58 perl-net-server or similar. dont remember exactly 2018-12-21 18:00:58 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 and openssl 1.1.1 2018-12-21 18:01:17 yeah 2018-12-21 18:01:33 i grabbed some patches from fedora, that i thought would fix it 2018-12-21 18:01:46 and the tests passed in my work machine 2018-12-21 18:01:56 but some of the builders still hung 2018-12-21 18:02:20 so i have disabled the testsuite for perl-io-socket-ssl for now 2018-12-21 18:02:24 to unblock the builders 2018-12-21 18:03:34 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 clamsmtp fails on builders because source site is down 2018-12-21 18:12:56 is it ok to add source from somewhere else, debian archive for example? 2018-12-21 18:14:08 ncopa: perl-io-socket-ssl passed test in local machine with 'abuild check' 2018-12-21 18:15:34 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 procmail source is missing on the ftp://ftp.informatik.rwth-aachen.de/pub/packages/procmail/ 2018-12-21 18:22:29 its weekend for me now 2018-12-21 18:22:46 I'll be here all weekend, I don't really do holidays 2018-12-21 18:22:56 have a nice weekend everyone, and thanks for great work this week 2018-12-21 18:23:09 the holiday I celebrate is actually today, but I didn't manage to get off work ^^;; 2018-12-21 18:23:15 see you ncopa \o 2018-12-21 18:23:21 you too, take a break - you definitely deserve it ncopa 2018-12-21 18:28:41 if anyone isn't taking a well-deserved break :) smokeping upgrade builds now, but fails on install 2018-12-21 18:28:49 where do i start looking for things like 2018-12-21 18:28:49 >>> ERROR: smokeping*: Arch specific binaries found so arch must not be set to "noarch" 2018-12-21 18:28:49 >>> ERROR: smokeping*: prepare_package failed 2018-12-21 18:28:49 >>> ERROR: smokeping: rootpkg failed 2018-12-21 18:29:04 ah, arch var 2018-12-21 18:29:35 nm 2018-12-21 18:36:03 ok smokeping.2.7.3 package built ok afaics 2018-12-21 18:39:53 http://tpaste.us/zBla 2018-12-21 18:40:02 i'll try and put a proper patch in 2018-12-21 18:40:12 but will be later / over the w/e as i really ought to go home now 2018-12-21 18:54:37 ok i think that sent 2018-12-21 21:55:39 clandmeter, sec upgrade https://github.com/alpinelinux/aports/pull/5886 I bet it needs backport 2018-12-22 00:13:17 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 I don't see dqlite being worked on in your user-aports, so perhaps you hadn't noticed 2018-12-22 07:58:11 SpaceToast: we are painfully aware of it 2018-12-22 07:58:25 ok, ty :) 2018-12-22 07:58:35 I use lxd (and am planning to use clustering) in my infra, both at home and work 2018-12-22 07:58:38 so it's quite important for me 2018-12-22 07:58:48 it's a can of worms, that dqlite and patched sqlite 2018-12-22 07:58:54 aye :/ 2018-12-22 07:59:15 at least their choice of gossip alg was good :) (serf is awesome) 2018-12-22 09:32:50 gotta love lxd, even though its commandline client could use some improvements like ... return codes :) 2018-12-22 16:03:19 ncopa, I've a strange issue with latest LXC: https://dpaste.de/wZNo 2018-12-22 16:03:39 this is the APKBUILD:https://dpaste.de/wA8s/raw 2018-12-22 16:04:28 the issue is that latest LXD ships his own version of sqlite (with replication patche) and dqlite 2018-12-22 16:04:44 dqlite to be compiled needs sqlite with replication patches 2018-12-22 16:05:18 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 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 but I never seen this error before 2018-12-23 08:13:41 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 https://github.com/alpinelinux/aports/pull/5893 failed due to make: execvp: /bin/sh: Argument list too long 2018-12-23 08:47:17 how to fix this ? 2018-12-23 10:21:54 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 when i've seen that, it's the kernels ARG_MAX 2018-12-23 10:35:33 danieli: but I can build this on my host 2018-12-23 11:16:50 the CI kernel may have a smaller ARG_MAX 2018-12-23 11:20:55 that sounds plausible 2018-12-23 19:59:53 clandmeter: here is clamsmtp source fix https://patchwork.alpinelinux.org/patch/4330/ 2018-12-23 20:00:17 source url, I mean 2018-12-23 20:01:58 there are a lot of fail reports for clamsmtp on #alpine-commits 2018-12-23 20:06:52 I'm about to take off, literally. So maybe later. 2018-12-23 20:07:04 <_ikke_> o/ 2018-12-23 20:07:35 np 2018-12-23 22:56:17 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 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 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 so perhaps I've experienced this as well 2018-12-23 22:59:54 that was two days ago or so? 2018-12-23 23:00:08 no, closer to a monthish ago 2018-12-23 23:00:22 SpaceToast: do you remember where it got stuck, and how did you get it working again? 2018-12-23 23:00:38 it got stuck after printing "Caching service dependencies" 2018-12-23 23:00:47 not sure if it was on that, or on the service after that (with just no output) 2018-12-23 23:00:56 I got it working by rebooting into a rescue environment and downgrading to 3.8 :) 2018-12-23 23:01:21 (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 that did break my webmail but I didn't use it anyway 2018-12-23 23:01:32 SpaceToast: great fix ;D I see, thanks! 2018-12-23 23:01:42 no worries, good luck figuring this one out! 2018-12-23 23:02:00 thanks :) 2018-12-24 12:03:45 im am setting the v3.9 builders to continue on errors 2018-12-24 12:03:57 so we can collectd a list of packages that fails 2018-12-24 12:07:50 nice, I'd love a piece of the list to fix some stuff 2018-12-24 12:27:22 ncopa, it would be nice if we could ask algitbot the list. 2018-12-24 12:31:44 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 its sort of nontrivial 2018-12-24 12:36:01 and hackish 2018-12-24 12:36:37 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 as far as i know, we do not have anything more than rough ideas 2018-12-24 12:45:26 ncopa: some packages fails to build because of source urls are non functional, clamsmtp, procmail and possibly more 2018-12-24 12:46:23 mps: i'll write a script to check all packages in aport 2018-12-24 12:46:30 i have a feeling a couple will have broken sources 2018-12-24 12:46:49 abuild sourcecheck 2018-12-24 12:46:51 I posted one patch for clamsmtp (https://patchwork.alpinelinux.org/patch/4330/) changing source to Debian archive 2018-12-24 12:47:14 danieli: I thought to do that, also 2018-12-24 12:47:25 that may be one way to do it, but is that the official upstream? 2018-12-24 12:47:55 ncopa: no, upstream for clamsmtp is 'dead' 2018-12-24 12:48:03 ok 2018-12-24 12:48:08 where do other distros pull from, debian archive? 2018-12-24 12:48:38 i think distros generally have their own archive 2018-12-24 12:48:52 both arch and gentoo use the broken site 2018-12-24 12:48:57 danieli: well, didn't had better idea, if there are somewhere internet archive it would be preferred, ino 2018-12-24 12:49:09 it must've broken fairly recently, or nobody uses clamsmtp on those OSes 2018-12-24 12:49:12 s/ino/imo/ 2018-12-24 12:49:12 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 i guess we should store it in our own archive 2018-12-24 12:50:28 thats why i asked 2018-12-24 12:50:30 dev.alpinelinux.org/archive/ 2018-12-24 12:50:30 who has access to that, by the way? 2018-12-24 12:50:34 we store it per branch 2018-12-24 12:50:37 which breaks things 2018-12-24 12:50:41 it would be best idea to have Alpine source archive but someone have to set it 2018-12-24 12:51:20 danieli: people with git push access (i think) 2018-12-24 12:51:23 ncopa, cant we just keep distfiles on a location wtih enough space? 2018-12-24 12:51:34 and make builders prefer it? 2018-12-24 12:51:36 sounds like it's loosely coupled to that 2018-12-24 12:52:02 i dont think it makes sense to store all the files indefinitively 2018-12-24 12:52:25 at least not edge 2018-12-24 12:52:36 i dont think it makes sense to clean when you have enough space? 2018-12-24 12:52:40 distfiles.a.o vs dev.a.o? 2018-12-24 12:53:01 distfiles is a "cache" of upstreams archives 2018-12-24 12:53:19 dev.a.o/archive is storage for our own projects tarballs 2018-12-24 12:53:25 gotcha, good to know 2018-12-24 12:53:38 we also upload things there when we make git snapshots 2018-12-24 12:54:08 i rarely see references to distfiles and dev, but i come across them once in a while 2018-12-24 12:54:27 ehm, didn't know for distfiles.a.o 2018-12-24 12:54:52 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 how long files are kept there 2018-12-24 12:55:23 mps: the vX.Y/ dirs are supposed to be kept forever 2018-12-24 12:55:36 or as long as we provide the release images and binary repos 2018-12-24 12:55:37 mps: ever seen ancient.a.o referenced or mentioned? 2018-12-24 12:55:40 :') 2018-12-24 12:55:45 ncopa, currently we always bump into these issues. 2018-12-24 12:55:55 this one dir 2006-Sep-18 12:55:07 2018-12-24 12:56:05 src is gone and we need to fix it. 2018-12-24 12:56:19 ok, now I can post patches for clamsmtp and procmail with source url on distfiles.a.o 2018-12-24 12:56:24 while we could use our own cache. 2018-12-24 12:57:22 there are 2 sides of it 2018-12-24 12:57:48 one is the problem above, builder stop due to upstream is moved or gone 2018-12-24 12:57:55 sources for at least actively supported AL releases are fine, imo 2018-12-24 12:58:03 the second issue is to keep our APKBUILDs uptodate 2018-12-24 12:58:27 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 danieli: no, first time see ancient.a.o mentioned 2018-12-24 12:59:02 which is the main reason I don't point the builders to distfiles by default 2018-12-24 12:59:03 i can't think of any easy way to automatically 'detect' when upstream moves to new locations 2018-12-24 12:59:41 sounds like a hack to fix apkbuild 2018-12-24 13:00:19 danieli: it should be easy enough to check if source is there or gives 404 2018-12-24 13:00:25 but it requires some scripting 2018-12-24 13:00:33 right, detects whether it's broken or not, but not the actual new location 2018-12-24 13:00:34 and a cronjob or whatever 2018-12-24 13:00:49 i'll write a demo script to check that 2018-12-24 13:01:06 i think thats good enough, to get a list of broken upstream source URLs 2018-12-24 13:01:20 mm, i'll continue the code i started a while ago to do exactly that 2018-12-24 13:01:34 what I wonder is what we do when upstream disapears? 2018-12-24 13:01:41 what do we put in APKBUILD? 2018-12-24 13:02:03 I'd say we keep the last version that was released 2018-12-24 13:02:14 we shouldn't have to rebuild it, should we? 2018-12-24 13:02:21 even if host is gone? 2018-12-24 13:02:47 the info in APKBUILD is to tell where the upstream package is to be found 2018-12-24 13:02:57 we do rebuild ever 6 month 2018-12-24 13:03:06 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 for each stable release 2018-12-24 13:03:32 older stable releases does not need to rebuild 2018-12-24 13:03:44 and if it does, due to sec fix, then we should have it in the distfiles cache 2018-12-24 13:04:07 which is why we shouldnt remove it from distfiles/v3.x/ 2018-12-24 13:04:20 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 if the package is accepted source should be put on archive 2018-12-24 13:05:09 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 mps: that is what im thinking too 2018-12-24 13:05:41 danieli: its not uncommon that distros still ship dead packages for some time, and add sec fixes themselves 2018-12-24 13:06:02 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 even if upstream 'dies', changes license, make something bad, whatever, then there is last acceptable version to build 2018-12-24 13:06:13 and its normally possible to find patch from other distro 2018-12-24 13:06:57 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 but i'd like to keep the distfiles as a cache 2018-12-24 13:07:34 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 having archive is the safest, although that require a lot of disk space 2018-12-24 13:07:59 if we have the disk space to waste on something like this, sure, go ahead I guess 2018-12-24 13:08:42 if I have fast link and some free big disks I would, for sure 2018-12-24 13:11:27 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 s/manages to/manages to setup/ 2018-12-24 13:12:33 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 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 what's the proper way to use aports/scripts/mkimage.sh? 2018-12-25 07:49:42 always got Ignoring /media/usb/apks/aarch64/APKINDEX.tar.gz: UNTRUSTED signature 2018-12-25 10:26:24 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 i think its ok to reboot now 2018-12-26 12:01:28 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 they existed in 3.6 but afaik they weren't made reserved until 3.7 2018-12-26 21:22:19 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 they also changed some internal encoding stuff, which will be a little painful to fix on musl 2018-12-27 07:30:04 woot 2018-12-27 07:30:14 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 im working on 4.19 kernel configs 2018-12-27 08:32:45 will hopefully push those today 2018-12-27 08:49:52 clandmeter, java/armv7 fix https://git.alpinelinux.org/cgit/aports/commit/?id=66a06a28 2018-12-27 08:50:23 \o/ 2018-12-27 08:50:45 it was rather nasty to debug and find 2018-12-27 08:50:51 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 thats why we have you around, make the impossible possible :) 2018-12-27 08:51:51 _ikke_, wrong window? 2018-12-27 08:51:54 <_ikke_> yes 2018-12-27 08:51:57 :p 2018-12-27 11:56:31 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 here comes 4.19... 2018-12-27 11:57:32 choo choo 2018-12-27 12:32:12 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 those packages fails on x86 (32bit): http://tpaste.us/jXNm 2018-12-27 12:35:22 mps: i guess we get it with 9.19.13. seems like its added for stable too 2018-12-27 12:36:38 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 kunkku: ping. i think I have a problem with lxc and dad.if-up 2018-12-27 14:31:39 it hangs 2018-12-27 14:31:44 forever 2018-12-27 14:32:08 its build-edge-x86_64 on bld2.a.o 2018-12-27 15:19:14 i solved it by change the mac address 2018-12-27 15:28:23 ncopa: dad.if-up hung for me forever on 3.8 without lxc 2018-12-27 15:28:31 a pretty long time ago too 2018-12-27 15:28:42 I just disabled it at the time (was in a hurry to get network running) 2018-12-27 15:32:38 ok 2018-12-27 15:32:49 i saw there was a patch recently 2018-12-27 15:33:15 but in general, i think we should have a finite loop 2018-12-27 15:33:28 in other news, lcms test suite fails on armv7: 2018-12-27 15:33:32 Testing linear interpolation ...Error in Linear interpolation (2p): Must be i=8000, But is n=8001 2018-12-27 15:33:32 make[1]: *** [Makefile:489: check] Error 1 2018-12-27 15:35:52 off by one? 2018-12-27 15:36:58 huh?, it succeeds on my machine... 2018-12-27 15:37:10 i mean in my dev container 2018-12-27 15:38:31 ok, this is super weird... 2018-12-27 15:38:41 sounds like a true heisenbug 2018-12-27 15:38:45 off-by-one on a specific architecture 2018-12-27 15:40:42 i have more werid stuff going on: 2018-12-27 15:40:50 >>> lcms: Package is up to date 2018-12-27 15:40:50 ncopa-edge-armv7:~/aports/main/lcms$ abuild cleanpkg 2018-12-27 15:40:50 >>> lcms: Cleaning built packages... 2018-12-27 15:40:50 >>> lcms: Updating the main/armv7 repository index... 2018-12-27 15:40:50 ERROR: APKINDEX.tar.gz: UNTRUSTED signature 2018-12-27 15:41:06 it fails to update the index 2018-12-27 15:41:09 why? 2018-12-27 15:41:13 no clue 2018-12-27 15:42:21 sounds like it generates a broken signature 2018-12-27 15:46:07 that's so strange 2018-12-27 15:47:45 yup 2018-12-27 15:47:57 im considering drop armv7 for alpine 3.9 2018-12-27 15:48:11 too much weird brokeness 2018-12-27 15:49:41 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 also, would this affect rpi(0-3)? 2018-12-27 15:50:37 we stil have armhf 2018-12-27 15:51:01 so no, it shouldnt affect rpi 2018-12-27 15:51:18 except you cannot run the newer rpis as armv7 2018-12-27 15:51:38 the cortex a53 is armv8 (64bit) 2018-12-27 15:51:42 oh so you mean armv7 w/o hardware float 2018-12-27 15:51:56 no, i think its armv7hf 2018-12-27 15:52:21 danieli: yes the aarch64 work on rpi3 2018-12-27 15:52:42 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 yes, but not for alpine 2018-12-27 15:53:12 ah, how do we categorize all of this? 2018-12-27 15:53:16 for alpline armhf is armv6hf 2018-12-27 15:53:22 oh 2018-12-27 15:54:02 we did that for be able to support the early rpis 2018-12-27 15:54:36 i think we want drop support for armv6 and only support armv7 2018-12-27 15:54:37 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 er 2018-12-27 15:55:11 s/a53 armv6/a53 armv8/ 2018-12-27 15:55:11 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 right, so we may drop support for the pi1 2018-12-27 15:55:34 dropping armv6 sounds reasonable, you initially said "drop armv7 for alpine 3.9" which got me confused :) 2018-12-27 15:55:55 armv7hf is still quite widespread 2018-12-27 15:56:02 well, we currently have problems building the armv7hf 2018-12-27 15:56:10 armv7 is new for us, and it's troublesome 2018-12-27 15:56:17 so i was thinking continue with armhf only for now 2018-12-27 15:56:25 instead of armhf + armv7 2018-12-27 15:56:42 the plan was to drop the armv6 next release (3.10) 2018-12-27 15:57:21 ok i gotta go 2018-12-27 15:57:25 but if armhf is armv6hf, wouldn't that mean that we're indeed dropping armv7, and not armv6? 2018-12-27 15:57:36 well 2018-12-27 15:57:45 its more "we wait with adding support for armv7" 2018-12-27 15:57:50 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 ah, ok 2018-12-27 15:58:01 since we currently have armhf (armv6) 2018-12-27 15:58:15 and get it running on 3.10, which is when we drop v6 (hf) 2018-12-27 15:58:40 i was hoping for both v6 and v7 for alpine 3.9 2018-12-27 15:59:03 and with the release of alpine 3.9 we announce that this is the last of armv6 2018-12-27 15:59:18 so people have an overlap release where they can upgrade 2018-12-27 15:59:50 armv7 would require a reinstall from v6 (I would imagine) 2018-12-27 16:00:18 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 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 not all of world is built for armv7 2018-12-27 16:18:40 it isn't officially released 2018-12-27 16:19:16 know that, but runs fine even unofficially :) 2018-12-27 16:19:34 doesn't really change anything, unfortunately 2018-12-27 16:20:21 have it running on two SBCs without X and one chromebook with X 2018-12-27 16:21:31 if it will be dropped then I would have to build a lot of packages 2018-12-27 16:22:16 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 is there a url with list of failed builds for armv7 2018-12-27 16:22:29 there's always #alpine-commits 2018-12-27 16:22:44 i'm there 2018-12-27 16:24:08 and don't have impression that the armv7 to high on failed builds 2018-12-27 16:24:36 enough to warrant not releasing it with 3.9 2018-12-27 16:26:18 `apk search | wc -l` gives 11036 2018-12-27 16:26:45 13146 on an x86_64 edge machine 2018-12-27 16:27:06 not big difference 2018-12-27 16:27:51 oh, forgot to tell: main, community and testing 2018-12-27 16:28:54 we have a few weird issues with armv7, we need to solve those 2018-12-27 16:29:06 and there is number of packages which are excluded from armhf/armv7 2018-12-27 16:29:48 openjdk7 was big and it is solved, afaik 2018-12-27 16:30:00 yup 2018-12-27 16:30:07 main/lcms 2018-12-27 16:30:27 the testuite fails on the build server 2018-12-27 16:30:32 but not i my dev container 2018-12-27 16:30:47 ok, will try later on local machine 2018-12-27 16:31:07 i think you can try the v3.9 packages too now 2018-12-27 16:31:32 instead of edge, you mean 2018-12-27 16:31:38 yes 2018-12-27 16:31:56 majority of the packages should be built now 2018-12-27 16:32:06 ok, will try later 2018-12-27 16:32:18 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 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 yes, understand. in hour or two will try 2018-12-27 16:34:23 I have one box but with just 1GB of RAM, slow for builds 2018-12-27 16:35:34 chromebook have 4GB, fine for building most packages except few which requires a lot of RAM for building 2018-12-27 16:51:46 armv7 v3.9 testing is not uploaded yet? looked at https://nl.alpinelinux.org/alpine/v3.9/ 2018-12-27 16:53:50 Testing not ready yet i suppose 2018-12-27 16:54:23 Oh that's stable 2018-12-27 16:54:32 There is no testing in stable 2018-12-27 16:56:45 yup, testing is only in edge @ mps 2018-12-27 16:56:53 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 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 indeed 2018-12-27 16:58:02 if you mix stable and edge, be ready for abi and api mismatches and other such failures 2018-12-27 16:58:08 you can do it, but expect to have to fix it on your own 2018-12-27 16:58:11 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 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 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 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 I always have edge/testing on stable installs, tagged although 2018-12-27 16:59:52 danieli: yeah but the maintainer should do that ;) 2018-12-27 17:00:30 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 I only maintain things I use, but that also means it's like ~10 packages :) 2018-12-27 17:01:39 Same 2018-12-27 17:01:48 (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 That makes me remember, I should change a PR of mine 2018-12-27 17:46:56 ncopa: main/lcms builds fine on armv7 locally 2018-12-27 17:56:41 mps: the problem is the test 2018-12-27 17:56:44 try abuild check 2018-12-27 18:00:15 tried with 'abuild -r', doesn't it runs check, also 2018-12-27 18:00:27 fcolista: is there a specific reason we don't have qt5-qtspeech available? 2018-12-27 18:00:33 I'm working on pyside2 2018-12-27 18:01:27 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 [[sroracle]]: also passed 2018-12-27 18:04:37 odd 2018-12-27 18:05:33 btw, I noticed that some packages builds fine locally but build.a.o have promblems with them 2018-12-27 18:05:56 it might be something cpu-specific, but that sounds unlikely 2018-12-27 18:06:20 last tried community/shards on aarch64, locally works 2018-12-27 18:06:49 on which builder? 2018-12-27 18:07:19 http://build.alpinelinux.org/buildlogs/build-3-9-aarch64/community/shards/shards-0.8.1-r0.log 2018-12-27 18:07:57 i've built it locally with 'abuild' 2018-12-27 18:13:56 looks like there will be no pyside for now, qt is a bit of a disorganized mess 2018-12-27 20:16:58 ncopa, https://github.com/alpinelinux/aports/pull/5925 blocks 3.9 builders 2018-12-27 22:09:04 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 especially for fairly trivial patches 2018-12-27 22:14:45 danieli: ncopa told me few days opposite 2018-12-27 22:15:01 s/few days/few days ago/ 2018-12-27 22:15:01 mps meant to say: danieli: ncopa told me few days ago opposite 2018-12-27 22:15:03 i think i was present, i vaguel remember it 2018-12-27 22:15:09 s/vaguel/vaguely/ 2018-12-27 22:15:09 danieli meant to say: i think i was present, i vaguely remember it 2018-12-27 22:15:33 this blocks builds on armv7, and is simple patch 2018-12-27 22:15:48 armv7 isn't an immediate priority if we're delaying it until after 3.9 2018-12-27 22:17:15 don't think it is bad to fix bugs, which is irrelevant to release imo 2018-12-27 22:17:43 oh no, that's not an issue at all, don't get me wrong :) 2018-12-27 22:18:16 i meant the bugs.a.o issue 2018-12-27 22:19:01 well, I have split mind about it like you, but trying to follow core devs advice 2018-12-27 22:19:16 fair enough, the gods will decide 2018-12-27 22:19:58 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 and absolutely agree with, this doesn't deserve to be at bugs.a.o 2018-12-27 22:20:10 s/lik ethis/like this/ 2018-12-27 22:20:10 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 other idea I have is to be tiresome on #alpine-devel 2018-12-27 22:22:54 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 no, my intention is to solve bug which blocks builders 2018-12-27 22:24:35 ah. they get blocked every once in a while if they are configured to 2018-12-27 22:25:22 yes, and just trying to help where I can and have a free time 2018-12-27 22:29:38 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 and libzen is 'stuck' at builders 2018-12-27 22:30:47 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 I promise :) 2018-12-28 02:31:54 so 2018-12-28 02:31:55 textrels 2018-12-28 02:31:58 what the fuck are they 2018-12-28 02:34:21 something we can probably answer with a nicer asked question 2018-12-28 02:34:53 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 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 while you have textrels, your code isn't *TRULY* position-independent, basically 2018-12-28 02:36:21 I keep hitting that abuild linter failure when compiling nghttp2 for risc-v 2018-12-28 02:36:28 been trying to put it off but I can't avoid it 2018-12-28 02:36:37 afaict it's going to be hell to fix 2018-12-28 02:36:45 yes, yes it is. 2018-12-28 02:36:53 woo 2018-12-28 02:37:06 you may find https://wiki.gentoo.org/wiki/Hardened/Introduction_to_Position_Independent_Code useful 2018-12-28 02:37:15 thx 2018-12-28 02:37:29 no idea re: RISC-V specifics though 2018-12-28 02:37:32 so... expect hell :( 2018-12-28 02:42:23 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 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 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 the previous Fedora MIPS port hit the same issue for the same reason 2018-12-28 02:45:01 thanks sorear 2018-12-28 02:45:05 that's a useful lead 2018-12-28 02:46:21 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 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 cheers 2018-12-28 02:50:40 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 can you elaborate 2018-12-28 02:51:33 as part of each alpine release cycle, all ports have to be qualified for inclusion in the release 2018-12-28 02:52:28 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 what are the requirements for qualification? 2018-12-28 02:52:58 24x7 dedicated builder 2018-12-28 02:53:13 multiple interested alpine developers 2018-12-28 02:53:45 porting machines 2018-12-28 02:53:46 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 i assure you the build demand is larger than you believe it to be 2018-12-28 02:54:21 the slower boards have a hard time keeping up 2018-12-28 02:54:22 I doubt this one board setup scales to the demand, to be clear 2018-12-28 02:54:34 but I intend to get more boards, and SiFive already offered to provide them 2018-12-28 02:54:40 okay 2018-12-28 02:54:44 this board isn't that slow, tbh 2018-12-28 02:54:51 well 2018-12-28 02:55:00 even aarch64 struggles to keep up 2018-12-28 02:55:02 and 2018-12-28 02:55:03 especially once I set up gigabit nbd 2018-12-28 02:55:06 that is thunderx2 2018-12-28 02:55:12 soooooooo 2018-12-28 02:55:48 as for porting machines (I assume that's for maintenance of the port?) 2018-12-28 02:56:11 porting machines are so that alpine developers & maintainers can debug their packages on real hardware 2018-12-28 02:56:12 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 qemu is not acceptable 2018-12-28 02:56:31 my CI environment supports a fairly straightforward ad-hoc job submission 2018-12-28 02:56:38 CI is not acceptable 2018-12-28 02:56:45 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 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 but you're not coming off as very open to that 2018-12-28 02:57:13 there is no working through concerns 2018-12-28 02:57:18 it either qualifies or it doesn't 2018-12-28 02:58:00 all other ports in alpine have these things 2018-12-28 02:58:05 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 well, you're not getting that 2018-12-28 02:58:13 no i am not 2018-12-28 02:58:15 so if you're interested in the port let's talk about other ways 2018-12-28 02:58:31 i am saying that you need two boards 2018-12-28 02:58:38 1 for building 2018-12-28 02:58:52 1 for shell access for developers & maintainers on request 2018-12-28 02:58:59 they technically could be the same machine 2018-12-28 02:59:19 but the point is, if an alpine package maintainer has a problem with ppc64le for example 2018-12-28 02:59:25 out of curiosity, have you tried builds.sr.ht? 2018-12-28 02:59:28 they can go to whoever they are working with 2018-12-28 02:59:42 and whoever they are working with can get them a shell 2018-12-28 02:59:47 on an ppc64le machine 2018-12-28 02:59:57 a real one, not qemu emulation 2018-12-28 03:00:04 nothing beats a shell, for sure 2018-12-28 03:00:06 this is also possible for arm, aarch64 etc 2018-12-28 03:00:12 yes 2018-12-28 03:00:13 well 2018-12-28 03:00:17 that is the requirement 2018-12-28 03:00:31 directing people to a proprietary service 2018-12-28 03:00:32 but I want you to consider giving the design I have in mind a try 2018-12-28 03:00:41 sr.ht is 100% open source, LGPL+MIT 2018-12-28 03:00:47 it does not matter 2018-12-28 03:00:53 it is external to the project 2018-12-28 03:01:01 so is github, etc 2018-12-28 03:01:14 yes ,and we do not use github exclusively 2018-12-28 03:01:20 in any case, I have volunteered to be an alpine developer before, offer still stands 2018-12-28 03:01:36 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 well, that is another topic entirely 2018-12-28 03:01:49 oh, while you mention it 2018-12-28 03:02:02 ncopa: my offer still stands to take maintainership for mkinitfs 2018-12-28 03:02:22 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 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 but this is indeed a separate topic 2018-12-28 03:03:28 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 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 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 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 it doesn't matter that you have some PPA thing 2018-12-28 03:04:05 shell access can probably be arranged tbh, it just requires me to put some thought into it 2018-12-28 03:04:07 (I was going to ask once I got to it, but since it got mentioned already...) 2018-12-28 03:04:23 there are procedures already in place and we're not going to make exception for riscv 2018-12-28 03:04:37 when every other arch meets these requirements 2018-12-28 03:04:38 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 there has already been some discussion on how to improve/overhaul the alpine build infrastructure 2018-12-28 03:05:04 sure 2018-12-28 03:05:11 most alpine devs seem to be interested in builds.sr.ht as an option 2018-12-28 03:05:27 i'm not interested in it unless it is controlled by us 2018-12-28 03:05:37 well, it's open source after all 2018-12-28 03:05:41 i'd prefer to stay on the alpinelinux.org infra 2018-12-28 03:06:07 but if you want access to my boards you'll have to go through my infrastructure somehow 2018-12-28 03:06:13 ¯\_(ツ)_/¯ 2018-12-28 03:06:29 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 which brings the discussion back around to "maybe I can join the team" 2018-12-28 03:07:04 but there were also some other ideas tossed around 2018-12-28 03:07:29 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 becoming an alpine developer does not mean you get to control the master signing keys ;) 2018-12-28 03:07:51 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 I have a lot more work to do between now and then 2018-12-28 03:08:21 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 veering off-topic again, but master signing keys seems a bit weird to me 2018-12-28 03:08:31 why not a keyring 2018-12-28 03:08:51 each arch has it's own master signing keys 2018-12-28 03:08:59 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 they are in fact distributed by a keyring 2018-12-28 03:09:06 oh, well it would naturally make sense for me to maintain the riscv64 port 2018-12-28 03:09:13 sure 2018-12-28 03:09:21 so if we sign them with my key on my hardware then nbd 2018-12-28 03:10:01 anyway 2018-12-28 03:10:09 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 if you want to become an alpine developer 2018-12-28 03:10:24 i would recommend 2018-12-28 03:10:33 finishing up the riscv64 port 2018-12-28 03:10:39 that would make justification easy 2018-12-28 03:10:47 assuming you can find some other people to sign off on it 2018-12-28 03:10:48 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 turnkey is on my todo list 2018-12-28 03:11:15 but honestly the effort/reward ratio is pretty rough 2018-12-28 03:11:35 sorear: sure, and i think there's an area for "unofficial" ports, much like debian-ports.org 2018-12-28 03:11:53 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 are the requirements for a new port written up anywhere? 2018-12-28 03:12:21 writing up a wiki page is on my todo list as well 2018-12-28 03:12:28 new architectures officially supported by the distribution is a large ask of the entire community too 2018-12-28 03:12:44 because you are asking us, as package maintainers, to support your new arch 2018-12-28 03:12:45 ddevault: it's on my list to add to the dev manual 2018-12-28 03:12:51 aye 2018-12-28 03:12:56 that's why we ask for porting hw 2018-12-28 03:12:57 improving the process for package maintainers is also on my list 2018-12-28 03:13:00 what exactly they are I've no idea right now, but now I know exactly who to ask ;) 2018-12-28 03:13:17 I want to, for example, run automated builds against all arches in a nice fresh alpine installation 2018-12-28 03:13:19 SpaceToast: i just wrote what they are 2018-12-28 03:13:24 whenever a patch lands in alpine-aports 2018-12-28 03:13:28 - dedicated builder (24x7 uptime) 2018-12-28 03:13:53 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 - 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 so the loop on testing should be small and require little intervention from anyone else 2018-12-28 03:14:16 getting a shell in this environment is an interesting idea that should be possible, too 2018-12-28 03:14:19 - interested alpine developers (NOT maintainers) 2018-12-28 03:14:31 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 it's ok, I'll get to it once I'm actually writing that section. 2018-12-28 03:14:53 in fact I think I should try to make that work 2018-12-28 03:15:03 SpaceToast: there has never been a formal requirement on number of developers signing off on the port 2018-12-28 03:15:16 SpaceToast: and yes, obviously the people maintaining the port must be developers themselves 2018-12-28 03:15:18 https://todo.sr.ht/~sircmpwn/builds.sr.ht/172 2018-12-28 03:15:41 if there isn't a formal requirement, it's kind of hard to draw the line appropriately 2018-12-28 03:15:59 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 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 ok, that should be formal enough 2018-12-28 03:18:27 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 why? 2018-12-28 03:18:46 ddevault: because you could get bored and quit working on the port tomorrow 2018-12-28 03:18:59 I get paid to maintain sr.ht's infrastructure 2018-12-28 03:19:01 ddevault: meaning that new hardware will have to be found to keep the port viable etc 2018-12-28 03:19:09 and that includes RISC-V support 2018-12-28 03:19:18 that is not relevant to us 2018-12-28 03:19:32 I don't understand how the risk is different for any other alpine developer who loses interest 2018-12-28 03:19:35 you could, of course, use sr.ht to manage requisitions internally 2018-12-28 03:19:46 but the procedure must remain generic 2018-12-28 03:20:08 for alpine developers (either acting on behalf of maintainers or themselves) 2018-12-28 03:20:09 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 it would be, but 2018-12-28 03:20:39 the problem is 2018-12-28 03:20:44 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 if you have this other procedure 2018-12-28 03:20:52 then people will want it from the other archs 2018-12-28 03:20:57 who will not provide it 2018-12-28 03:21:02 why not do it for the other arches? 2018-12-28 03:21:23 because 2018-12-28 03:21:27 also, if one arch could do it better why let the others spoil the fun? 2018-12-28 03:21:29 that either locks the project into sr.ht 2018-12-28 03:21:38 (which is open source and self hostable) 2018-12-28 03:21:44 or that imposes undue burden on other archs 2018-12-28 03:22:13 but either way 2018-12-28 03:22:15 well, I'm not interested in burdening anyone with something they'll find burdensome/not useful 2018-12-28 03:22:16 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 ^^^^^^^^^^ 2018-12-28 03:22:35 99% of porting requisitions 2018-12-28 03:22:35 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 SpaceToast: sure, and cgit, hypermail, bugzilla... 2018-12-28 03:22:39 the admin contact 2018-12-28 03:22:43 just creates an lxc jail 2018-12-28 03:23:20 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 well, to put to rest the requisition issue 2018-12-28 03:23:45 in the hypothetical world where the riscv64 port is completed and I'm the maintainer 2018-12-28 03:24:00 i don't personally care how the riscv64 team handles requisitions as long as they get handled 2018-12-28 03:24:01 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 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 and they don't have to sign up 2018-12-28 03:24:10 and then if other arches find it useful 2018-12-28 03:24:12 for some special thing 2018-12-28 03:24:13 I'll help them set it up 2018-12-28 03:24:31 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 ^^^^^^^^^^^ 2018-12-28 03:25:00 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 sure, that'd be nice too 2018-12-28 03:25:17 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 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 so this stuff is getting built if alpine wants it or not 2018-12-28 03:25:39 that's all fine 2018-12-28 03:26:00 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 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 they're a little starved for boards fwiw 2018-12-28 03:26:20 "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 sorear: yeah, they're going to be rebooted very frequently with the design I'm working on 2018-12-28 03:26:42 after each build 2018-12-28 03:27:27 kaniini: I understand, and I'm saying there are ways to fix that 2018-12-28 03:27:30 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 oh yeah that's super optimistic 2018-12-28 03:27:45 so hopefully by the time that it *is* ready for inclusion, I believe they'll be better set :) 2018-12-28 03:27:50 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 I have a bunch of shit on my plate 2018-12-28 03:28:08 sorear: an actual relay, I have one here in my apartment I've been experimenting with 2018-12-28 03:28:18 I'm also going to use it possibly to disconnect the microSD card post-boot 2018-12-28 03:28:25 just get some of those 2018-12-28 03:28:28 if I can't get a kernel-based solution I'm reasonably confident in 2018-12-28 03:28:28 usb rebooter things 2018-12-28 03:28:31 that OVH has 2018-12-28 03:28:34 lolovh 2018-12-28 03:28:56 or whatever it is 2018-12-28 03:28:58 that they use 2018-12-28 03:29:12 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 i wouldn't know 2018-12-28 03:29:40 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 but I'm still a ways from that 2018-12-28 03:29:51 (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 just get 2018-12-28 03:29:59 sifive 2018-12-28 03:30:01 to put ipmi 2018-12-28 03:30:03 on their bullshit 2018-12-28 03:30:04 duh 2018-12-28 03:30:06 lol 2018-12-28 03:30:16 god 2018-12-28 03:30:20 even my thunderx2 machines 2018-12-28 03:30:22 have ipmi 2018-12-28 03:30:24 just make an open source risc-v-based ipmi that communicates through usb :^) 2018-12-28 03:30:28 even my IBM POWER8 machines 2018-12-28 03:30:29 this is literally the first commercially available risc-v hardware EVER 2018-12-28 03:30:30 have ipmi 2018-12-28 03:30:32 cut them some slack 2018-12-28 03:30:41 like ipmi blows 2018-12-28 03:30:43 but 2018-12-28 03:30:45 it works 2018-12-28 03:30:53 kaniini: except when it doesn't 2018-12-28 03:30:56 supermicro \o/ 2018-12-28 03:31:17 I might also just desolder the power button and wire it into some GPIO somewhere 2018-12-28 03:31:17 wouldn't know 2018-12-28 03:31:23 we ported openbmc 2018-12-28 03:31:26 to our supermicro boards 2018-12-28 03:31:38 life is good 2018-12-28 03:32:42 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 (until completely cutting power and restarting the entire board) 2018-12-28 03:32:55 sounds quality 2018-12-28 03:32:58 it's 10/10 2018-12-28 03:33:00 probably why we ported openbmc 2018-12-28 03:33:06 sounds about right 2018-12-28 03:33:13 actually it is not why 2018-12-28 03:33:19 we just did that to be standard 2018-12-28 03:33:22 since everything else 2018-12-28 03:33:24 is openbmc 2018-12-28 03:34:29 anyway 2018-12-28 03:34:33 beta silicon, beta cpu 2018-12-28 03:34:38 beta toolchain 2018-12-28 03:34:41 sounds fun 2018-12-28 03:34:55 fully open hardware is nice though :) 2018-12-28 03:35:21 i'll take fully working hardware over fully open hardware, it's more useful 2018-12-28 03:35:41 fwiw I haven't really had any issues with this board 2018-12-28 03:35:45 I believe the hope is that the latter merges with the former at some point 2018-12-28 03:35:55 if I could get my hands on one of those expansion boards, whoo-ee 2018-12-28 03:37:09 uptime(1) output pls 2018-12-28 03:37:24 5 days 2018-12-28 03:37:29 I don't keep any of my computers on for long 2018-12-28 03:37:36 whoo-ee you're beating fedora 2018-12-28 03:37:38 ;) 2018-12-28 03:37:58 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 is beating fedora supposed to be hard? :) 2018-12-28 03:38:22 it hasn't been working very hard though 2018-12-28 03:38:31 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 time to bust out 2018-12-28 03:38:38 prime95 2018-12-28 03:39:58 gonna go with "no" on that one 2018-12-28 03:40:05 coward 2018-12-28 03:40:12 it's not in aports and I'm lazy 2018-12-28 03:40:15 s/lazy/busy/ 2018-12-28 03:40:15 ddevault meant to say: it's not in aports and I'm busy 2018-12-28 03:40:22 excuses 2018-12-28 03:40:27 put it in aports 2018-12-28 03:40:30 it 2018-12-28 03:40:31 then I'll run it for you :) 2018-12-28 03:40:34 is non-free software 2018-12-28 03:40:38 so we can't 2018-12-28 03:40:40 oh, even better 2018-12-28 03:40:43 then I won't run it for you in any case 2018-12-28 03:40:51 just 2018-12-28 03:40:53 compile 2018-12-28 03:41:06 void main() { while (1) {}; } 2018-12-28 03:41:09 and run it 2018-12-28 03:41:13 and see how long before kpanic 2018-12-28 03:41:14 ;) 2018-12-28 03:41:24 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 uh 2018-12-28 03:41:44 Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz 2018-12-28 03:41:46 vs 2018-12-28 03:41:49 kaniini: why go through all that trouble when forkbombing exists? :) 2018-12-28 03:42:00 well 2018-12-28 03:42:03 i want to see 2018-12-28 03:42:08 how beta this silicon is 2018-12-28 03:42:08 1.5GHz riscv64 2018-12-28 03:42:13 yeah 2018-12-28 03:42:14 just do 2018-12-28 03:42:18 fwiw I've compiled gcc on this thing 2018-12-28 03:42:23 :() { :|:& }; :& 2018-12-28 03:42:23 no problems 2018-12-28 03:42:26 no 2018-12-28 03:42:26 on it 2018-12-28 03:42:49 coward 2018-12-28 03:42:54 I suspect ddevault would be more willing to run stability measurements once he has more than one board 2018-12-28 03:43:08 we don't learn anything from forkbombs 2018-12-28 03:43:13 it'll probably just crash 2018-12-28 03:43:18 no interesting numbers from that 2018-12-28 03:43:18 eh true 2018-12-28 03:43:30 i guess building gcc 2018-12-28 03:43:33 give me a real benchmark and I'll run it 2018-12-28 03:43:33 ddevault: sure there are - "how long until it crashes" 2018-12-28 03:43:35 is a decent stress test 2018-12-28 03:44:02 (this is going to be a part of qualifying riscv64 for the first time) 2018-12-28 03:44:10 what, running a forkbomb? 2018-12-28 03:44:15 no 2018-12-28 03:44:17 or benchmarking the board 2018-12-28 03:44:21 the latter seems fine to me 2018-12-28 03:44:31 proving that the port is stable 2018-12-28 03:44:36 lemme run a fresh gcc build and time it 2018-12-28 03:44:36 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 its not benchmarking 2018-12-28 03:44:46 so much as 2018-12-28 03:44:55 proving it's not going to violently explode 2018-12-28 03:45:08 sorear: source is supposedly published, but I haven't unzipped it (or whatever they use) to see 2018-12-28 03:45:15 or to put it in meme form 2018-12-28 03:45:28 riscv64 needs to be more solid than misskey 2018-12-28 03:45:31 time abuild -r 2018-12-28 03:45:36 now we wait 2018-12-28 03:45:54 i'm seriously confused as to why 2018-12-28 03:45:56 fwiw whenever I have it doing something particularly difficult 2018-12-28 03:46:00 they wouldn't have included 2018-12-28 03:46:00 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 I stick my finger next to the heatsink 2018-12-28 03:46:04 usb 2018-12-28 03:46:07 and it's always running cool 2018-12-28 03:46:13 you can overclock it but I'm not going to 2018-12-28 03:46:16 like 2018-12-28 03:46:22 why run off nbd at all 2018-12-28 03:46:27 why not just get external hdd 2018-12-28 03:46:28 and use that 2018-12-28 03:46:29 because mmc is slow as utter shit 2018-12-28 03:46:34 no 2018-12-28 03:46:34 and external hdd requires usb, sata, etc 2018-12-28 03:46:38 yes 2018-12-28 03:46:42 why dont they have that 2018-12-28 03:46:42 which isn't present 2018-12-28 03:46:44 ¯\_(ツ)_/¯ 2018-12-28 03:46:46 why do all these embedded fuckwits 2018-12-28 03:46:50 make boards 2018-12-28 03:46:54 that do not have usb or sata 2018-12-28 03:46:55 the expansion board has sata 2018-12-28 03:47:02 well 2018-12-28 03:47:03 but that's another 2 grand I don't intend to spend 2018-12-28 03:47:05 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 cannot spend* 2018-12-28 03:47:11 because they're out* 2018-12-28 03:47:11 why the fuck does it cost 2 grand 2018-12-28 03:47:14 to get sata 2018-12-28 03:47:20 "first ever", new build process, etc 2018-12-28 03:47:33 it's an FPGA that just happens to be flashed/provisioned as a hifive expansion board 2018-12-28 03:47:35 can you imagine how much today's i3 would cost around the dawn of x86? 2018-12-28 03:47:49 ddevault: this just raises even more questions 2018-12-28 03:47:58 what SpaceToast said 2018-12-28 03:48:12 I was going to use nbd anyway 2018-12-28 03:48:13 SpaceToast: except sifive 2018-12-28 03:48:21 it fits more closely with the system already used for non-riscv64 on builds.sr.ht 2018-12-28 03:48:22 SpaceToast: have extensive motivation 2018-12-28 03:48:28 and is easier to deploy updates on 2018-12-28 03:48:31 esp considering no kvm 2018-12-28 03:48:37 SpaceToast: to get hardware into the hands of devs 2018-12-28 03:48:46 SpaceToast: so making sure the hardware is viable 2018-12-28 03:48:48 kaniini: yes, that's how ddevault got his piece, after all 2018-12-28 03:48:50 the expansion boards were actually a third party thing 2018-12-28 03:48:56 SpaceToast: to be clear I paid for my board 2018-12-28 03:49:04 ddevault: this raises EVEN MORE questions 2018-12-28 03:49:06 ddevault: oh, ok, I thought that was one of the ones they offered to send in 2018-12-28 03:49:37 I imagine this gcc build is going to be I/O bound, and mmc is slow as shit 2018-12-28 03:49:40 so this benchmark might suck 2018-12-28 03:49:44 well, gcc is C++, not C 2018-12-28 03:49:46 so nevermind 2018-12-28 03:50:01 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 this isn't far from that 2018-12-28 03:50:25 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 they have a high-speed interface for plugging your FPGA into 2018-12-28 03:50:38 but also an on-board mmc and ethernet and some GPIO 2018-12-28 03:50:52 that's about it 2018-12-28 03:50:56 not even an RTC 2018-12-28 03:51:01 it's not even MMC, it's just SPI 2018-12-28 03:51:21 dear god 2018-12-28 03:51:24 that's why it's so slow 2018-12-28 03:51:41 they also stuck 8G of RAM on the board 2018-12-28 03:51:54 other than the CPU I think that's pretty much it 2018-12-28 03:52:02 that's the other thing 2018-12-28 03:52:05 why can't they just have 2018-12-28 03:52:07 ram slots 2018-12-28 03:52:12 ¯\_(ツ)_/¯ 2018-12-28 03:52:19 like this is the same bullshit 2018-12-28 03:52:20 as ARM 2018-12-28 03:52:30 at least with edgerouter you can get octeon board 2018-12-28 03:52:35 apparently nobody likes RAM slots 2018-12-28 03:52:36 just wait till you hear about the boot process 2018-12-28 03:52:36 and expand it to 16gb or more 2018-12-28 03:52:46 well surely that is just 2018-12-28 03:52:47 u-boot 2018-12-28 03:52:48 no? 2018-12-28 03:52:51 nope 2018-12-28 03:53:03 the firmware loads a partition with a magic GPT UUID into RAM and jumps to it 2018-12-28 03:53:17 the only bootloader that exists just jumps into the kernel 2018-12-28 03:53:20 no command line, no initrd 2018-12-28 03:53:30 ddevault: i am going to go back to working on getting pleroma into a packageable state now 2018-12-28 03:53:35 i have heard enough 2018-12-28 03:53:40 I'm going to have to work on the bootloader before this port is viable 2018-12-28 03:53:43 s/port/board/ 2018-12-28 03:53:44 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 kaniini: later, then 2018-12-28 03:53:48 o/ 2018-12-28 03:53:50 kaniini: are we gonna see a pleroma aport eventually then? 2018-12-28 03:53:52 that's exciting! 2018-12-28 03:53:59 SpaceToast: yes, as soon as OTP releases are ready 2018-12-28 03:54:02 nice! 2018-12-28 03:54:04 OTP? 2018-12-28 03:54:07 SpaceToast: we also need a way of configuring it 2018-12-28 03:54:09 like encryption? 2018-12-28 03:54:12 ddevault: no 2018-12-28 03:54:13 /etc? :) 2018-12-28 03:54:17 ddevault: open telephony platform 2018-12-28 03:54:29 ddevault: fancy term for "how erlang/beam works" 2018-12-28 03:54:42 is this like some PSTN shit 2018-12-28 03:54:51 ddevault: basically an "OTP release" is the technical term for compiling down to a set of binaries 2018-12-28 03:55:06 sounds like they suck at naming things 2018-12-28 03:55:31 it's an erlang thing 2018-12-28 03:55:43 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 ic 2018-12-28 03:56:35 ddevault: anyway OTP releases are kind of annoying because they are basically statically-linked binaries 2018-12-28 03:56:45 statically linked binaries are cool 2018-12-28 03:56:59 not when you want to use the system erlang packages 2018-12-28 03:57:00 ;) 2018-12-28 03:57:08 static linking is good (in most/many cases), but annoying in cases like .... kaniini beat me to it 2018-12-28 03:57:20 yeah aside from annoying distro maintainers static linking is pgreat 2018-12-28 03:57:28 I wish I had time to work on that fully static distro I was making... 2018-12-28 03:58:38 ic 2018-12-28 03:59:11 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 ddevault: contribute to stali /s 2018-12-28 03:59:42 roughly same here, though I suspect the things we want differ a bit 2018-12-28 03:59:50 ddevault: http://erlang.org/doc/design_principles/release_structure.html 2018-12-28 03:59:54 ddevault: read the manpage :D :D :D 2018-12-28 04:01:02 both projects are just a holdover until I have time to realize The Glorious Dream of Plan 9 2018-12-28 04:05:26 ddevault: so say you realize the glorious dream of plan 9 2018-12-28 04:05:52 how does that effect riscv64 arch on alpine 2018-12-28 04:06:08 the soonest I'm going to realize the glorious dream of plan 9 2018-12-28 04:06:11 is like 20 years from now 2018-12-28 04:06:14 so don't sweat it 2018-12-28 04:06:38 certainty about anything, least of all riscv64 on alpine, approaches zero on that timeline 2018-12-28 04:08:47 lol ok 2018-12-28 05:37:34 is there an exhaustive list of possible CARCH'es somewhere in abuild or aports? 2018-12-28 05:41:44 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 is functions.sh.in what you want? 2018-12-28 05:45:45 yes 2018-12-28 05:45:46 thanks. 2018-12-28 06:12:47 the libc6-compat code is incomplete and incorrect, having broken symlinks for mips and ppc64el 2018-12-28 06:13:05 and im really infurated that the fixes were attributed to be necessary for go 2018-12-28 06:13:16 because go is unrelated 2018-12-28 06:13:48 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 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 Here is the strace screenshot https://transfer.sh/fRiqk/screenshot.png 2018-12-28 14:08:48 Any ideas? 2018-12-28 14:15:41 you don't happen to have a paste rather than a screenshot? 2018-12-28 14:16:02 also, note that this is #alpine-devel, the development channel 2018-12-28 14:20:11 https://hastebin.com/yiwusewohu 2018-12-28 14:21:19 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 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 so this sounds like an xy problem - care to elaborate *why* you want to do this? 2018-12-28 14:25:20 might also be CAP_SYS_ADMIN but idk if you wanna actually use that either ;) 2018-12-28 14:32:14 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 Might this be an issue with busybox mount? 2018-12-28 14:34:58 I just tried on a different system (arch-based) with util-linux same result 2018-12-28 14:35:05 seriously though, *why* are you trying to do that? 2018-12-28 14:35:16 again, MS_MANDLOCK is full of scary race conditions on linux 2018-12-28 14:35:54 (and you still have to enable locks manually with chmod because of course you do) 2018-12-28 14:36:08 are you running into issues where your write lock isn't being honored? 2018-12-28 14:36:18 I'm actually thinking of a CTF challenge 2018-12-28 14:36:53 related to mandlock 2018-12-28 14:37:45 ah, so you want to use it *because* it's broken ;) 2018-12-28 14:37:50 yes 2018-12-28 14:38:20 well, I do believe it's against the spirit of CTF to receive outside help, so good luck :) 2018-12-28 14:38:48 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 ok, thx anyway 2018-12-28 14:51:36 Figured it out. There is kernel option for this, disabled by default in alpine vanilla. 2018-12-28 14:57:22 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 ctf even, I create and participate in them quite a lot 2018-12-28 15:23:47 TBB: setsuid can be set if you own the file 2018-12-28 15:24:18 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 ??? 2018-12-28 21:20:33 very interesting bug, informative and insightful 2018-12-28 21:23:34 indeed 2018-12-28 21:23:51 oh, he updated it 3 mins ago 2018-12-29 20:01:46 how far along is 3.9? 2018-12-29 20:05:52 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 most of it seems not to have been touched in 8-10 years 2018-12-29 22:20:27 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 i would appreciate any comments 2018-12-29 22:51:32 hatramatra: maybe builddir="$srcdir/$pkgname-$pkgver" instead of builddir="$srcdir/minidyndns-$pkgver" 2018-12-29 22:52:30 and, needn't to post tpaste url with hl=true 2018-12-29 22:52:52 mps: thanks and sorry :-) 2018-12-29 22:53:33 don't worry, just noted 2018-12-29 22:54:58 to me it looks ok, but have one quustion. shouldn't sha512sums be at the bottom of APKBUILD? 2018-12-29 22:55:03 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 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 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 although not sure about that 2018-12-29 22:58:28 and, i presume you tried to build it with 'abuild -r' 2018-12-29 22:58:56 yes, i tried ... also installed. 2018-12-29 23:00:39 happy aporting, then :) 2018-12-29 23:09:41 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 mps: and thank you! 2018-12-29 23:11:05 you are welcome 2018-12-30 09:35:17 does anyone know what happends after $pkgname-openrc is removed/purged? what if it was still running? 2018-12-30 09:36:12 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 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 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 there seems to be something called subpackage's split function, but i can't grasp how it works. 2018-12-30 09:57:34 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 yes, that idea to split package to -openrc subpackage sound as not well thought out 2018-12-30 09:59:41 why I need to have nginx-openrc if I deleted nginx? 2018-12-30 10:01:46 was it decided in the anticipation of other init/supervisor mechanisms? 2018-12-30 10:02:15 nginx nginx-openrc nginx-systemd (oh nooo!!!) :-) 2018-12-30 10:03:04 probably, but I'm not sure if that needed to go to separate packages 2018-12-30 10:05:36 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 the openrc() function is defined in /usr/bin/abuild script 2018-12-30 10:10:14 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 these are my superficial observation, didn't analyze it deeply to judge what is right solution 2018-12-30 10:12:40 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 yep, that did the trick! 2018-12-30 10:16:16 also, if i apk added just main package, it automatically installed also -openrc subpackage 2018-12-30 10:16:17 nice to know, i have to write that in my notes 2018-12-30 10:16:48 mostly, in my experience 2018-12-30 10:19:13 right, also --purge del worked just perfectly now, it stopped the service before removal 2018-12-30 10:25:46 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 i just failed captcha while creating wiki account, i'm a bloody robot! 2018-12-30 10:26:46 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 only when want to clean after i make big mess 2018-12-30 10:28:59 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 mps: do you think i should update the APKBUILD reference page in the wiki? 2018-12-30 10:59:27 hatramatra: if it is wrong it should be updated, but who should have to do that idk 2018-12-30 11:00:28 better to not have guide/info than have a wrong one 2018-12-30 11:24:44 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 i'll post email to the mailing list 2018-12-30 11:51:36 huh, you remembered me maybe is the time for me to register at Alpine wiki 2018-12-30 11:53:40 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 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 often i have to rewrite it a few times before i think it's without any ballast 2018-12-30 12:02:41 but then i hope it gets better over the time 2018-12-30 12:04:23 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 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 hatramatra: we are OT now, there is a #alpine-offtopic channel for such discussion 2018-12-31 10:52:43 ncopa: re: DAD script getting stuck 2018-12-31 10:52:50 was it the old or the new version? 2018-12-31 12:52:38 i think it was the new 2018-12-31 13:20:03 I'm stucked with lxd 2018-12-31 13:21:20 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 these libs are shipped withing lxd because are patched with cluster support 2018-12-31 13:22:14 *within 2018-12-31 13:22:39 there are basically two libs needed: 2018-12-31 13:22:47 sqlite with this "clustering" support 2018-12-31 13:22:55 dqlite (distributed sqlite) 2018-12-31 13:23:06 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 ah ok 2018-12-31 13:23:25 that was the thing you are referring 2018-12-31 13:23:41 no, I haven't figure that yet 2018-12-31 13:23:44 yeah - since it only happens to the .so one, not .so.0 or .so.0.8.6 2018-12-31 13:24:14 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 SpaceToast, we need to figure a way to hanlde this in the long term 2018-12-31 13:24:40 aye 2018-12-31 13:24:42 we can put as otions="!nostrip" and patchelf on package() 2018-12-31 13:24:47 wondering if this might work 2018-12-31 13:25:20 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 always in package() the we can do what strip() does.. 2018-12-31 13:25:44 SpaceToast, agree that is not a long term solution.. 2018-12-31 13:25:55 another solution could be to have an option that performs stripbin() before package() 2018-12-31 13:26:03 and then enforce patchelf only be called in package() 2018-12-31 13:26:12 another option is building separate sqlite specifically for lxd 2018-12-31 13:26:22 calling in sqlite-lxd() which conflicts with sqlite() 2018-12-31 13:26:25 *sqlite 2018-12-31 13:26:36 dunno why I've putted () :D 2018-12-31 13:26:57 anyway, this will make sqlite-lxd build (havin conflicts=sqlite) 2018-12-31 13:27:09 dqlite requires sqlite to build 2018-12-31 13:27:26 do you know if the lxd build process will actually detect that and avoid building the bundled one? 2018-12-31 13:27:39 if we need to patch the build system to use system libs it's a pain 2018-12-31 13:27:54 no it does not 2018-12-31 13:28:15 tbh since it uses go, it might be that it does, and I've not seen it 2018-12-31 13:28:26 I'm not acquainted with go 2018-12-31 13:32:46 fcolista: it depends on what sqlite library they are using 2018-12-31 13:33:21 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 (and people just want it to work when you `go get` the package) 2018-12-31 13:33:38 that might be the case 2018-12-31 13:36:09 fcolista: setting !strip, and calling stripbin() in package() before running patchelf (with *) fails on the linter 2018-12-31 13:36:22 for some reason the linter checks for rpath in $builddir as well 2018-12-31 13:36:39 but now I do need to go \o 2018-12-31 13:36:52 thx SpaceToast 2018-12-31 13:41:25 fcolista: stuck on dqlite? 2018-12-31 13:43:11 packages in x86 that fails to build for v3.9: http://tpaste.us/ronj 2018-12-31 13:44:42 danieli, not really 2018-12-31 13:45:10 dqlite APKBUILD is easy, but it needs "patched" sqlite to be built 2018-12-31 13:45:20 "patched" sqlite does not build 2018-12-31 13:46:49 i see 2018-12-31 13:46:50 why not 2018-12-31 13:46:52 ? 2018-12-31 13:47:41 'cause is not able to find sqlite3.h even if is there... 2018-12-31 13:47:45 ncopa: libzen fails on other archs to? 2018-12-31 13:49:43 because sha512sum is invalid. I posted patch https://patchwork.alpinelinux.org/patch/4349/ 2018-12-31 13:51:37 fcolista: https://github.com/CanonicalLtd/dqlite#build the Build part was vital for me to build it 2018-12-31 13:51:45 it uses the manifest[.uuid] files to generate sqlite3.h 2018-12-31 13:52:11 wth 2018-12-31 13:52:31 i think i told you this when we first had a look at it in #alpine-linux 2018-12-31 13:53:01 yes, but I wouldn't go ahead on that path 2018-12-31 13:53:14 having different packages built for lxd 2018-12-31 13:53:15 mps: thanks. that seems to fix it 2018-12-31 13:53:33 yeah, but it solves this part -> 14:45:20 <@fcolista> "patched" sqlite does not build 2018-12-31 13:53:53 separate package or not, the manifest files are necessary for it to build 2018-12-31 13:53:56 and dcron site is dead, I can put source from somewhere else if it is ok for you 2018-12-31 13:54:42 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 Debian archive, maybe 2018-12-31 13:57:58 dcron is moved to github, will make APKBUILD patch and post in a hour, i hope 2018-12-31 14:13:07 ncopa: here is the patch for dcron https://patchwork.alpinelinux.org/patch/4354/ 2018-12-31 14:15:10 it's new year's eve, i'm surprised it's this active 2018-12-31 14:15:46 danieli: which year ;) 2018-12-31 14:17:38 mps: is dobiousjim the new maintainer? 2018-12-31 14:19:01 i don't know, really. don't like to touch maintainer field to not offend someone 2018-12-31 14:20:40 i mean upstream maintainer 2018-12-31 14:20:52 seems he is the upstream maintainer 2018-12-31 14:21:02 the name is familiar. he used to contribute to alpine 2018-12-31 14:21:31 mps: applied it. thanks! 2018-12-31 14:26:05 yaw, now working on cloc fix 2018-12-31 14:38:30 ncopa: fix for cloc is here https://patchwork.alpinelinux.org/patch/4355/ 2018-12-31 14:39:32 mps: i thought i just pushed the fix? 2018-12-31 14:39:45 yeah 2018-12-31 14:39:48 commit 1898000c94c1b3f2909908f358e5b76040e3ad60 2018-12-31 14:39:48 Author: Natanael Copa 2018-12-31 14:39:48 Date: Mon Dec 31 13:48:54 2018 +0000 2018-12-31 14:39:48 community/cloc: update source url 2018-12-31 14:41:47 ah, ok, never mind. duplicate work 2018-12-31 14:42:31 anyway, do you have a list of packages which need fixes 2018-12-31 14:51:45 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 removed some patches (seems to have gotten fixed upstream) and bumped the version 2018-12-31 14:52:12 tests also ran, so i re-enabled them 2018-12-31 15:06:12 mps: this is for x86: http://tpaste.us/65En 2018-12-31 15:23:05 volatility fails on x86_64 also, but needs change source only 2018-12-31 15:23:28 ncopa: it would be interesting to see the output of "ip address" when the DAD script gets stuck 2018-12-31 15:24:09 is there an env where the issue can be easily reproduced? 2018-12-31 15:24:10 ncopa: should I post patch or copy-paste new url here 2018-12-31 16:01:23 ncopa: community/volatility fix is here https://patchwork.alpinelinux.org/patch/4356/ 2018-12-31 16:04:39 what is this error? 2018-12-31 16:04:39 ERROR: sqlite-lxd: builddeps failed 2018-12-31 16:05:28 neverminf 2018-12-31 16:05:32 fixed 2018-12-31 16:06:10 lol 2018-12-31 16:08:17 i got sqlite packaged 2018-12-31 16:08:52 https://dpaste.de/jv63/raw 2018-12-31 16:09:04 I've called it sqlite-lxd 2018-12-31 16:34:49 ncopa: community/wireshark fix patch is here https://patchwork.alpinelinux.org/patch/4358/ 2018-12-31 19:48:08 danieli, you around? 2018-12-31 19:53:02 https://dpaste.de/4aHY/raw 2018-12-31 20:16:13 o/ 2018-12-31 20:16:15 hello 2018-12-31 21:33:28 \o 2018-12-31 21:33:50 bah, I have too many -devel channels open, this isn't the one with recent activity