2016-11-01 08:03:02 clandmeter, can you make 3.5 builders retry doxygen package? the build fails is now fixed with downgraded flex 2016-11-01 08:03:10 i retried x86/x86_64 2016-11-01 08:03:16 if you can kick armhf and aarch64 2016-11-01 08:14:35 k 2016-11-01 08:44:22 morning 2016-11-01 08:58:04 morning ScrumpyJack ;) 2016-11-01 10:03:20 Good morning. 2016-11-01 10:58:48 good morning! 2016-11-01 11:00:02 just posted this http://patchwork.alpinelinux.org/patch/2513/, just to make sure that it is not merged before the dovecot upgrade itself, as I believe there is no backward compatibility 2016-11-01 11:24:19 kaiyou: feels like I know your nickname from somewhere else 2016-11-01 11:26:56 coredumb, same here, probably from the french nonprofit hzv or la nuitduhack? if not, then either ffdn, another french nonprofit or digicube, an IaaS provider 2016-11-01 11:27:16 way too many French people in this chan 2016-11-01 11:27:16 AH that's it 2016-11-01 11:27:19 digicube 2016-11-01 11:27:24 skarnet: clearly 2016-11-01 11:27:29 should ban them 2016-11-01 11:27:34 let's vote! 2016-11-01 11:27:40 o/ 2016-11-01 11:28:17 o/ 2016-11-01 11:31:40 \o/ 2016-11-01 11:32:21 na you can't vote twice 2016-11-01 11:32:44 lol 2016-11-01 11:32:48 frogs everyhere /o\ 2016-11-01 11:33:59 ribbit 2016-11-01 11:45:23 <^7heo> ribbit 2016-11-01 11:49:42 <_ikke_> rabbit 2016-11-01 12:15:41 cro-ak 2016-11-01 12:49:24 Hey 2016-11-01 13:56:41 Hi guys, I am still having problems running the mkimage-alpine.sh script from Docker 2016-11-01 13:57:22 For every package that gives a BAD signature error, event when using the --allow-untrusted flag, it is not installing anything from that package 2016-11-01 13:57:36 The only package that does not give an error seems to be musl 2016-11-01 13:58:50 and the musl-utils package 2016-11-01 14:04:47 m5p3nc3r: please wait a few min 2016-11-01 14:05:10 Sure 2016-11-01 14:05:21 something went wrong 2016-11-01 14:05:32 with our mirror (mistake from our side) 2016-11-01 14:11:55 So its not me going mad the :) 2016-11-01 14:12:10 s/the/then/ 2016-11-01 14:17:49 m5p3nc3r: no its me 2016-11-01 14:19:42 Any idea of an ETA for a fix? (just so I don't sit around running the script until it passes!) And thanks for your help resolving this 2016-11-01 14:20:29 m5p3nc3r: which repo do you use? 2016-11-01 14:20:51 I'm using edge (aarch64) 2016-11-01 14:21:03 sorry i mean mirror 2016-11-01 14:21:43 http://nl.alpinelinux.org/alpine/edge/main 2016-11-01 14:23:32 m5p3nc3r: try fr.a.o 2016-11-01 14:23:38 and let me know the result 2016-11-01 14:24:58 success :o) Thanks! 2016-11-01 14:58:21 m5p3nc3r, sorry for the mess. it seems the signature keys for aarch64 are broken. we are working on fixing this. 2016-11-01 15:07:39 Hey fabled - no problems, glad to see that they are being fixed 2016-11-01 15:07:53 this might take a while 2016-11-01 15:08:04 we need to figure out what to do. but finally we know what's wrong. 2016-11-01 15:08:27 it should be fixed this week. but is it today, tomorrow or later; i can't promise. it's a bit non-trivial to fix. 2016-11-01 15:15:28 sigh 2016-11-01 15:15:43 aarch64 is a headache maker 2016-11-01 23:45:41 clandmeter: fabled: yesterday I’ve downloaded ISO image for grsec virt x86_64 3.4.5 and it didn’t boot, maybe it’s related 2016-11-01 23:46:15 clandmeter: fabled: and with didn’t boot I mean that it failed to load even boot loader 2016-11-02 05:51:42 <_ikke_> jirutka: Did you verify the image? A user reported it only being 1.4M 2016-11-02 07:48:24 ncopa: you around ? 2016-11-02 07:48:43 i am 2016-11-02 07:48:51 good morning 2016-11-02 07:49:02 ncopa is not in this week 2016-11-02 07:49:34 jirutka: we only have issues with aarch64 2016-11-02 07:50:03 clandmeter: give me your email please 2016-11-02 07:50:21 clandmeter@alpinelinux.org 2016-11-02 07:50:42 nude pictures? 2016-11-02 07:51:33 clandmeter: I'm more a video person 2016-11-02 07:51:42 i have another address for those 2016-11-02 07:51:46 :p 2016-11-02 08:55:32 morning 2016-11-02 09:46:04 m5p3nc3r: around? 2016-11-02 09:46:22 I'm here - busy today, but will be online 2016-11-02 09:46:56 m5p3nc3r: we resigned all aarch64 packages 2016-11-02 09:47:08 Do you need me to test? 2016-11-02 09:47:10 we added the new key to alpine-keys 2016-11-02 09:47:39 you need to new key to trust the new index/packages 2016-11-02 09:48:12 you can copy it manually (take the key from git) 2016-11-02 09:48:30 If I rebuild the base alpine docker image, this should pull it in? 2016-11-02 09:48:36 or apk update untrusted and apk fix -u alpine-keys 2016-11-02 09:48:55 yes 2016-11-02 09:48:55 I would rather test the bootstrap case than retro-fit/ 2016-11-02 09:48:55 if you start clean it should be all working. 2016-11-02 09:48:58 But I can test both approaches if you like tho? 2016-11-02 09:49:06 no not needed 2016-11-02 09:49:17 if you test from scratch and find issues, let us know. 2016-11-02 09:49:22 Ok, will kick off the rebuild now and let you know how I get on. 2016-11-02 09:49:35 sorry for the mess 2016-11-02 09:50:53 Is this available on the nl.a.org mirror? I would like to go back to the vanilla docker mkimage-alpine.sh 2016-11-02 09:51:14 Or should I continue to use the fr.a.org one? 2016-11-02 09:51:33 it should be on all mirrors in a while 2016-11-02 09:51:45 nl syncs every hour or so. 2016-11-02 09:51:53 great. And don't worry about the mess! I appreciate your work with this :o) 2016-11-02 09:54:38 good news so far, the mkimage-alpine.sh works unmodified. 2016-11-02 10:11:37 the docker alpine builds mostly unmodified now too (just the buildmode=pie fix)- the packaging is working great 2016-11-02 10:12:02 Thanks for fixing this, should make for an great experience on aarch64 now :) 2016-11-02 12:56:26 curl release (11 CVEs) https://curl.haxx.se/changes.html#7_51_0 2016-11-02 14:13:19 clandmeter: [15:09:02] jirutka: ok, could you remove the following *.apk from v3.5? according to build logs these pkgs reported unsatisfiable constraints, but the build succeeded, so they *may* be broken; http://paste.fedoraproject.org/468141/47809569/raw/ 2016-11-02 14:13:34 fabled: ^ 2016-11-02 14:13:43 clandmeter: [15:09:53] jirutka: I don’t know what to do with pkgs without build log available :/ 2016-11-02 14:13:58 clandmeter: [15:11:05] jirutka: I fetched logs yesterdasy from http://build.alpinelinux.org/buildlogs/ and there were a lot of logs missing 2016-11-02 14:14:27 clandmeter: [15:12:50] jirutka: anyway, we can start with the list http://paste.fedoraproject.org/468141/47809569/raw/; not all of them may be really broken, sometimes only runtime deps have been missing, but it’s imo not worth to examine one by one, it’s faster to just remove them and let them rebuild, to be sure 2016-11-02 14:14:59 clandmeter, i can fix x86 and x86_64 2016-11-02 14:15:17 fabled: what do you mean with “fix”? 2016-11-02 14:15:24 delete the packages you requested :) 2016-11-02 14:15:28 aha :) 2016-11-02 14:15:57 ok ill do that same on the arm boxex 2016-11-02 14:15:58 fabled: why you can’t delete also armhf and aarch64 pkgs? they are all in one repo, aren’t they? 2016-11-02 14:16:09 jirutka, no, they are separate boxes 2016-11-02 14:16:15 that push to same rsync master 2016-11-02 14:18:28 btw there’s also a risk that pkgs depending on those which are potentially broken may be also broken, not sure how real this risk is; the problem is only (?) with builds which enables/disables features according to available libs; ofc it’s always better to force these flags in apkbuild, but not everyone is doing it :/ 2016-11-02 14:18:38 fabled: ah, right 2016-11-02 14:19:07 jirutka, on x86/x86_64 side the packages are not base libraries 2016-11-02 14:19:18 so i'm pretty sure they are okish 2016-11-02 14:19:25 in sense that not many depend on them 2016-11-02 14:19:31 fabled: okay 2016-11-02 14:20:07 fabled: any idea why some build logs are missing? 2016-11-02 14:20:17 not all packages are built yet 2016-11-02 14:20:26 but there might be something else broken too 2016-11-02 14:21:14 fabled: let me correct it; some packages that are available in http://fr.alpinelinux.org/alpine/v3.5/ don’t have build logs in http://build.alpinelinux.org/buildlogs/ 2016-11-02 14:22:03 i think i've seen that happen few times, but i'm not sure why 2016-11-02 14:22:19 i removed the packages from 3.5 x86 and x86_64 that you requested now 2016-11-02 14:22:24 i also think i fixed the 'arch' issues 2016-11-02 14:22:36 and i'm now in progress of fixing remaining build failures due to various different reasons 2016-11-02 14:22:45 e.g. source url change, latent gcc6 issues, etc. 2016-11-02 14:23:19 great! 2016-11-02 14:23:51 jirutka: you also had the virt iso issue right? 2016-11-02 14:23:56 clandmeter: yes 2016-11-02 14:24:04 should be fixed 2016-11-02 14:24:10 fabled uploaded it again 2016-11-02 14:24:17 it was only 1.5 mb? 2016-11-02 14:24:17 clandmeter: where was the problem? 2016-11-02 14:24:37 sounds like the original sync from builder to rsync master got interrupted (transient network issue?) 2016-11-02 14:24:51 aha :/ 2016-11-02 14:24:52 ncopa had an issue when he did the release 2016-11-02 14:24:56 rsync failed 2016-11-02 14:25:05 so he had to do some manual steps i believe 2016-11-02 14:25:19 we really need more reliable infra :( 2016-11-02 14:28:11 btw vpsFree also wants to develop some sane CI solution, so maybe we can find common ground :) I’m really excited, there are already a lot of idea and projects that may be beneficial both for them and us 2016-11-02 14:32:31 jirutka: pkgs deleted. 2016-11-02 14:50:28 huh 2016-11-02 14:50:37 aiccu download fails with "402 Payment required" 2016-11-02 14:50:42 it checks user-agent 2016-11-02 14:51:30 send it to /dev/null 2016-11-02 14:52:12 what? XD 2016-11-02 14:52:21 I’ve never seen this HTTP code in practice 2016-11-02 14:53:59 iperf source tarball in sf.net seems to have changed 2016-11-02 14:54:27 isn’t it available somehwere else? 2016-11-02 14:54:57 sf.net is not trustworthy 2016-11-02 14:55:33 fabled: https://iperf.fr/download/source/iperf-3.1.3-source.tar.gz 2016-11-02 14:56:20 jirutka, http://sprunge.us/IXPg 2016-11-02 14:56:35 fabled: what’s that? 2016-11-02 14:56:41 src diff 2016-11-02 14:56:54 src diff from our copy of iperf, and the one now in sf.net 2016-11-02 14:56:57 2.0.9 2016-11-02 14:57:04 same as bacula did 2016-11-02 14:57:35 fabled: 2.0.9 is pretty old, isn’t it? 2016-11-02 14:57:44 we have that for some reason 2016-11-02 14:57:55 there are 2 versions right? 2016-11-02 14:57:57 oh 2016-11-02 14:58:02 we have iperf and iperf3 2016-11-02 14:58:05 hm, no, 2.x is still maintained 2016-11-02 14:58:08 fabled: so this one https://iperf.fr/download/source/iperf-2.0.9-source.tar.gz 2016-11-02 14:58:19 iperf3/APKBUILD says pkgname=iperf 2016-11-02 14:58:23 they create conflicting names 2016-11-02 14:58:34 and i know who did that. 2016-11-02 14:58:54 ACTION hides 2016-11-02 14:59:41 fabled: hm, I really “love” this suffixed latest versions (instead of suffixing legacy versions)… how should I detect it when comparing versions from Anitya? 2016-11-02 15:00:42 jirutka, not surewhat you mean? 2016-11-02 15:01:15 clandmeter, could you fix iperf3's pkgname? 2016-11-02 15:01:25 on it 2016-11-02 15:01:32 thx 2016-11-02 15:01:49 fabled: that it’s not clear if iperf is the latest version or it’s pinned to 2.x and latest is iperf3 2016-11-02 15:02:27 ok? 2016-11-02 15:02:42 fabled: there’s currently no simple way how to reliably infer this information and it complicates checks if the pkg is up-to-date 2016-11-02 15:02:46 true 2016-11-02 15:02:52 i think it's a bit of packaging thing 2016-11-02 15:02:58 or convention in aports 2016-11-02 15:03:06 the problem is that there’s no convention 2016-11-02 15:03:11 agreed 2016-11-02 15:03:24 some pkgs uses suffix for legacy versions (like ruby2.1), tihs is the better way 2016-11-02 15:03:52 but some other packages uses suffix for latest version (like iperf3) and pkg without suffix is some arbitrary old version (like 2.x) 2016-11-02 15:03:55 it’s a mess 2016-11-02 15:06:20 :) 2016-11-02 15:06:21 yes 2016-11-02 15:06:31 it's difficult if multiple versions are needed 2016-11-02 15:06:42 should probably use version for all packages, and make the unversioned name a metapackage 2016-11-02 15:06:52 clandmeter, pkgname change broke the source file name? 2016-11-02 15:06:56 and that, ladies and gentlemen, is why fs-based packaging is best 2016-11-02 15:07:23 fabled: like adding version suffix to ALL pkgs? definitely not 2016-11-02 15:07:34 fabled: fixed 2016-11-02 15:07:43 the problem is also that sometimes the compatibility change at random times 2016-11-02 15:07:49 there's no rule 2016-11-02 15:07:59 because each upstream projects $random things 2016-11-02 15:08:23 fabled: IMO more sane rule is that pkgname without suffix is always the latest version, and use version suffix only for legacy versions 2016-11-02 15:08:41 ^ 2016-11-02 15:08:48 or have the equivalent of symlinks in apk 2016-11-02 15:08:51 then, you might need a huge dependency update when upgrading 2016-11-02 15:09:07 in order to have iperf -> iperf3, and the user can change that default if they want 2016-11-02 15:14:25 can someone abump pkgconf-1.0.2 ? 2016-11-02 15:23:36 skarnet: yeah, we need something like that for more pkgs, for example for openjdk 2016-11-02 15:23:55 skarnet: something like gentoo’s eselect 2016-11-02 15:28:16 kaniini: done 2016-11-02 15:30:12 btw I’d like to add option to setup-alpine/setup-disk to not create partitions (they are useless in VM) /basically note for myself 2016-11-02 15:32:10 jirutka: you mean VMs you recreate every time, like Docker containers? 2016-11-02 15:33:28 if a machine isn't completely ephemeral, I like to have at least 2 partitions: one ro and one rw, and put the immutable data on the ro one. If some process does something it's not supposed to, it fails. 2016-11-02 15:34:24 but if the workflow is "if the VM fails, just delete the whole thing and start over", then it's obviously unnecessary. 2016-11-02 15:35:50 skarnet: no, I mean persistent VM 2016-11-02 15:36:42 skarnet: in VM I just have more disks – LVM volumes or images on host system, so it’s useless to add partition 2016-11-02 15:37:04 I See. 2016-11-02 15:37:08 skarnet: usually I have one disk for /, one for data and one for swap 2016-11-02 15:37:24 partitions just complicates resizing 2016-11-02 15:37:41 yeah, but can you make your / ro? 2016-11-02 15:39:10 yes 2016-11-02 15:39:13 with xen it is possible 2016-11-02 15:40:24 sure, but the real question is: how to make sure the guest doesn't write to it 2016-11-02 15:43:06 skarnet: I can, but currently don’t do it 2016-11-02 16:31:06 <^7heo> https://pbs.twimg.com/media/CwRA3EcVYAA_gm8.jpg 2016-11-02 17:02:51 why the heck syslinux si not in the ISO image? 2016-11-02 18:23:57 What's the process for making a package that doesn't have prepared tarballs? 2016-11-02 18:49:35 <^7heo> what does it have? 2016-11-02 19:12:14 <_ikke_> What's more common, to start a service as nobody, or create a system user? 2016-11-02 19:22:14 _ikke_: create a system user 2016-11-02 19:24:48 <_ikke_> ok 2016-11-02 19:37:32 _ikke_: You should't run services as user nobody; if you're not careful you'll end up running multiple services as the same user (nobody) which might introduce bad synergy effects for security. 2016-11-02 19:37:50 _ikke_: So, as jirutka said, create a system user. 2016-11-02 19:41:57 16:40 < skarnet> sure, but the real question is: how to make sure the guest doesn't write to it <- Use initlets and s6. =) 2016-11-02 19:42:17 skarnet: Perhaps that's not what you ment though. 2016-11-02 19:42:48 skarnet: I guess you ment make sure that no process whatsoever in the guest tries to write to it? 2016-11-02 20:12:30 ^7heo: well, in my instance, it only has a git repository 2016-11-02 20:25:04 <_ikke_> nidan_: Yeah, I suspected so. It's just that a specific service by default used the nobody user 2016-11-02 21:04:56 _ikke_: Ah. Not nice by that service, maybe notify the developer if they don't know? 2016-11-02 21:06:55 <_ikke_> :q 2016-11-02 21:08:11 <_ikke_> Why can this init file be so minimal, it doesn't even specify the command to start? http://git.alpinelinux.org/cgit/aports/tree/main/zabbix/zabbix-server.initd 2016-11-02 22:12:44 _ikke_: isn't it taking the init file name for command if not specified ? 2016-11-02 22:25:44 nidan_: indeed, for once it wasn't a hidden (or not-so-hidden) advertisement for s6, it was a real question. Making the rootfs ro is a real and often overlooked step for a system's safety, and most installations don't make it easy (automation modifying stuff in /etc, things like that). It takes a real engineering effort to accomplish. 2016-11-02 22:50:12 agreed 2016-11-03 00:08:18 hm. It seems like there's some undocumented abuild features... specifically the "snapshot" command 2016-11-03 00:11:59 http://git.alpinelinux.org/cgit/abuild/tree/abuild.in#n2078 2016-11-03 00:12:11 this doesn't appear to be in any documents 2016-11-03 00:14:13 so, after building some own packages i see packages in the "unmaintained" which really could not be updated because of no upstream release since many years. e.g. daemontools or dhex. how can these packages go back to the "community" tree without being moved back to "unmaintained" after six month? 2016-11-03 00:14:49 tavixvi: you’re right, many features are not properly documented, this is one of them :( documentation for APKBUILD is on https://wiki.alpinelinux.org/wiki/APKBUILD_Reference, but snapshot is not described here 2016-11-03 00:16:02 hanez: unmantained doesn’t mean unmantained by upstream, but by the package maintainer 2016-11-03 00:17:05 jirutka: yes, i know. but there will be no update in alpine because of no code release within the next six month... 2016-11-03 00:17:38 hanez: yes, I’ve also argued that this metric is just wrong 2016-11-03 00:17:54 hanez: eh, wait a moment 2016-11-03 00:17:56 jirutka: hmm, okay 2016-11-03 00:17:58 ok 2016-11-03 00:18:29 hanez: I’ve kinda misunderstood the topic, so forget about the previous message 2016-11-03 00:18:59 hanez: testing repository is just for, well, testing… if the package is proven to be working, then it should be moved to the community repository (or main in same cases) 2016-11-03 00:19:46 so, should i create pull requests for packages where i just change the maintainer to myself? 2016-11-03 00:19:51 hanez: yes 2016-11-03 00:20:04 jirutka: ok. thx 2016-11-03 00:21:37 jirutka: one more question. should i move packages from "unmaintained" to "testing" before the pull request? 2016-11-03 00:22:06 hanez: you mean before moving it to community? 2016-11-03 00:23:02 jirutka: hm, just before any pull request... or leave it in "unmaintained" and send the pull request for that repo so someoneelse can move it? 2016-11-03 00:23:29 hanez: if you don’t move it, then what would that PR contain? o.O 2016-11-03 00:24:44 jirutka: ok, thanks... you're right... ;) i will move to testing before sending a pull request. how is it then moved to community afterwards... should i do it after some time using this software? 2016-11-03 00:25:13 hanez: yes 2016-11-03 00:25:32 jirutka: nice... thx for help 2016-11-03 00:25:40 HostServ: you’re welcome 2016-11-03 00:25:46 :D 2016-11-03 00:48:24 jirutka: you prefer pull requests at github or just here? 2016-11-03 00:48:33 hanez: github 2016-11-03 00:48:50 jirutka: okay 2016-11-03 01:13:16 okay. looking through some existing 2016-11-03 01:13:47 APKBUILDS, I've seen that they use _giturl instead of just giturl 2016-11-03 01:14:08 _giturl appears nowhere in the apkbuild source 2016-11-03 01:14:55 is that a deprecated use? 2016-11-03 01:18:20 tavixvi: underscore prefix is used for custom variables, these that are not defined by abuild 2016-11-03 01:18:48 tavixvi: why do you need snapshot anyway? where’s the project you’d like to package hosted? 2016-11-03 01:20:54 It's the chromium kernel. they don't release tarballs 2016-11-03 01:21:31 tavixvi: and where’s the git repo hosted? 2016-11-03 01:22:35 jirutka: https://chromium.googlesource.com/chromiumos/third_party/kernel/ 2016-11-03 01:23:14 this repo looks like dead 2016-11-03 01:23:16 for 6 years 2016-11-03 01:24:33 They update other branches 2016-11-03 01:24:49 main is just a clone of the normal kernel 2016-11-03 01:25:00 which branches? 2016-11-03 01:25:08 there are a lot of them 2016-11-03 01:26:28 anway, you can simply get tarball for specific commit, for example https://chromium.googlesource.com/chromiumos/third_party/kernel/+archive/f1a4923435a50fcc4de68c2d1ae7058de95d6afe.tar.gz 2016-11-03 01:26:35 so no need to use snapshot feature at all 2016-11-03 01:30:08 The wiki said something about not using that. 2016-11-03 01:30:12 https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package 2016-11-03 01:30:53 "Some projects didn't provide a release tarball. If you point source to an tarball provided by a git web interface (gitweg, cgit, github), such as:" ... "You will run into issues because the checksum changes when downloading on the build system." 2016-11-03 01:32:16 this is not true 2016-11-03 01:32:26 *shrug* 2016-11-03 01:32:41 the problem is when you point to a branch, then you will get different tarball once new commits are added 2016-11-03 01:33:40 but when you point to the specific tag or commit, then you should always get the same tarball; this is certainly true for GitHub, but not sure about that google stuff 2016-11-03 01:35:07 even GitLab provides stable tarballs 2016-11-03 01:35:32 google isn't exactly concerned with distributing their source 2016-11-03 01:36:49 i know 2016-11-03 01:36:57 google projects are usually total crap 2016-11-03 01:37:14 then often even don’t bother to properly make releases 2016-11-03 01:37:38 Wouldn't it be better to point it at a branch rather than a commit? I'm kinda new to packaging things 2016-11-03 01:38:00 definitely not, then you’ll get the exact problem as described on wiki 2016-11-03 01:38:27 Not if I used abuild snapshot, right? 2016-11-03 01:38:33 you must point to a specific commit, using its SHA1 checksum or tag 2016-11-03 01:38:49 using abuild snapshot is probably unnecessary in this case 2016-11-03 01:39:20 let’s try download some tarball from them, download the same one tomorrow and compare if it’s the same 2016-11-03 01:39:59 to get up-to-date patches with targeting a commit, wouldn't you have to manually update the package? 2016-11-03 01:43:55 i’ve fixed that point on the wiki page 2016-11-03 01:44:03 tavixvi: yes 2016-11-03 01:44:19 tavixvi: and you a date in format YYYYMMDD as a pkgver 2016-11-03 01:46:40 sounds like more work than just running abuild checkout to update 2016-11-03 01:48:01 there’s no any abuild checkout command 2016-11-03 01:48:44 **snapshot 2016-11-03 01:48:45 version must be fixed and bumped by the package maintainer when needed 2016-11-03 01:49:18 snapshots are not for free, we must store them on our servers 2016-11-03 01:49:40 moreover, every package must have version number 2016-11-03 01:49:51 so it does not simplify anything for you 2016-11-03 01:50:11 i must go sleep 2016-11-03 11:19:51 <^7heo> Are licenses GPLv2 or GPL2? 2016-11-03 11:21:56 <_ikke_> GPL2 2016-11-03 11:22:49 <^7heo> _ikke_: no really. 2016-11-03 11:22:54 <^7heo> _ikke_: check the repo. 2016-11-03 11:23:35 <^7heo> We have 2/3 GPL2 and 1/3 GPLv2 2016-11-03 11:23:37 GPL 4 U, U LIKE it 2 2016-11-03 11:24:12 <^7heo> it's not obviously appearant 2016-11-03 11:24:14 <^7heo> appearent* 2016-11-03 11:24:22 apparent. 2016-11-03 11:25:01 <^7heo> damn 2016-11-03 11:25:03 <^7heo> thanks skarnet 2016-11-03 11:25:14 but now that you mention it, pears... 2016-11-03 11:25:29 <_ikke_> ^7heo: According to the wiki it should be GPL2 2016-11-03 11:25:38 <^7heo> _ikke_: valid point. 2016-11-03 11:25:45 <^7heo> maybe we should uniformize that. 2016-11-03 11:26:59 I'm having trouble with busybox sh. It's the second time this year that it arbitrarily and randomly won't process ${foobar##prefix}. 2016-11-03 11:27:25 I'm getting ${foobar}, with the prefix still there. 2016-11-03 11:28:09 What's insane is that it's reproducible... in a given script. When I copy the script to another place, the bug doesn't trigger. 2016-11-03 11:28:27 I gave up trying to understand the first time it appeared. 2016-11-03 11:28:30 (mmm... pears.) 2016-11-03 11:29:14 But now that the bug rose its ugly head again... I'm scared. 2016-11-03 11:29:31 I think I'll just ln -sf bash /bin/sh for my builds. :/ 2016-11-03 11:29:56 <^7heo> skarnet: any relation to the file name? 2016-11-03 11:30:12 the file name is always "configure". XD 2016-11-03 11:30:47 <^7heo> path? 2016-11-03 11:31:34 path is certainly an element. The exact same configure script called with the same arguments triggers the bug in s6 but not in s6-dns, for instance. 2016-11-03 11:33:06 I spent a lot of time earlier this year trying to figure out what was going on, to no avail. I chalked it up to edge tbh - it went away when I threw edge out the window and went to regular 3.4. But here it came up again, on the latest 3.4. 2016-11-03 11:34:23 <^7heo> why are most developers retards? 2016-11-03 11:35:06 because the ecosystem does not punish retardation 2016-11-03 11:35:19 <^7heo> Valid point. 2016-11-03 11:35:42 they made an entire ecosystem just for them. 2016-11-03 11:36:10 it starts with a G and and with an o 2016-11-03 11:36:36 gtfo! 2016-11-03 11:37:44 <^7heo> skarnet: I am with clandmeter on that one. 2016-11-03 11:39:18 whoosh 2016-11-03 11:40:07 <^7heo> I mean 2016-11-03 11:40:17 <^7heo> Google is the perfect example of cleverness gone wrong. 2016-11-03 11:40:38 <^7heo> And Go its perfect implementation proof. 2016-11-03 11:41:08 <^7heo> Google is a bunch of clever people hiring less clever people because the market has a shortage... 2016-11-03 11:41:15 <^7heo> ...recursively until retardiness. 2016-11-03 11:41:23 no, that's wrong. 2016-11-03 11:41:25 <^7heo> \o/ 2016-11-03 11:41:36 <^7heo> I'm not including you in the retards 2016-11-03 11:41:38 <^7heo> Just so you know. 2016-11-03 11:41:52 I know you aren't, but what you said is still wrong. 2016-11-03 11:42:07 -> offtopic 2016-11-03 11:42:10 <^7heo> myeah 2016-11-03 11:57:10 yup, my build works with sh = bash. 2016-11-03 12:01:13 <^7heo> skarnet: you mean, if you install GNU bash and symlink it from /bin/sh? 2016-11-03 12:01:21 yes. 2016-11-03 12:01:42 <^7heo> I don't use that {var#subst} syntax 2016-11-03 12:01:45 <^7heo> so I wouldn't know. 2016-11-03 12:01:46 (and I know it's not on the scripts, which are pure POSIX sh) 2016-11-03 12:02:04 <^7heo> wait, {var#subst} isn't POSIX, is it? 2016-11-03 12:02:42 it is. 2016-11-03 12:03:05 #, ##, %, %% are all posix variable expansions. 2016-11-03 12:04:14 http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_02 2016-11-03 12:09:41 Hi, I am trying to make a clean build from https://dpaste.de/wzgc/raw and the abuild -r output is https://dpaste.de/s6BW/raw 2016-11-03 12:09:42 can someone hint mee where this ">>> WARNING: singularity*: Redundant /usr/lib in rpath found" comes from ? 2016-11-03 12:10:05 <^7heo> skarnet: interesting 2016-11-03 12:10:12 <^7heo> skarnet: thanks for the link :) 2016-11-03 12:44:05 How come only the linux packages use cpio in their APKBUILD, and no packages use cp --parents? =) --parents isn't supported by busybox's cp, that might be a reason. I have a strong urge to using either one or the other, is there a specific reason for not using cpio? 2016-11-03 12:53:01 hm, dummy question, but: what is the usual process for package upgrades? are the patches merged immediately? is the build tested first? is there a separate reviewer that checks the checksums for security? 2016-11-03 12:54:46 kaiyou: if you submit patches to github, travis-ci will test build it. 2016-11-03 12:55:20 patches to the ML will only be test build be the dev with commit access. 2016-11-03 12:55:40 I submitted them to the ML, so thanks for the reply (: 2016-11-03 12:56:31 kaiyou: there is more activity on github, patches on the ML tend to take longer. 2016-11-03 13:02:58 thanks, I did not know and blindly followed the wiki :D 2016-11-03 13:03:05 for next patches I will post to Github! 2016-11-03 13:04:29 kaiyou: I'd appreciate if you pm:ed a micro-howto on that... =) 2016-11-03 13:04:31 the wiki needs reformating regarding this topic. (i did add some lines saying we allow github but its less clear). 2016-11-03 13:14:37 <^7heo> How do people maintain stuff that uses autohell? 2016-11-03 13:14:42 <^7heo> Seriously... 2016-11-03 13:16:11 ^7heo: +1 2016-11-03 14:58:44 jirutka: saw your notification about the bug of salt in lxd 2016-11-03 14:59:43 not sure what I can do about it, as the reporter says it's nothing to do with the salt package but the fact that the container lacks /dev/shm 2016-11-03 15:27:02 mkdir /dev/shm 2016-11-03 15:27:10 you're welcome 2016-11-03 15:27:38 \o/ 2016-11-03 15:27:56 but /dev/shm must be a tmpfs 2016-11-03 15:28:10 it will be the case 2016-11-03 15:28:14 and I have no idea what lxd is doing there 2016-11-03 15:28:16 if /dev is a devtmpfs 2016-11-03 15:28:40 skarnet: are you sure it must not be a separated one ? 2016-11-03 15:29:03 for art and purity, it should be 2016-11-03 15:29:06 but nobody cares 2016-11-03 15:29:26 ah... so if nobody cares :D 2016-11-03 15:30:22 i do, just because i can! 2016-11-03 15:30:37 if you prefer, you can mkdir /run/shm and ln -s /run/shm /dev/shm 2016-11-03 15:30:41 ACTION switches back to idle mode  2016-11-03 15:30:43 that's marginally cleaner 2016-11-03 15:31:11 I prefer nothing I have no issue :D 2016-11-03 15:31:22 i envy you 2016-11-03 15:32:41 I ran a dump restore on my new pgsql instance this morning and it's still running 2016-11-03 15:32:49 so I just look at it running 2016-11-03 15:32:52 no issue 2016-11-03 15:33:00 just waiting 2016-11-03 15:33:02 \o/ 2016-11-03 15:33:14 and its almost weekend! 2016-11-03 16:00:30 <_ikke_> For me it's weekend 2016-11-03 16:01:01 en ik maar werken... 2016-11-03 16:03:56 clandmeter: why do you insist on writing Dutch today? 2016-11-03 16:05:37 its dutch in your face day today. 2016-11-03 16:15:48 ncopa: https://bugs.alpinelinux.org/issues/6370#note-6 2016-11-03 16:15:55 fabled: https://bugs.alpinelinux.org/issues/6370#note-6 2016-11-03 16:31:32 could somebody review/apply http://patchwork.alpinelinux.org/patch/2515/ 2016-11-03 16:38:12 revised (prepend CVE- in commit message) http://patchwork.alpinelinux.org/patch/2516/ 2016-11-03 16:45:28 ScrumpyJack: did you get acme-client after ncopa's fix? 2016-11-03 16:45:35 *check 2016-11-03 18:07:52 what's the best way to create a python package nowadays? If the package supports both python2 and python3 it should have a py3- and py2- subpackage, right? 2016-11-03 18:08:01 If so: We might want to update the python newapkbuild template to reflect that 2016-11-03 20:34:28 What do you guys use for arm compilation? Does abuild support cross-compilation? 2016-11-03 21:11:09 tavixvi: I wish it would, but atm it doesn't. They have powerful arm builders for compilation: https://twitter.com/clandmeter/status/776068182574596098 2016-11-03 21:49:07 tavixvi, skarnet : there is limited cross-compilation support for bootstrapping. hopefully we get better cross-compile support in future. 2016-11-03 22:30:15 coredumb: sorry, I must admit that I didn’t read the issue, no time at that moment, I just saw salt, so Ijve notified you 2016-11-03 22:31:05 coredumb: I’ve added /dev/shm to Alpine template in LXC quite recently; but not sure if LSD… or LXD or how is that… use these templates or something else 2016-11-03 22:32:21 skarnet: “[12:35:06] skarnet: because the ecosystem does not punish retardation” … very true 2016-11-03 22:32:59 “[12:36:09] clandmeter: it starts with a G and and with an o” … totally agree! 2016-11-03 22:40:29 jirutka: no problem I like to know that ppl use my packages in the end ;) 2016-11-03 22:47:50 skarnet: the correct solution is to mount tmpfs at /dev/shm from the lxc config, not these hacks you’ve suggested… 2016-11-03 22:49:35 actually, what I suggested are not hacks, they're exact solutions to the problem 2016-11-03 22:49:57 your suggestion is also a solution, but a more costly one: it creates one additional, spurious tmpfs instance 2016-11-03 22:50:00 nmeum: https://wiki.alpinelinux.org/wiki/APKBUILD_examples:Python 2016-11-03 22:54:56 so much debate 2016-11-03 22:55:00 not enough eer 2016-11-03 22:55:06 beer* 2016-11-03 22:55:13 what can we do ? 2016-11-03 22:55:39 drink some more yeah \o/ 2016-11-03 22:56:50 coredumb: I had just wine and something I don’t remember how is named, from Netherlands IIRC 2016-11-03 22:57:06 ^^ 2016-11-03 23:00:02 coredumb: I should not mix them probably, not feeling good now 2016-11-03 23:00:56 if the thing from the Netherlands spoke to you, it's totally understandable 2016-11-03 23:01:14 skarnet: it does not XD 2016-11-03 23:12:16 So I set up qemu-user to chroot into an arm root.... seems to be working 2016-11-03 23:16:25 hey guys, opened this issue a while ago 'cause I've no idea how to properly fix it on my own... https://bugs.alpinelinux.org/issues/6379 2016-11-03 23:16:56 is it expected that you take ownership of your own issues and inform someone about it in addition to creating it on the tracker? or have I done my part :( 2016-11-03 23:18:25 trfl: are you sure that it’s an alpine issue? because this looks more like a kernel issue 2016-11-03 23:18:39 that's the thing, I have no idea what I've bumped into :p 2016-11-03 23:18:51 all I know it started happening when applying grsec to the latest alpine kernel 2016-11-03 23:19:12 trfl: have you started from the alpine grsec kernel? 2016-11-03 23:19:28 trfl: … modifying the config 2016-11-03 23:20:41 sort of... back on kernel 4.4.19 with the same abuild file and all, except I replaced the config with an all-no config and enabled just the stuff I needed 2016-11-03 23:20:52 it worked fine for 4.4.19 and 4.4.20 but broke when we bumped to 4.4.26 2016-11-03 23:21:15 so yeah the alpine-grsec with only customization being the kconfig 2016-11-03 23:21:31 so you probably custmozied it wrong o.O 2016-11-03 23:21:31 dunno 2016-11-03 23:21:41 well it worked fine for the first two versions :/ 2016-11-03 23:22:12 the official alpine-grsec kconfig didn't change at all since 4.4.19, so I haven't missed out on any mandatory flags or anything 2016-11-03 23:24:43 sorry, I need to go sleep now 2016-11-03 23:24:50 no worries, sounds familiar hehe 2016-11-04 00:35:46 <__errm__> So there are some vuns in curl … https://curl.haxx.se/docs/vuln-7.50.3.html what is the procedure for dealing with stuff like this… just submit a patch, or do these things need to be logged somewhere in a ticketing system? 2016-11-04 00:50:33 __errm__: there's a patch pending (2516) for curl-7.51.0. 2016-11-04 00:50:42 <__errm__> oh ok 2016-11-04 00:50:44 <__errm__> cool 2016-11-04 00:52:03 <__errm__> is there a way to see what patches are pending … I am on the alpine-devel email list but didn’t see anything ... 2016-11-04 00:53:11 two different places: patchwork.alpinelinux.org or pull requests at github.com/alpinelinux/aports 2016-11-04 00:54:12 also, you'd want to be on the alpine-devel mailing list 2016-11-04 00:54:18 alpine-aports* 2016-11-04 00:54:42 <__errm__> right I see alpine-aports get patches ... 2016-11-04 00:54:48 <__errm__> thanks 2016-11-04 08:20:04 morning. happy friday! 2016-11-04 08:21:23 morning o/ 2016-11-04 11:46:49 fun fun fun 2016-11-04 12:24:50 anybody here from autstralia? 2016-11-04 20:29:12 Hmm… I see an APKGBUILD failing with: /usr/bin/abuild: line 1: update_config_guess: not found 2016-11-04 20:29:40 theres also a update_config_guess || return 1 in the prepare() function … and I wonder what update_config_guess could be 2016-11-04 20:31:23 jomat: this updates config.guess file from authells with latest version 2016-11-04 20:31:35 should've been update_config_sub ? 2016-11-04 20:31:47 oh 2016-11-04 20:31:54 maybe your abuild is just too old 2016-11-04 20:32:39 fabled: no, there are both update_config_guess and update_config_sub 2016-11-04 20:32:50 abuild 2.27.1 2016-11-04 20:32:53 fabled: or at least they used to be 2016-11-04 20:33:08 and still are 2016-11-04 20:33:31 see https://github.com/alpinelinux/abuild/blob/master/abuild.in#L506-L539 2016-11-04 22:06:43 jomat: you are use 3.4 install with master branch of aports? 2016-11-04 22:07:38 update_config_guess has been introduced after 3.4 has branched. 2016-11-04 22:08:29 yes, current master branch and 3.4 main as default pkg repo 2016-11-04 22:08:46 then you are playing with fire :) 2016-11-04 22:10:47 clandmeter: IMO we should explicitly mention on wiki that users should create packages on edge system 2016-11-04 22:11:01 clandmeter: even skarnet didn’t know that 2016-11-04 22:11:14 alright :-) good to know 2016-11-04 22:11:34 jirutka: right 2016-11-04 22:11:51 clandmeter: hmm, maybe we can also add some simple script that would install alpine edge in chroot (this should be good enough for making pkgs), to make it easy 2016-11-04 22:12:09 honestly I thought that was what abuild did 2016-11-04 22:12:26 skarnet: can you tell me how can abuild did it? 2016-11-04 22:12:30 because abuild -r works even when I don't have the dependencies installed 2016-11-04 22:12:42 -r installs dependencies 2016-11-04 22:12:44 skarnet: of course, but it installs these dependencies in your system 2016-11-04 22:12:54 and removes them again with the default settings 2016-11-04 22:12:56 on the system? and removes them afterwards? 2016-11-04 22:13:00 yes 2016-11-04 22:13:01 depends if they are available 2016-11-04 22:13:05 THIS IS INSANE 2016-11-04 22:13:07 skarnet: what did you think? that it somehow magically installs edge in some namespace? 2016-11-04 22:13:15 jirutka: yes, it should 2016-11-04 22:13:22 CLEANUP="srcdir pkgdir deps" 2016-11-04 22:13:23 skarnet: no, this is not insane, insane is to use it on your production system 2016-11-04 22:13:29 yes 2016-11-04 22:13:37 that means you can't build packages on a production system 2016-11-04 22:13:49 skarnet: ofc you should not 2016-11-04 22:13:53 what do you call a system that is designed to build packages? 2016-11-04 22:13:56 skarnet: alpine is not gentoo 2016-11-04 22:14:23 skarnet: abuild is simple tool, it’s not and should not be responsibility of abuild to build a container 2016-11-04 22:14:39 I can agree with that 2016-11-04 22:14:52 skarnet: I’m quite shocked that you didn’t know how it works 2016-11-04 22:14:55 but then it should be made extremely clear that abuild heavily modifies the system it's run on 2016-11-04 22:15:07 I read all the doc pages and I don't remember seeing that 2016-11-04 22:15:17 skarnet: it was very clear for me since beginning… 2016-11-04 22:15:36 probably because you didn't have as high expectations as I did :P 2016-11-04 22:15:42 and its no problem to build on your system 2016-11-04 22:15:52 just checkout stable branch 2016-11-04 22:15:56 :) 2016-11-04 22:16:47 but really, we don't need a container... a chroot with an edge package database would be enough 2016-11-04 22:17:00 docker! 2016-11-04 22:17:17 please, I'd like to keep jirutka alive for a couple more years 2016-11-04 22:17:56 clandmeter: what the heck did you just said?! 2016-11-04 22:18:14 who me? 2016-11-04 22:18:18 yes 2016-11-04 22:18:20 that was ncopa 2016-11-04 22:18:23 jirutka: it's nothing, it's nothing, sit down, it's all gonna be okay 2016-11-04 22:18:26 :p 2016-11-04 22:18:41 clandmeter: ncopa is on business trip or something like that ;) 2016-11-04 22:18:58 skarnet: you haven’t made many packages, did you? 2016-11-04 22:19:02 iirc he's got a well-deserved vacation 2016-11-04 22:19:57 jirutka: maybe you can add your logic of travis to abuild 2016-11-04 22:20:12 jirutka: nope, I only packaged my own software, and since it's awesomely clean with no external dependencies, I didn't mess up my system :P 2016-11-04 22:20:13 never looked at it though 2016-11-04 22:20:18 skarnet: if abuild would create some ephemeral “container” (chroot or anything like that) in background when you build a package, it would actually complicates many things 2016-11-04 22:20:31 of course it would, I'm not suggesting that 2016-11-04 22:20:49 what I am suggesting, however, is a higher-level set of tools 2016-11-04 22:21:00 skarnet: your idea would just bring more magic into abuild, I’m quite surprised that *you* are suggesting that 2016-11-04 22:21:02 that set up an edge development environment 2016-11-04 22:21:08 and calls abuild inside 2016-11-04 22:21:09 skarnet: I agree on that 2016-11-04 22:21:35 skarnet: I’ve suggested some script that would install alpine edge in chroot with pkgs needed for building pkgs :P 2016-11-04 22:22:07 see? stop putting words in my mouth and ideas in my head, and you'll notice I agree with you much more than you think :P 2016-11-04 22:23:27 :P 2016-11-04 22:23:46 of course it may be just as simple to whip up another VM with edge... 2016-11-04 22:24:31 but when the compiler on edge is broken, which happened not even 2 months ago, or when the shell on edge is broken, which happened last summer, or... 2016-11-04 22:24:36 skarnet: actually your software have many dependencies… on your another software :P I’ve already complined about that :) 2016-11-04 22:25:10 yes, I said no _external_ dependencies, which is the important thing 2016-11-04 22:25:13 skarnet: well, I use LXC, so I have container that I use just for building pkgs, nothing else, so I don’t care if I mess it up 2016-11-04 22:25:49 skarnet: I would never run it on production system… eh… well… actually I run it on production machine, but not on the same system :P 2016-11-04 22:26:32 my point is that if something basic enough breaks on edge, you can't even get to the point where you're able to actually build packages 2016-11-04 22:26:40 and that would be bad 2016-11-04 22:26:54 skarnet: ad ncopa: he will have very deserved vacation since next week iirc 2016-11-04 22:27:22 oh, it's next week? then he's having a well-deserved week-end :P 2016-11-04 22:29:44 yeah 2016-11-04 22:30:04 skarnet: https://github.com/alpinelinux/abuild/blob/master/buildlab.in 2016-11-04 22:31:11 clandmeter: cool! what's the status on this, is it usable? 2016-11-04 22:31:26 I have no idea :) 2016-11-04 22:31:28 clandmeter: cool, so we already have such script! didn’t know about it 2016-11-04 22:31:39 jirutka: sure you do 2016-11-04 22:31:54 looks at the last commiter ;-) 2016-11-04 22:32:22 the examples mention nenolod 2016-11-04 22:32:22 clandmeter: I’ve mass modified all the scripts in this repo, I haven’t read what is this script for ;) 2016-11-04 22:33:05 i think its very old 2016-11-04 22:33:14 kaniini made it long time ago iirc 2016-11-04 22:33:52 clandmeter: actually I just wanted to fix some bug in setup-dns script and horrified from mixed tabs & spaces, so before that I fixed them and also improved some things, and then fixed that single line bug :P 2016-11-04 22:34:11 if the examples have "nenolod" in them, then yes, it was a *long* time ago :) 2016-11-04 22:34:35 what’s nenolod? 2016-11-04 22:34:43 kaniini's old nick 2016-11-04 22:35:04 aha 2016-11-05 03:11:04 skarnet: buildlab likely needs updates, but it depends on cowdancer which was broken on musl so i quit working on ity 2016-11-05 03:11:06 -y 2016-11-05 12:56:53 kaniini: do you use gammu? 2016-11-05 14:00:22 Alpine stickers are on another conference, this time on OpenAlt in Brno, Czech Republic https://twitter.com/vpsfree_cz/status/794829347203010560 :) 2016-11-05 14:22:44 \o/ 2016-11-05 15:16:37 ScrumpyJack: no idea what that is 2016-11-05 15:31:03 jirutka: thanks for moving neovim to community (and mostly for fixing lua-mpack) 2016-11-05 17:18:34 Yesterday I learned building packages on 3.4 instead of edge is playing with fire… today I upgraded my build env (gcc 5.3.0-r0 -> 6.2.1-r1) and my build fails with stuff like "stack-protector enabled but compiler support broken" - see also https://0.jmt.gr/?3fe25a39e0273ec2#ISEzadhmd9bswhFaFFV+PgvjpR8lOD1AwYPrjrR09vI= 2016-11-05 18:24:05 Ah: http://lists.alpinelinux.org/alpine-devel/5480.html 2016-11-05 20:28:27 You know your project is becoming too complex when people are starting shell scripting coding style discussions in your mailing-list 2016-11-05 20:28:57 everning everyone (: 2016-11-05 20:28:59 Having an issue with the latest Dovecot package and the antispam plugin due to ABI changes, could anyone trigger a build of dovecot-antispam-plugin? 2016-11-05 21:02:03 kaiyou, done 2016-11-05 21:15:17 thanks a lot fabled, do you know how long it should take to build and push? 2016-11-05 21:44:05 oh, it's available already, thank you again 2016-11-05 23:36:47 I decided to post the mkinitfs updates to the list, hope that's ok. Have some vacation coming up and I'm not going to find time to learn how to create github pull requests before that. 2016-11-05 23:51:05 nidan_: thats fine. 2016-11-05 23:51:14 there is no ci for mkinitfs repo 2016-11-05 23:52:39 and creating pr's are very easy, fork repo, create feature branch, push changes, create pr (should now show in your github repo) 2016-11-06 07:02:22 clandmeter: Thanks, I'll save that. I don't have a machine set up for development where I can access github so I have to fix that first. 2016-11-06 07:02:51 clandmeter: What does the abbrevation "ci" mean? 2016-11-06 07:07:02 clandmeter: If there is a reply, pm please, I'll be afk for some time. 2016-11-06 11:12:00 nidan_: https://travis-ci.org 2016-11-06 12:06:38 someone with c skills around? 2016-11-06 12:08:15 nidan_: continuous integration 2016-11-06 13:18:45 _ikke_: hey. darktable 2.2.0 rc0 is out :) time to package 2016-11-06 13:48:19 <_ikke_> LebedevRI: thanks for the heads-up 2016-11-06 13:48:41 any other distros that use musl libc that i could ping? 2016-11-06 13:49:33 <_ikke_> I'm not aware 2016-11-06 13:51:47 LebedevRI: Void Linux 2016-11-06 13:56:40 Does anybody know by chance if kernel modules can be swapped between grsec and vanilla kernel? 2016-11-06 13:57:27 e. g. there is just a package drbd9-grsec but no drbd9-vanilla 2016-11-06 14:02:47 jomat: dunno, but I bet that they cannot be swapped 2016-11-06 14:20:02 Hm… I'm asking because I'm about to package WireGuard for Alpine and I don't know how to handle module building for different kernel flavours… WIP here: https://github.com/jomat/aports/tree/master/community/wireguard 2016-11-06 14:20:41 Perhaps this is a question for the mailing list 2016-11-06 16:37:44 jomat, no, grsec/vanilla modules need to be built separately 2016-11-06 16:47:31 I thought so… 2016-11-06 16:55:36 fabled: https://github.com/alpinelinux/aports/commit/e480e9171ea20dc9fd247bd0f3ad4dce826fbdb0 2016-11-06 16:56:32 jirutka, that's the only case not really supported in abuild syntax yet; then again, all noarch is still rewritten as the $CBUILD, so end result is same 2016-11-06 16:56:42 need to fix that after release cycle 2016-11-06 16:57:11 fabled: if the result is the same, then what’s wrong with it? 2016-11-06 16:57:50 the current code expects the subpackages' clause to have the real target arch, it does not handle 'all' 2016-11-06 16:58:01 i'm thinking how to fix that 2016-11-06 16:58:05 fabled: if so, then why it does not fail during build? 2016-11-06 16:58:27 it creates the subpackage and places 'all' as arch in the pkg 2016-11-06 16:58:57 ah, so the resulting apk is broken and whole this behaviour is of course totally undocumented :( 2016-11-06 16:59:37 and the package is placed in 'all' arch subdir, which is not synced out. 2016-11-06 16:59:56 that's also why the builder tries to rebuild it, it does not find the package in proper dir 2016-11-06 17:00:00 it thoughts it's not built 2016-11-06 17:00:24 I’m still strongly convinced that it would be better to revert the last abuild version, the current state is light minefield 2016-11-06 17:00:25 the lua code for builder checks only the target arch dir 2016-11-06 17:01:14 the problem is that 'arch' handling was never defined properly 2016-11-06 17:01:24 and it got overloaded for two purposes 2016-11-06 17:01:39 'on which arch to build', and 'what should be the package's arch' 2016-11-06 17:01:54 because it was not documented properly and despite it was used “wrongly” in half of the abuilds, you haven’t said that it’s wrong and no one known that it’s wrong 2016-11-06 17:02:29 i did not pay attention until i wrote the cross-build support 2016-11-06 17:02:39 that is also not documented 2016-11-06 17:02:39 i did not write the arch stuff originally 2016-11-06 17:02:47 so i have no clue how to use it and what it actually can do 2016-11-06 17:02:55 i only fixed it to work properly 2016-11-06 17:03:06 but i understand it's rather messy state 2016-11-06 17:04:29 yes, and the worst is that it’s way more mess than in the previous version; although we have been using arch wrong all the time, it somehow worked, no I still don’t know how to use it to not produce broken apk :( 2016-11-06 17:04:31 we talked several times with ncopa on how to do the cross-building arch setting 2016-11-06 17:04:40 why it worked 2016-11-06 17:04:48 is that 'noarch' ways always translated to 'all' 2016-11-06 17:04:52 still is 2016-11-06 17:05:30 and internall abuild ignored the arch set in split function 2016-11-06 17:05:43 no, it does not 2016-11-06 17:05:48 it *used* to 2016-11-06 17:05:52 until i fixed it 2016-11-06 17:05:55 nope 2016-11-06 17:05:58 it did 2016-11-06 17:06:13 it was a bit hidden 2016-11-06 17:06:13 hm, actually, yeah, because noarch == all 2016-11-06 17:06:26 hmm 2016-11-06 17:07:31 what it did is: http://git.alpinelinux.org/cgit/abuild/tree/abuild.in?id=8302c0652c99f861ab05f0903579c74793cf5ab5#n836 2016-11-06 17:07:51 and $parch is always $CARCH: http://git.alpinelinux.org/cgit/abuild/tree/abuild.in?id=8302c0652c99f861ab05f0903579c74793cf5ab5#n811 2016-11-06 17:08:37 okay, but at least it used to be semantically correct, just unused 2016-11-06 17:08:45 now, the code actually honors the arch set in subpackages 2016-11-06 17:08:51 and it's put directly to the package 2016-11-06 17:09:52 we really tried to make arch setting nice, and doable inside the split function 2016-11-06 17:10:01 but we could not figure any sensible way to do it 2016-11-06 17:10:12 so that it would be parseable 2016-11-06 17:10:20 yes, because redefining variables inside split functions is wrong from the beginning 2016-11-06 17:10:58 yeah 2016-11-06 17:12:01 but in practice it’s currently problem only for arch and depends, isn’t it? 2016-11-06 17:13:57 it's really only arch 2016-11-06 17:14:08 anyway, it’d be probably less evil to use e.g. _ (pkgdesc_zshcomp=) or something like that for all variables instead of redefining them in split functions 2016-11-06 17:14:19 depends is certainly a problem as well 2016-11-06 17:14:43 because abuild installs both depends and makedepends before building a package 2016-11-06 17:14:57 but it does not install depends declared in split functions, because it does not know about them 2016-11-06 17:15:53 that’s why I don’t like subpkg:split:arch, because the problem is more general and this handles just one case in very special way 2016-11-06 17:16:57 btw `abuild -i` is broken now… but I haven’t had time to debug it yet 2016-11-06 17:17:38 mmm... i think 'abuild -i' was removed, usage() was not updated 2016-11-06 17:17:51 it's only the top level depends that's considered 2016-11-06 17:17:55 it's always been like that 2016-11-06 17:18:02 but i think it's sort of mistake 2016-11-06 17:18:44 that's why depends_dev was added and it's often added as makedepends="$depends_dev ..." 2016-11-06 17:19:08 but we have some package where $depends is not really needed to be installed, and it'd simplify building if it was not auto-installed 2016-11-06 17:20:26 arch is more special because it's needed in early stages, to figure out where the generated .apk files should go 2016-11-06 17:23:16 we were talking on redoing the apkbuild format too, but it'd be controversial. and there isn't really good alternative 2016-11-06 17:24:02 it would probably need to be mix of things; e.g. yaml for metadata, with shell script embedded or so 2016-11-06 17:24:26 but to get the yaml section do all the corner cases we do with conditionals currently would be complicated 2016-11-06 17:24:42 why was `abuild -i` removed?! 2016-11-06 17:25:47 i think we thought no one was using it, and it was slightly complicated to re-implement 2016-11-06 17:26:02 hm, i use it quite often… 2016-11-06 17:26:16 that was maybe a bit of oversight 2016-11-06 17:27:36 abuild -i foo #=> /usr/bin/abuild: line 2287: foo: not found 2016-11-06 17:27:46 http://git.alpinelinux.org/cgit/abuild/commit/?id=f7e2b48d1cdcbd2c84705de20669b94c62ab6371 2016-11-06 17:28:48 i guess it could be added back and install all packages of 'noarch' or $CBUILD type 2016-11-06 17:28:50 abuild 2.29.0 2016-11-06 17:28:50 usage: abuild [options] [-P REPODEST] [-s SRCDEST] [cmd] ... 2016-11-06 17:28:50 abuild [-c] -n PKGNAME[-PKGVER] 2016-11-06 17:28:50 Options: 2016-11-06 17:28:50 … 2016-11-06 17:28:51 -h Show this help 2016-11-06 17:28:51 -i Install PKG after successful build 2016-11-06 17:28:52 -k Keep built packages, even if APKBUILD or sources are newer 2016-11-06 17:29:08 yes, the help test was not updated by mistake 2016-11-06 17:29:23 -p was removed also 2016-11-06 17:29:28 i can live without it, the problem is that it’s again broken, because it is still in usage and it does not tell that such option does not exist, but print cryptic error message instead 2016-11-06 17:30:43 $ abuild foo 2016-11-06 17:30:43 /usr/bin/abuild: line 2287: foo: not found 2016-11-06 17:31:19 i think that's been a problem since dawn, that if you mistype 'cmd' it prints like that 2016-11-06 17:31:21 in fact 2016-11-06 17:31:34 try 'abuild echo' 2016-11-06 17:31:52 i think it should whitelist known commands 2016-11-06 17:32:11 now it just tries to run it 2016-11-06 17:35:18 jirutka, sorry for the abuild mess. let's try to fix it to usable state, instead of reverting. imho, the current functionality is better. and we did try to preserve compatibility, but sometimes it's not possible. especially if it was misused earlier. 2016-11-06 17:35:27 <_ikke_> Is there no way to specify an rc version with abuild? 2016-11-06 17:35:36 _ikke_, 1.0_rc1 is accepted 2016-11-06 17:35:49 <_ikke_> ok 2016-11-06 17:35:59 it needs _rc or so 2016-11-06 17:36:11 -rc is not ok, or _rc without number 2016-11-06 17:36:23 <_ikke_> right 2016-11-06 17:36:27 fabled: imo the most important now is to properly document it, because lack of documentaiton is the source of most of the current problems (misuse etc.) 2016-11-06 17:36:35 yes 2016-11-06 17:36:37 i thought that i know how it works, but i was wrong 2016-11-06 17:37:10 i probably had same impression as you, before i started fixing it 2016-11-06 17:37:21 i think that's part of the reason why no one noticed the misuse 2016-11-06 17:37:26 _ikke_: alpine uses the same format as gentoo, it’s documented here https://devmanual.gentoo.org/ebuild-writing/file-format/ 2016-11-06 17:37:42 _ikke_: plus alpine defines extra post-release suffixes _git, _svn, _cvs 2016-11-06 17:37:57 <_ikke_> ok 2016-11-06 17:40:25 fabled: i should finally find some time, read abuild source code, write at least some notes, make it run with set -e and try to write some tests 2016-11-06 17:40:35 yes, set -e is good 2016-11-06 17:40:43 also remove md5/sha256 checksum 2016-11-06 17:41:21 that’s another thing i wanted to ask… why we have md5, sha256 and sha512 checsums? 2016-11-06 17:41:45 legacy history 2016-11-06 17:41:56 it was only md5 originally 2016-11-06 17:42:02 <_ikke_> fabled: jirutka thanks 2016-11-06 17:42:06 the two shas were added later 2016-11-06 17:42:08 are all of them verified now or just sha256? 2016-11-06 17:42:15 originally it verified all 2016-11-06 17:42:19 now it verifies only the strongest 2016-11-06 17:42:30 so it's redundant to keep them all 2016-11-06 17:42:44 it was mostly to be compatible with the older versions 2016-11-06 17:42:55 aha 2016-11-06 17:43:03 but the 'verify strongest hash only' + sha512 has been there for years 2016-11-06 17:43:09 so it's ok to drop the weak ones out 2016-11-06 17:50:50 Hi guys, what's the current ETA for 3.5.0? Is it still expected for a November release? 2016-11-06 17:52:10 r3g3, yes, i think hopes are to have _rc1 out early next week 2016-11-06 17:52:57 sounds great, thanks fabled! 2016-11-06 17:53:28 <_ikke_> LebedevRI: http://alpine.ikke.info/testing/x86_64/darktable-2.2.0_rc0-r0.apk 2016-11-06 18:01:05 <_ikke_> jirutka: Ah, I see you reviewed my darktable PR, thanks 2016-11-06 18:01:08 <_ikke_> missed that 2016-11-06 18:08:53 _ikke_: cool 2016-11-06 19:24:05 please git pull git://git.alpinelinux.org/user/fab/aports 2016-11-06 19:24:11 a couple of updates 2016-11-06 19:51:51 faffolter: testing build is running https://github.com/alpinelinux/aports/pull/404 2016-11-06 19:57:02 faffolter: py-scrapy failed, https://travis-ci.org/alpinelinux/aports/builds/173729141 2016-11-06 19:59:49 that didn't work well...seems that i missed a couple of changes 2016-11-06 20:01:34 let me create PRs on GitHub to profit from travis 2016-11-06 20:14:54 okay :) 2016-11-06 20:44:47 fabled: is it okay to use pkg:split:noarch? 2016-11-06 20:44:57 fabled: when top-level is all 2016-11-06 20:50:19 yes 2016-11-06 20:50:30 jirutka, that's used in various places 2016-11-06 20:51:07 fabled: okay, i wasn’t sure 2016-11-06 20:51:33 it still gets rewritten as $CBUILD currently, but hopefully during next dev cycle we get that sorted out 2016-11-06 21:12:08 faffolter: I’ve merged all of your commits except py-scrapy that needs to be fixed 2016-11-06 21:13:09 jirutka: thanks 2016-11-06 22:29:01 can someone with knowledge about alpine/musl/c have a look at this? https://github.com/alpinelinux/aports/pull/406 2016-11-06 22:33:26 looks ok, if costly 2016-11-06 22:33:51 I mean, I don't know what applications use libmilter but... 2016-11-06 22:34:33 they'll be huge after the change. 2016-11-06 22:34:58 Not sure what the Alpine policy is on this - but from a C/correctness point of view, I think it's ok. You might want to ask confirmation on #musl. 2016-11-06 22:36:02 thank you 2016-11-06 22:36:23 spamassassin and opendkim are using libmilter - just to name 2 2016-11-06 22:37:10 yeah, they're behemoths anyway :/ 2016-11-06 22:37:49 and musl has a entry in their wiki: http://wiki.musl-libc.org/wiki/Functional_differences_from_glibc#Thread_stack_size 2016-11-06 22:38:26 yes, they are, but i don't know about alternatives 2016-11-06 22:38:29 :/ 2016-11-06 22:38:57 <^7heo> stwa l'alternative 2016-11-06 22:39:02 <^7heo> ACTION hides 2016-11-06 22:39:20 <^7heo> (joke aimed at skarnet; for other people, please disregard) 2016-11-06 22:39:35 I've had that one on my mind for ages... 2016-11-06 22:39:44 <^7heo> :P 2016-11-06 22:39:47 pfffff and others that could understand ? 2016-11-06 22:39:48 thanks for being my uninhibited self :P 2016-11-06 22:39:51 :( 2016-11-06 22:40:08 <^7heo> coredumb: then you can enjoy it too :D 2016-11-06 22:40:29 stwa: yes, that's why I think the patch is correct - it doesn't hack musl, it uses the right API for the job, etc. 2016-11-06 22:40:53 my only criticism would be: it should be up to the application to modify stack size, not a library 2016-11-06 22:41:10 but if it's part of the libmilter API to create threads, then there's not much you can do 2016-11-06 22:41:17 apart from sending hate mail to the libmilter authors 2016-11-06 22:42:33 the alternative to spamassassin and opendkim is to burn the whole mail infrastructure with napalm and extreme prejudice 2016-11-06 22:42:44 yeah, debugging libmilter was almost killing me ... 2016-11-06 22:42:49 unfortunately, that's impractical for now 2016-11-06 22:43:36 but okay, thanks for your feedback! 2016-11-06 22:44:21 yes, sounds impractical, and i will better skip the hate mails too 2016-11-06 22:44:48 pffff... nobody ever takes my suggestions 2016-11-06 22:44:59 <^7heo> :D 2016-11-06 22:46:16 skarnet: "the alternative to spamassassin and opendkim is to burn the whole mail infrastructure with napalm" … agree on that! 2016-11-06 22:46:31 don't forget the extreme prejudice 2016-11-06 22:46:45 <^7heo> I really dislike when shit doesn't build for obscure reasons 2016-11-06 22:47:56 ^7heo: or crashes for obscure reasons… 2016-11-06 22:51:44 <^7heo> stwa: same :P 2016-11-06 23:13:53 skarnet: I’m too tired to read whole backlog, so just tl;dr, what do you think about https://github.com/alpinelinux/aports/pull/406, should I merge it? 2016-11-06 23:15:11 I'm giving it a lgtm, that's as far as I'm willing to go :D 2016-11-06 23:15:31 now if libmilter-using applications are currently unusable anyway, go ahead and merge it, it can't hurt XD 2016-11-06 23:17:05 skarnet: to be honest i have no clue what does it actually do, so I needed to ask :) 2016-11-06 23:18:15 it increases the thread stack size of threads started by libmilter from the musl default (which is small) to 8 MB (which is huge but more or less what glibc does so some ass-broken applications rely on that) 2016-11-06 23:18:30 (or is it broken-ass?) 2016-11-07 02:09:03 If one were to test an arm package through abuild, how would they go about compiling it? 2016-11-07 08:13:48 tavixvi: very carefully 2016-11-07 08:19:14 morning. happy monday! 2016-11-07 08:19:44 ACTION grumbles 2016-11-07 10:24:35 stwa: skarnet: WDYT? https://github.com/alpinelinux/aports/pull/406#issuecomment-258798091 2016-11-07 10:25:41 hi 2016-11-07 10:25:45 i made that comment 2016-11-07 10:26:55 here's a snippet from yesterdays talk on #voidlinux 2016-11-07 10:27:26 hallo. not sure anyone cares, but we have just released darktable-2.2.0rc0, with support for musl libc 2016-11-07 10:27:40 LebedevRI, thats nice to hear. i hope you did so without introducing a lot of hacks or wasting a lot of resources(like making the default stacksize for all threads 8MB) ;) 2016-11-07 10:27:40 sh4rm4^bnc: the code now does not stack-allocate more than 32Kb, but it still do not work, likely due to external library, so we bumped default stacksize to 1Mb. 2016-11-07 10:27:40 i see. that's way more reasonable than 8MB, at least. 2016-11-07 10:27:40 just out of curiosity, did you try if e.g. 256KB would work ? 2016-11-07 10:28:08 sh4rm4^bnc: re 256KB: i'll be honest: i do not believe i did check, mostly because it was a case of remote-debugging :( it is on my todo for after 2.2.0 though 2016-11-07 10:28:09 LebedevRI, would be quite nice if it turned out to work, or at least 512 KB if not. thanks for considering it! 2016-11-07 10:28:28 and today: 2016-11-07 10:28:30 [10:47:56] sh4rm4^bnc: it *seems* you were right, **so far** i was unable to make darktable crash even with 256Kb stack 2016-11-07 10:28:57 sh4rm4^bnc: hi, i was scanning the list of pkgs on sabotage but haven't found libmilter ;) 2016-11-07 10:29:39 yes. the only case we found so far is Dwarf Fortress 2016-11-07 10:29:40 as i stated in the pr, ~1MB may be sufficient, i havn't tested it 2016-11-07 10:29:40 oh, it's definitely costly, but until someone is willing to bisect the correct value for the stacksize, better to have wasteful but working packages than crashing ones. 2016-11-07 10:29:47 we had to patch libsdl for that 2016-11-07 10:29:55 1 MB would certainly be better indeed. 2016-11-07 10:30:34 i try with 1 MB… 2016-11-07 10:34:58 okay, it doesn't crash with 512 KB stack size, at least for opendkim 2016-11-07 10:45:40 and even a stack size of 256 KB works, thought i have tested it yesterday 2016-11-07 10:46:13 skarnet: jirutka: so what do you think? "wasteful but working" or "as long as it doesn't crash"? 2016-11-07 10:48:09 what is the subtle difference between "working" and "it doesn't crash" ? 2016-11-07 10:49:33 e.g. it seems to work but may be there are corner cases in the code where additional memory is allocated… 2016-11-07 10:52:27 Not being a libmilter user, I really don't care. Going with 512 KB is safe, but if you go with 256 KB, it will probably work too, and if it crashes someone will report it and the fix will be very easy and fast. So it's really your choice, I guess. 2016-11-07 11:08:03 alright, thanks, created a second PR, sorry jirutka :/ 2016-11-07 11:52:27 stwa: I don’t know what are the exact consequences, so I let you and skarnet decide that ;) 2016-11-07 11:53:25 stop involving me, I was only there to check the mechanism, not the policy! :P 2016-11-07 12:02:12 skarnet: don't you want to be policy enforcer? 2016-11-07 12:04:08 coredumb: absolutely not. Unless you offer me the position of world dictator with full powers, then we can start negotiating. 2016-11-07 12:04:50 nah just the for the stack's size sorry :P 2016-11-07 12:05:22 Too bad. 2016-11-07 12:18:39 no please, i dont want to speak french! 2016-11-07 12:23:23 kind of interesting error message: http://build.alpinelinux.org/buildlogs/build-3-5-x86/community/rawtherapee/rawtherapee-4.2-r1.log 2016-11-07 12:24:40 or maybe its a warning 2016-11-07 12:26:38 ncopa: wow, you’re here; already boring at vacation? :) 2016-11-07 12:36:46 <^7heo> clandmeter: it's a wrong assumption that all french people like french. 2016-11-07 12:37:07 <^7heo> clandmeter: also it's a wrong assumption that french people speak french 2016-11-07 12:41:08 <^7heo> clandmeter: most of them speak an approximative french that is as close to French as Hoi Toider is to Shakespeare's English. 2016-11-07 12:41:24 <^7heo> (or even worse) 2016-11-07 12:41:31 <^7heo> (much likely worse) 2016-11-07 12:44:03 clandmeter: Don't worry. The only language policy I would enforce as world dictator would be "no Dutch". 2016-11-07 12:46:27 <^7heo> skarnet: dude, no! 2016-11-07 12:46:33 <^7heo> skarnet: dutch is cool 2016-11-07 12:52:08 then you have to outlaw also klingon i believe 2016-11-07 13:00:56 also i'm convinced the only nation that can pronounce cthulhu correctly is the dutch. ;) 2016-11-07 13:07:29 if you haven’t heard and try to learn Arabic, then you really don’t know what is weird language with extremely weird pronounciation ;) 2016-11-07 13:09:16 <^7heo> Dude, Arabic is easy next to Chinese :P 2016-11-07 13:11:51 i dont know about arabic, but im surrounded by ppl speaking cantonese and mandarin. you will learn to ignore it eventually :) 2016-11-07 13:14:10 <^7heo> clandmeter: are you in asia atm? 2016-11-07 13:14:39 no, i call it little asia (our office) 2016-11-07 13:14:50 <^7heo> oh ok 2016-11-07 13:17:18 mandarin? this is actual language? 2016-11-07 13:17:36 colloquially known as "Chinese" 2016-11-07 13:17:56 but Cantonese is also Chinese, and distinct from Mandarin. 2016-11-07 13:19:15 ppl from hong kong talk Cantonese, the rest of them speak mostly mandarin. 2016-11-07 13:19:26 <^7heo> Cantonese is spoken in Hong Kong 2016-11-07 13:19:35 <^7heo> The rest of the China speaks Mandarin 2016-11-07 13:19:37 <^7heo> oh 2016-11-07 13:19:42 <^7heo> sorry clandmeter for paraphrasing you. 2016-11-07 13:19:47 :) 2016-11-07 13:19:58 most are not from china ;-) 2016-11-07 13:20:07 dont tell them they are from china 2016-11-07 13:20:14 <^7heo> who? 2016-11-07 13:20:22 Taiwan 2016-11-07 13:20:38 <^7heo> ah 2016-11-07 13:20:38 <^7heo> yeah 2016-11-07 19:33:20 ^7heo: around? 2016-11-07 20:52:13 faffolter: py-m2crypto, is it possible to move it to main/community? 2016-11-07 21:19:24 stwa: if the update works we can do that 2016-11-08 00:41:23 so there really isnt a good way to cross compile? 2016-11-08 18:09:42 what's the default way to handle a tool which runs with py2 and/or py3? 2016-11-08 18:10:37 is al able to check that automatically or is a postfix '-3' and a modified shebang needed? 2016-11-08 18:13:23 looking forward for 2020...then we are back to normal when it comes to py packages 2016-11-08 18:17:00 faffolter: we haven’t figured out yet… to handle it systematically, we need support in apk for “alternatives” 2016-11-08 18:17:13 faffolter: is it really needed to have py2 variant? 2016-11-08 18:18:05 faffolter: we agreed that Python 3 should be default target, so if it’s only a tool, not a lib used by other packages, then it’s okay to have only python3 variant 2016-11-08 19:40:28 i dont know what happens, but it seems that rsync hangs when uploading new releases 2016-11-08 19:40:35 at least x86_64 and x86 does 2016-11-08 19:41:21 i have no idea why 2016-11-08 19:41:26 same thing happened last time i did release 2016-11-08 19:44:50 alpine-mirror:~# ps xa | grep buildoze | tpaste 2016-11-08 19:44:50 http://tpaste.us/36YZ 2016-11-08 19:44:55 thats on the server side 2016-11-08 19:45:51 alpine-mirror:~# strace -p 29163 2016-11-08 19:45:51 strace: Process 29163 attached 2016-11-08 19:45:52 _newselect(1, [0], [], [0], {57, 486009} 2016-11-08 19:45:57 and it hangs tehre 2016-11-08 19:46:22 alpine-mirror:~# strace -p 29162 2016-11-08 19:46:23 strace: Process 29162 attached 2016-11-08 19:46:23 _newselect(4, [3], [], [3], {30, 435089} 2016-11-08 19:46:55 alpine-mirror:~# strace -p 29162 2016-11-08 19:46:56 strace: Process 29162 attached 2016-11-08 19:46:56 _newselect(4, [3], [], [3], {30, 435089}) = 0 (Timeout) 2016-11-08 19:46:56 _newselect(4, [3], [], [3], {60, 0} 2016-11-08 19:47:00 it will get timeouts 2016-11-08 19:47:50 in the end it will just give up 2016-11-08 19:49:01 _newselect eh? 2016-11-08 19:49:12 is that a syscall? o.O 2016-11-08 19:49:21 no idea 2016-11-08 19:49:30 thats what strace returns 2016-11-08 19:49:57 alpine-vanilla-3.4.6-x86_64.iso 2016-11-08 19:49:57 54,886,400 63% 13.07MB/s 0:00:02 2016-11-08 19:50:01 and there it hung 2016-11-08 19:50:31 apparently it's a syscall, but the man page for _newselect just mentions select and pselect 2016-11-08 19:50:41 so I suppose it's just select 2016-11-08 19:51:28 [103536.757476] TCP: request_sock_TCP: Possible SYN flooding on port 873. Sending cookies. Check SNMP counters. 2016-11-08 19:51:46 i dont know if its related 2016-11-08 19:51:49 probably not 2016-11-08 19:52:02 this rsync runs over ssh 2016-11-08 19:52:32 I don't know, but I'd love it if the bugs I trigger sent me cookies as well 2016-11-08 20:01:31 ok the release is finally uploaded 2016-11-08 20:16:46 and one of the uploaded iso images was corrupt 2016-11-08 20:18:12 i think we need new master mirror 2016-11-08 20:25:20 we know 2016-11-08 20:27:04 ncopa: I have an offer from vpsFree (they can give us VPS for mirror for free), but they need to know our average traffic 2016-11-08 20:35:30 clandmeter: do we have traffic stats from scaleway? 2016-11-08 20:37:56 jirutka: no, real need for py2 at least i guess 2016-11-08 20:40:21 faffolter: is the comma on the correct place? i.e. is it “no real need for py2”, or “no, real need [is] for py2” ? 2016-11-08 20:41:23 jirutka: no, no real need 2016-11-08 20:41:53 negations are hard 2016-11-08 20:42:39 skarnet: no, the problem here is interpunction… 2016-11-08 20:43:17 I hadn't not understand what you did not fail to mean 2016-11-08 20:43:24 understood*, sorry 2016-11-08 20:43:59 grammar isn't lacking in difficulty either 2016-11-08 20:44:16 sorry, in absence of easiness 2016-11-08 20:46:00 XD 2016-11-09 06:24:26 hi guys 2016-11-09 06:24:48 I'm getting IO ERROR when adding unsecure package 2016-11-09 06:26:44 specifically I'm `curl`ing `alpine-pkg-glibc` from andyshinn's repo and it works after I do `apk add --allow untrusted ....` 2016-11-09 06:27:03 but if I `curl` from a fork of that repo, it will say IO ERROR 2016-11-09 09:58:59 jirutka: i dont really have stats but i can tell you this 2016-11-09 09:59:33 20 days uptime, eth0 reports: RX bytes:7863419938756 (7.1 TiB) TX bytes:8144545561956 (7.4 TiB) 2016-11-09 10:00:29 but this is probably a bad moment to mesure because of the recent aarch64 resigning/reuploading and v3.5 2016-11-09 10:44:21 morning folks 2016-11-09 10:44:34 anyone notices problems with lighttpd lately? 2016-11-09 10:44:51 ScrumpyJack: what do you mean? 2016-11-09 10:45:04 i guess not then :) 2016-11-09 10:45:42 anyway, it seems it seg faults on ssl calls 2016-11-09 10:46:17 I've just noticed, so i'll dig around a bit more 2016-11-09 10:50:57 ScrumpyJack: i guess thats on edge? 2016-11-09 10:51:04 probably due to libressl? 2016-11-09 10:56:00 it turns out it was php-fpm 2016-11-09 10:56:50 permissions on the php-fpm unix socket make lighttpd seg fault when it tried to open it 2016-11-09 11:24:17 ScrumpyJack: what version? edge? 2016-11-09 12:24:49 i'd like to enable the php(7) plugin for uwsgi 2016-11-09 12:25:02 either we need to move php7 to main or we move uwsgi to community 2016-11-09 12:25:25 anyone tried php7 in alpine? 2016-11-09 12:25:40 im not sure it is packaged "correctly" 2016-11-09 12:38:42 guys 2016-11-09 12:38:46 what do we do with php7? 2016-11-09 12:39:07 its broken 2016-11-09 12:39:24 apparently you need create manual symlinks to make it work 2016-11-09 12:39:45 How new is it? 2016-11-09 12:39:59 has been out for a while 2016-11-09 12:40:08 Is it only the symlinks that are broken? 2016-11-09 12:40:18 well 2016-11-09 12:40:21 Sounds as if it's quite easy to fix then? 2016-11-09 12:40:26 the problem is 2016-11-09 12:40:46 php7-dev ships /usr/bin/'php-config7 2016-11-09 12:40:55 apps does not look for php-config7 2016-11-09 12:40:59 they just use php-config 2016-11-09 12:41:06 so we shouldnt rename the php-config 2016-11-09 12:41:12 same goes with /usr/bin/php 2016-11-09 12:41:28 apps looks for /usr/bin/php, not for /usr/bin/php7 2016-11-09 12:41:52 so people apparently manually create symlinks php7 -> /usr/bin/php 2016-11-09 12:41:57 Yeah, wonder why the packager decided on that approach. 2016-11-09 12:42:30 probably because he wanted have both installed at the same time 2016-11-09 12:42:31 Iirc there was a discussion about "slots" or similar for packages some time ago..? 2016-11-09 12:42:50 there are no "slots" we have different package names 2016-11-09 12:42:55 each package name is a "slot" 2016-11-09 12:43:09 slots doesnt solve anything 2016-11-09 12:43:34 you get same problem, files from different packages/slots wants to claim same filepath 2016-11-09 12:43:36 Yeah, but it would be very simple to have something like the busybox-links trigger to update a symlink, perhaps according to some config in /etc/apk/slots or similar? 2016-11-09 12:43:46 right, update-alternatives 2016-11-09 12:44:01 i think gentoo has eselect 2016-11-09 12:44:06 that we dont have 2016-11-09 12:44:07 but 2016-11-09 12:44:18 its kinda late to start work on that now 2016-11-09 12:44:28 i kinda wanted rc1 out today 2016-11-09 12:44:33 Ok. 2016-11-09 12:44:36 so i wonder 2016-11-09 12:44:41 what do we do with php7 2016-11-09 12:44:47 we just leave it as it is, broken? 2016-11-09 12:44:53 burn it 2016-11-09 12:44:55 burn apk too 2016-11-09 12:44:57 burn everything 2016-11-09 12:45:18 skarnet: are you ok? 2016-11-09 12:45:23 Would it really be that much work, in case packages install php[678], gpg[123] etc, and a script updates /usr/bin/php to point to the right place? Sounds easy in theory at least. 2016-11-09 12:45:23 no I'm not 2016-11-09 12:45:49 but in this case my suggestion makes sense. Maybe not if you want a solution *today*, but long-term it does 2016-11-09 12:46:22 ncopa: Leaving it as it is might make people start using php7 in their scripts, which would (might) lock/force us into using that naming convention. 2016-11-09 12:46:32 redesigning apk to handle several versions at the same time and a current default is the only way to solve that kind of problem once and for all 2016-11-09 12:46:44 nidan_: thats is what i fear 2016-11-09 12:46:54 it happens for php7, it happens for py2 and py3, it has happened for countless other packages before, and it will happen again 2016-11-09 12:47:31 the problem is that python3 expects to be /usr/bin/python and python2 expects to be /usr/bin/python 2016-11-09 12:47:44 and php5 expects to be /usr/bin/php and php7 expects to be /usr/bin/php 2016-11-09 12:47:49 keep adding duct tape for the moment, but at some point you *will* have to burn everything and rebuild from the ground up 2016-11-09 12:47:58 Well, if it is as easy in practice as in theory (use a couple of symlinks to implement "slots"), it might actually not be that bad to have /usr/bin/php7? 2016-11-09 12:48:01 problem is that upstream expects that everyone upgrades the same moment they ship new release 2016-11-09 12:48:01 well, you can't fix stupid 2016-11-09 12:48:11 you can only mitigate it 2016-11-09 12:48:43 i suppse we can rename /usr/bin/php7 -> /usr/bin/php 2016-11-09 12:48:46 and let them conflict 2016-11-09 12:48:55 so you cannot have them installed at the same time 2016-11-09 12:49:31 skarnet: Well, _how_ would one solve having several versions at the same time, unless having different names for the binaries? 2016-11-09 12:49:33 make a wrapper that automatically sends a bug-report (which chosen hate words) to the PHP authors every time something crashes because of that 2016-11-09 12:49:41 Or , binaries, all conflicting files. 2016-11-09 12:50:09 skarnet: Well, it's equally impossible for them to solve, right? 2016-11-09 12:50:22 they have the power to change their interface, we don't 2016-11-09 12:50:51 skarnet: Or do you mean that THEY should ship php with the name php7 so that we wouldn't need to care? 2016-11-09 12:51:11 Yes. 2016-11-09 12:51:19 ok, let's rewind. 2016-11-09 12:52:31 I've said it before and I'll say it again: the correct way to handle multiversioning is to install, say, php 5 in /opt/php-5 and php 7 in /opt/php-7. Scripts that depend on php5 are called with /opt/php-5/bin/php, scripts that depend on php7 are called with /opt/php-7/bin/php. 2016-11-09 12:52:50 Scripts that don't care are called with /opt/php/bin/php. Or /usr/bin/php, which is a symlink to it. 2016-11-09 12:53:08 And /opt/php is a symlink to php-5 or php-7, depending on what the user chooses. 2016-11-09 12:53:14 The symlink is "the current default". 2016-11-09 12:53:21 The current default can be changed. 2016-11-09 12:53:33 so something like update-alternatives or eselect 2016-11-09 12:53:44 That's the same thing as ../bin/php7 and ../lib/php7, just that the paths differ. 2016-11-09 12:54:01 he is saying: use symlinks to select the default 2016-11-09 12:54:02 Yes, except doing that with a FHS-like installation sucks because you can't do atomic updates or atomic default changes. 2016-11-09 12:54:33 Might be easier to update that symlink though, in case there is only one symlink for the /opt alternative and several for the /usr alternative. 2016-11-09 12:54:39 Exactly. 2016-11-09 12:54:47 Yeah. 2016-11-09 12:54:48 Changing one symlink is atomic, changing several files is not. 2016-11-09 12:54:49 Lagg here. 2016-11-09 12:55:06 i am thinking just let them conflict 2016-11-09 12:55:23 Yes. Let them burn. 2016-11-09 12:55:29 ncopa: For now you mean? 2016-11-09 12:55:35 Rebuild on the ashes. 2016-11-09 12:55:36 if you need both, then install them in $container_root/usr/bin/php 2016-11-09 12:55:59 thats what containers are for 2016-11-09 12:56:25 "container" in this case meaning? 2016-11-09 12:56:34 containers are the easy way out for the lazy 2016-11-09 12:57:09 yeah 2016-11-09 12:58:21 "container" being what? Just an install path or something like a virtual machine? 2016-11-09 12:59:02 a VM. Install paths is what I suggested. 2016-11-09 12:59:30 A VM sounds rather disgusting imho. 2016-11-09 13:00:26 don't do computers if your stomach is fragile. 2016-11-09 13:00:28 Adding UNPACK_PATH=/opt/php-7/ apk add php-7.xxx.apk would be better. 2016-11-09 13:00:52 skarnet: Nah, one just have to cook one's own food... 2016-11-09 13:00:53 Of course it would be better. That's what I said. But nobody ever listens to me. 2016-11-09 13:00:59 HAhah 2016-11-09 13:03:43 https://despair.com/products/elitism 2016-11-09 13:03:45 <3 2016-11-09 13:04:57 skarnet: If I understand correctly you'd like all software under /opt then? 2016-11-09 13:05:02 "all". 2016-11-09 13:05:33 skarnet: Or is it more like interpreters and similar only? 2016-11-09 13:05:35 yeah, I know those posters. I much prefer this one: https://despair.com/products/pretension 2016-11-09 13:06:28 Personally, I'd like all software to be under /package, but that won't happen, so yes, /opt is file 2016-11-09 13:06:32 fine* 2016-11-09 13:06:40 skarnet: That one I hadn't seen before, quite a few years since I last checked that page. It was a very good one. 2016-11-09 13:06:59 https://bugs.alpinelinux.org/issues/6450 2016-11-09 13:07:03 the FHS hierarchy is a historical wart that needs to burn like all the rest 2016-11-09 13:07:27 but in the meantime, /usr/bin as a forest of symlinks works perfectly fine 2016-11-09 13:07:43 Well, Bernstein has a few points that people only seem to discard due to legacy or emotional reasons. 2016-11-09 13:09:01 ncopa: (thumbsup) 2016-11-09 13:11:46 14:07 < skarnet> but in the meantime, /usr/bin as a forest of symlinks works perfectly fine <- I missed that line. =) Yeah, I concur, I don't think the atomic updates/atomic default changes issue is much of a problem in practice. 2016-11-09 13:15:24 The point is that there's no issue if /usr/bin is symlinks. 2016-11-09 13:16:27 If /usr/bin/php is a link to /opt/php/bin/php, then it does not need to be updated. When you change the default php version by renaming the /opt/php symlink, /usr/bin/php automatically points to the new binary. 2016-11-09 13:17:36 If /usr/bin/php -> php7 depends on /usr/lib/php -> php7 then it is a problem. Then you would need to atomically update two symlinks for the software suite to work correctly. I don't know if that's impossible to handle though, I would expect /usr/bin/php7 to look in /usr/lib/php7/ and not in /usr/lib/php/, but I don't know for sure, that why I wrote "in theory" and "in practice" above. 2016-11-09 13:18:31 skarnet: Ok, that's a different take all together, I thought you meant no /opt when you wrote about /usr/ being a forest of symlinks above. 2016-11-09 13:19:23 That's also why I also still sniffed out a problem, although not big in practice. 2016-11-09 13:19:36 All the atomicity problems come from the fact that FHS was never designed to have several versions of the same package. It's a fucking legacy from 1970. 2016-11-09 13:19:45 ACK 2016-11-09 13:20:31 And in 2016 we are still wasting countless hours on problems that would be solved if only people weren't so scared to break that bloody stupid habit. 2016-11-09 13:21:06 ".. due to legacy or emotional reasons". ;) 2016-11-09 13:21:14 Thus, I agree. 2016-11-09 13:21:53 There is one other aspect though being the psychology of users, if we change too much, users will cry and be sad. =) 2016-11-09 13:22:14 no, all they want is for things to work 2016-11-09 13:22:23 We can join OpenBSD then. They also do what they think is most correct and don't give much about user opinions. =) 2016-11-09 13:22:55 I don't concur, they want things to be familiar. And work, at least some of the time. 2016-11-09 13:23:10 OpenBSD is a joke. Have they even diverged from FHS? no. 2016-11-09 13:23:28 In that, I define "users" as being the majority of those using an installation. 2016-11-09 13:23:56 I guess wanting things to work 100% of the time makes me an elitist. That's fine, I'm used to it. 2016-11-09 13:24:52 skarnet: No, I never stated they did, (don't really think you implied that I did either, just saying) but I do think they're doing what they think is best/correct and don't care much about the opinions of users. 2016-11-09 13:25:03 skarnet: I hear you. 2016-11-09 13:26:01 I share much of those thought, I usually try to select a path to that goal that is slower and less prone to conflict than attacking the issue head on though. 2016-11-09 13:26:07 yes, they're like Republicans. They do what they think is best/correct, except they're wrong. 2016-11-09 13:26:28 Hhaha, I will not argue against that simply because it's correct. =D 2016-11-09 13:27:26 Anyway, stuffning things in /opt and having /usr being a forest of symlinks might actually be that non-conflicting approach I usually look for. 2016-11-09 13:27:44 Users would still find their stuff where they're used to, AND it would work. 2016-11-09 13:28:01 Hop on the train, man. Been driving it since 2000, what took you so long? 2016-11-09 13:28:13 So, except for partitioning issues I don't see a problem with that approach. 2016-11-09 13:28:39 "issues" in the above sentance meaning "emotional issues". 2016-11-09 13:28:47 End user's emotional issues. 2016-11-09 13:29:11 I guess most people don't even do any partitioning except the default though so I might be wrong. 2016-11-09 13:29:20 skarnet: Gladly, sorry to be late. =) 2016-11-09 13:30:18 I used /package, /service and /doc 2002 ->, but then I got tired of keeping the packaging up to date and sort of quit.. =/ 2016-11-09 13:49:32 ncopa, fabled: any chance for backporting the #6391 mini_httpd fix to 3.3 and 3.2? 2016-11-09 13:49:47 they were also broken back in May by the mini_httpd upgrade 2016-11-09 14:01:16 tdtrask: it does not work 2016-11-09 14:01:24 mini_httpd.o: In function `do_file': 2016-11-09 14:01:24 mini_httpd.c:(.text+0x22af): undefined reference to `add_data' 2016-11-09 14:01:39 will need more investigation 2016-11-09 14:03:15 should probably be reported upstream 2016-11-09 14:27:24 ncopa: I just assumed it worked because fabled did it :) 2016-11-09 14:27:39 well, that and the fact that the issue is marked complete 2016-11-09 14:28:13 it does work on edge 2016-11-09 14:28:16 and v3.4 2016-11-09 14:28:25 on the latest mini_httpd 2016-11-09 14:30:09 ah, got ya 2016-11-09 14:30:18 just not on older mini_httpd 2016-11-09 14:32:43 i suppose its just a question of copying the add_data function 2016-11-09 14:32:58 but would kinda nice to test it before pushing it 2016-11-09 14:33:11 so its just not to cherrypick it 2016-11-09 14:33:30 and i want 3.5 rc1 out today 2016-11-09 14:33:36 which does not seem to happen 2016-11-09 14:34:25 ACTION will find some time today to mess with backporting the fix 2016-11-09 14:35:02 i think its easy. just takes a bit time to test that it works 2016-11-09 14:48:05 i bumped radare2 and am willing to co-maintain it: https://github.com/alpinelinux/aports/pull/501 2016-11-09 14:51:05 on a related note my emacs patch is also pending 2016-11-09 17:54:21 skarnet: /opt is in FHS and it has different meaning, it’d be better to come with some non-conflicting name; beside that I agree with you; but have questions, what about logs, config files and temporary files? I really don’t like to have them in // 2016-11-09 17:55:48 skarnet: ncopa: btw you can look at Homebrew (package manager for macOS), they do something very similar 2016-11-09 17:56:40 <^7heo> ncopa: nothing seems to happen today 2016-11-09 17:57:50 skarnet: ncopa: every package is installed into /usr/local/Cellar//, then symlinks are created into /usr/local/bin, /usr/local/lib, and /usr/local/include (/usr/local is used just to avoid messing with base system, doesn’t make sense for us ofc) 2016-11-09 18:00:38 i got a threat "pay bitcoins or all your sites will go down 11 nov 10am" 2016-11-09 18:01:11 <^7heo> well, let's not pay and see what happens. 2016-11-09 18:01:19 <^7heo> paying is calling for more anyway. 2016-11-09 18:01:32 skarnet: ncopa: this would not be easy change, but I totally agree with skarnet that FHS is legacy that brings more problems than it solves and it’s really worth it to try get rid of it (partially) 2016-11-09 18:07:59 jirutka: having a package manager install anything in /usr/local is completely broken. /usr/local is, by definition, for local admin modifications. 2016-11-09 18:08:39 skarnet: no, it’s not broken in case of Homebrew 2016-11-09 18:08:48 skarnet: but as I stated, it doesn’t make sense for us ofc 2016-11-09 18:09:01 skarnet: there are very specific reasons why Homebrew uses this which are not related for us 2016-11-09 18:09:04 If it's something the local admin uses, ok. If it's something a distributor uses, no. 2016-11-09 18:09:31 Distributions can't touch /usr/local, period. Admins do whatever they want. 2016-11-09 18:10:14 Apart from that, if you don't like /opt, then anything else will do. 2016-11-09 18:10:57 skarnet: discussion about /usr/local is totally irrelevant 2016-11-09 18:11:26 skarnet: what other systems use non-FHS approach? where we can take some inspiration? 2016-11-09 18:11:39 Gobolinux or slashpackage. 2016-11-09 18:12:04 hm, never heard of them 2016-11-09 18:12:04 I don't agree with all the decisions in either case, though. 2016-11-09 18:13:56 ncopa: the real question is what tz 2016-11-09 18:14:26 I hope ncopa answered "come at me bro" 2016-11-09 19:17:22 we should clean up Python packages, there are too many of them, and it’s really just a waste of time to maintain pure python libs, if there are no apps depending on them, that you can (and should) install using pip 2016-11-09 19:44:53 and we desperately need something like eselect or update-alternatives! it’s a real problem for python packages that supports both py2 and py3 and install some files into /usr/bin 2016-11-09 19:53:20 Well, as stated above, it doesn't seem hard in theory, I don't know about practice. Making an initial package with support for something like update-alternatives using symlinks wouldn't be that hard. 2016-11-09 19:54:40 There's quite a bit of work if all packages should be recompiled to using /usr/local/Cellar/ or /opt/package-name/ though, but the stuff handling the symlinks would be rather easy to do. 2016-11-09 20:12:12 nidan_: /usr/local/Cellar was just example how it handles homebrew, definitely not what we should do 2016-11-10 08:04:37 ERROR: Failed to create usr/share/fonts/truetype/inconsolata/Inconsolata-Bold.ttf: Not a directory 2016-11-10 08:04:37 ERROR: Failed to create usr/share/fonts/truetype/inconsolata/Inconsolata-Regular.ttf: Not a directory 2016-11-10 08:26:34 apk fix solved it 2016-11-10 16:52:27 can someone ask this guy to file a bug on bugs.alpinelinux.org, or file it for him? https://forum.alpinelinux.org/forum/installation/installing-xenserver-tools 2016-11-10 16:52:35 the package is broke iirc 2016-11-10 16:52:43 ask him to set target 3.5.0 2016-11-10 17:15:38 ncopa: asked him 2016-11-10 18:18:06 how about we move gcalcli from main to community? 2016-11-10 18:18:14 is would allow us to move a couple of py libs which are not used elsewhere too 2016-11-10 18:18:36 http://g.jk.gs/Cw.png 2016-11-10 18:19:39 \o/ dependency spaghetti \o/ 2016-11-10 18:19:50 faffolter: yes please 2016-11-10 18:19:55 looking at py-gflags, py-vobject 2016-11-10 18:20:26 i working on updating all my stuff to py3 2016-11-10 18:21:01 skarnet: i just mentioned your name on forum.a.o (i know its your favorite place to stay) 2016-11-10 18:22:32 hihihi, 100 pull requests and nowhere near the end...this will take longer than expected 2016-11-10 18:22:38 clandmeter: you obviously had only good things to say about me, I hope! 2016-11-10 18:22:53 not eme 2016-11-10 18:22:54 me 2016-11-10 18:22:59 but other did 2016-11-10 18:24:22 kafloopascope? ok, I'll take the silly name and even the clown face since he's nice with me :D 2016-11-10 18:24:41 :) 2016-11-10 18:24:55 nice graph, but doesn't the curvature make it hard to tell which edges are connected 2016-11-10 18:36:16 is there an mrtg alterantive based on c or similar? 2016-11-10 18:36:29 as in lightweight... 2016-11-10 18:37:03 > monitoring 2016-11-10 18:37:06 > lightweight 2016-11-10 18:37:09 hahahahahaha 2016-11-10 18:39:15 <_ikke_> I have Zabbix running on a raspberry PI, is that counting as lightweight? :P 2016-11-10 18:40:58 "enterprise-class" 2016-11-10 18:41:21 i just dont like perl 2016-11-10 18:41:30 nobody does 2016-11-10 18:42:10 even Larry Wall hides in shame today 2016-11-10 18:52:07 hmm an alternative written in Go... 2016-11-10 18:54:36 omg, https://github.com/facette/facette/blob/master/vendor/vendorctl 2016-11-10 19:05:31 a Python program invoking git and mercurial to control Go dependencies? 2016-11-10 19:05:37 It's EVERYTHING WE EVER WANTED 2016-11-10 19:18:41 :D 2016-11-10 19:19:47 he was all out of dogg food 2016-11-10 19:59:38 hi faffolter 2016-11-10 19:59:41 oops 2016-11-10 19:59:45 hi fabled 2016-11-10 20:00:05 did you document the ::noarch switch somewhere? 2016-11-10 20:00:21 in the commit message 2016-11-10 20:00:21 switch/option or however you can call that. 2016-11-10 20:00:29 but not much elsewhere 2016-11-10 20:00:30 yet 2016-11-10 20:00:36 should update the wiki 2016-11-10 20:00:38 uhm 2016-11-10 20:00:45 i checked git but could not find it 2016-11-10 20:00:48 which commit is it? 2016-11-10 20:01:28 http://git.alpinelinux.org/cgit/abuild/commit/?id=b217bbb2ea62dec889f0d275855ddf79b2bd9fb7 2016-11-10 20:01:35 i guess the docs could've been better there 2016-11-10 20:02:55 ok i get it now. 2016-11-10 20:03:41 ncopa / fabled: I backported the mini_httpd bug fix to alpine 3.3 and 3.2 2016-11-10 20:21:29 tdtrask, nice. thx. 2016-11-10 20:28:16 fabled: is there a reason we dont have perl-libs? 2016-11-10 20:32:09 fabled: thx to you for the initial fix 2016-11-10 23:39:50 hi, in case you're missing dl-5... i'm upgrading from 3.0 to 3.4 2016-11-11 00:35:47 yikes 2016-11-11 00:35:54 why is it that xfs is always causing problems 2016-11-11 00:36:04 i remember filing a bug report 4 years ago 2016-11-11 00:37:00 maybe switch to another FS? I’m quite happy with btrfs 2016-11-11 00:37:36 yeah i'm not going to resync the whole mirror for that 2016-11-11 00:45:48 seems to be a recuring problem https://bugs.alpinelinux.org/issues/3946 2016-11-11 00:47:06 but i see this on 4.4.30-0-grsec 2016-11-11 00:48:35 it's working on the iso ... maybe i just migrate that kernel 2016-11-11 01:00:10 oh it's booting 2016-11-11 01:00:12 nice surprise 2016-11-11 01:58:18 grimeton: there’s no information about how it has been fixed, it looks like a recurring bug in usptream kernel or grsecurity patches 2016-11-11 02:00:17 grimeton: it’s really not sane to use the latest kernel from upstream, but unfortunately since grsecurity stopped public (unpaid) support for stable releases, we don’t have other option 2016-11-11 02:00:45 grimeton: thank to fucking Intel that didn’t respect grsecurity’s license 2016-11-11 02:03:06 grimeton: so basically you can use more secure, but more buggy grsec kernel, or less secure but more stable kernel from some bigger distro 2016-11-11 02:05:51 probably the only other option would be to port Alpine to OpenBSD kernel, that would be great, but it’s not really an easy task and it would have many other limitations 2016-11-11 02:07:27 like that OpenBSD don’t support many platforms, like RPi; NetBSD is better in this, they support almost every platform that exists, but from what I heard, the kernel is not so good as OpenBSD’s kernel (but I really don’t know BSDs well (yet)) 2016-11-11 02:09:57 or Illumos (formerly OpenSolaris) kernel would be really interesting option, according to some ppl it’s the best kernel that we have, but it’s quite different world 2016-11-11 02:34:48 yeah the netbsd kernel was created with portability in mind 2016-11-11 02:34:55 so it basically runs on everything ... even a toaster 2016-11-11 02:35:02 that's not a joke btw. someone really put it on a toaster 2016-11-11 02:35:27 openbsd is a bit problematic as of the people working on it ... 2016-11-11 02:35:45 best option is freebsd but they already have everything in place 2016-11-11 02:36:52 netbsd is more or less dead afaik 2016-11-11 02:37:02 hurd is another option but that's dead too isn't it? 2016-11-11 13:08:28 grimeton: most BSD fans gets angry when I say FreeBSD, but don’t really know why 2016-11-11 13:31:54 jirutka: skarnet: Yes, I used 'Cellar' with the same meaning as you did, instead of writing "../somewhere/". =) Assuming we would start moving things into something along the lines of /opt/package-name-ver/ or /package/name-ver/ or some such, is there any reason that we couldn't to it in small batches? Is there any package that you know of that _couldn't_ be moved without problem? 2016-11-11 13:55:01 nidan_: we need support in abuild 2016-11-11 13:55:26 nidan_: to avoid insane boilerplate in every apkbuild 2016-11-11 13:55:51 then yes, it can be done gradually 2016-11-11 13:56:10 jirutka: Good point on abuild. 2016-11-11 13:56:39 after all core devs agree on this 2016-11-11 13:56:43 for me it’s +1 2016-11-11 13:57:01 I'm obviously not a core dev, but +1 from me too. 2016-11-11 13:57:21 fabled: can we review the mirror logs to see which testing packages are being used before moving them to unmaintained? 2016-11-11 13:57:32 or just move them and wait for someone to scream 2016-11-11 13:57:45 and use that to encourage a maintainer to step up? 2016-11-11 13:57:45 imo we should wait until ncopa come back from holidays and then ask on ML 2016-11-11 13:57:52 package being installed != package works 2016-11-11 13:58:09 we would like the maintainer to step up, and users to verify that it works 2016-11-11 13:58:16 though 2016-11-11 13:58:38 the mass removal recently was little but aggressive and with too short notice. i think we try to do it in better way next time. 2016-11-11 13:58:39 agreed, but reviewing the logs give some idea if they're used 2016-11-11 13:58:44 true 2016-11-11 13:58:51 but we don't have logs from all mirrors 2016-11-11 13:59:06 :( 2016-11-11 13:59:06 i guess we could still get enough data to get a rough idea 2016-11-11 13:59:13 just an idea 2016-11-11 13:59:29 I imagine a few would stand out above the noise 2016-11-11 13:59:39 i dont mind the more aggressive mode, but i already showed that last time. 2016-11-11 14:00:51 if you cannot move or ask for a move from testing to community/main within 6 months, i dont see a reason why it should stay. 2016-11-11 14:01:10 we already communicated that last time and thats months ago. 2016-11-11 14:03:05 is there a reason why vlc has opus not enabled? 2016-11-11 14:03:42 zwiPZuf9W2Lt: if gitlog shows nothing, we can enable it. 2016-11-11 14:03:55 i am just doing a testcompile with opus enabled 2016-11-11 14:04:01 will tell you how it goes 2016-11-11 14:04:12 now that we talk about vlc 2016-11-11 14:04:27 is it possible to open video in the current window? 2016-11-11 14:04:34 mine always opens an extra window 2016-11-11 14:04:51 no idea, i use it from the shell without gui 2016-11-11 14:05:09 and the controls are in a window with a black screen. 2016-11-11 14:08:06 fabled: we do need to find a way how we can properly move packages to unmaintained without breaking other testings pkgs buildeps. 2016-11-11 14:09:11 and imho we should rename testing to staging, which would make more sense. 2016-11-11 14:09:51 clandmeter, you need the check in the preferences that it uses embedded video control or something similar 2016-11-11 14:10:20 clandmeter, yeah, staging might make sense. and we should automate the warning that it's going to be deleted sent to maintainer + contributors 2016-11-11 14:10:25 not all are subscribed 2016-11-11 14:11:44 fabled: clandmeter: imho testing is better name than staging; in development, staging environment is pre-production, it’s on higher level than testing 2016-11-11 14:12:17 fabled: i think ive tried that option, but ill try it again. 2016-11-11 14:13:07 fabled: clandmeter: definitely, moving pkgs without knowledge of reverse dependencies is crazy; I wrote some ad-hoc scripts to help with it, but it was just a ugly hacky way, it’d be better to have support in apk for this 2016-11-11 14:13:19 fabled: so we need also builddeps in index 2016-11-11 14:13:37 huh vlc complains about libshout totally unrelated to opus i think strange 2016-11-11 14:13:53 jirutka: staging does make it more clear its only a temp place. 2016-11-11 14:14:48 clandmeter: what does testing say? I’m not English native, so I probably have different feeling about these words 2016-11-11 14:15:04 clandmeter, jirutka : moving from testing to main/community should be relatively easy to test unless one has testing untagged in repositories 2016-11-11 14:15:12 moving from main to community is more problematic 2016-11-11 14:15:38 jirutka: thats increasing the size of the db a lot while you wont use that data very often. 2016-11-11 14:16:27 but more importantly it would mean adding 'business logic' of repository relations to apk 2016-11-11 14:16:33 i'd prefer not to do that 2016-11-11 14:16:59 jirutka: i was thinking of adding that data to pkgs.a.o db 2016-11-11 14:17:25 https://twitter.com/hyc_symas/status/797071522485719040 2016-11-11 14:32:12 fabled: what about producing two indexes? 2016-11-11 14:32:49 jirutka, they are already in two separate indexes 2016-11-11 14:32:52 clandmeter: I’d prefer to have these data locally, so I can resolve full dependencies graph even without internet connection 2016-11-11 14:33:03 the problem is that we'd need to describe the relation ship of these indexes 2016-11-11 14:33:38 and make the error checks based on that 2016-11-11 14:33:41 just one index for end-users and another index, that would be superset of the first one, for devs 2016-11-11 14:34:01 i'm planning to do something like that 2016-11-11 14:34:09 the superset including full directory listing of all packages 2016-11-11 14:34:25 so you can do query like "which uninstalled package provides file X" 2016-11-11 14:34:31 the other metadata could go there 2016-11-11 14:35:41 +1 2016-11-11 14:36:55 package manager is all about dependency graph, so it’s essential to have complete data about all dependencies and tools to query it 2016-11-11 14:38:57 15:34 <@fabled> so you can do query like "which uninstalled package provides file X" <- +1, that's a feature I've been missing. =) 2016-11-11 14:40:23 Something like --queryformat to apk would be nice too. =) 2016-11-11 14:40:32 yes, this and what packages depends on package X (including build dependencies), this is essential for safe moving of packages into lower repos (e.g. main → community, testing → unmaintained) 2016-11-11 14:41:04 nidan_, yes, we are planning a major redesign of apk cli and some of the internals. and that's also something we want to fix. 2016-11-11 14:41:32 btw statistics from mirrors would be very helpful, so we can remove some packages that no one actually use :) 2016-11-11 14:41:57 apk cli is rather nice imho, a lot better than the apt stuff... 2016-11-11 14:42:12 nidan_: ^ +1 2016-11-11 14:42:43 unfortunately it currently lacks some important features, but as fabled already said, he’s working on it :) 2016-11-11 14:42:49 nidan_, i think add/fix/del/basics stay. but info/search need unification, and be scripting safe 2016-11-11 14:42:55 jirutka: if you cannot controll all of your mirrors, what use are stats? 2016-11-11 14:43:17 clandmeter: that’s the challenge ;) 2016-11-11 14:43:45 sure they can provide you a rough idea, but in the above cause I wonder if it would fix anything. 2016-11-11 14:44:14 maybe we can ask maintainers of the mirrors to provide us this data; or add support for telemetry into apk (but that may be very controversial) 2016-11-11 14:45:08 the idea is that system would send as list of the pkgs that user has installed 2016-11-11 14:45:48 but I’m afraid that opt-out would upset many users, so it must be opt-in and the question is how many users would enable it 2016-11-11 14:46:03 you could do an opt-in, but still doesnt really fit alpine's profile very well. 2016-11-11 14:46:09 yes 2016-11-11 14:46:21 I wrote that it may be very controversial 2016-11-11 14:46:40 and we specifically mention on our www that we do not collect users data. 2016-11-11 14:46:48 gather statistics from mirrors seems to be a better option 2016-11-11 14:47:08 i prefer we dont gather data and fix issues another way. 2016-11-11 14:47:17 agree 2016-11-11 14:47:22 btw 2016-11-11 14:47:28 did you see the non javascript menu? 2016-11-11 14:47:55 I’m also not fan of collecting data from users’ systems, but it’s one of the options 2016-11-11 14:47:59 not yet 2016-11-11 14:48:00 stwa submitted a pr to fix the menu. 2016-11-11 14:48:07 i know, but haven’t tried it yet 2016-11-11 14:49:14 afk 2016-11-11 14:59:04 fabled: Ok, and +1 on the unification (not if it means merge info and search though, my initial feeling is that that's a -1) and scripting safe. 2016-11-11 14:59:37 yeah, let's see how it works out. once i have something usable, i'll probably write an email and start asking ideas 2016-11-13 19:03:43 Hi, i found bootstrap.sh in the git-repo and trying to bootstrap armv7.. should this work out of the box? 2016-11-14 17:53:46 interestingly, we don't have ddclient in alpine repo 2016-11-14 17:53:56 but ddclient has init for alpine 2016-11-14 17:53:57 https://github.com/wimpunk/ddclient 2016-11-14 18:26:25 <^7heo> what is ddclient? 2016-11-14 18:26:46 <^7heo> a dyndns client 2016-11-14 18:30:52 written in perl, just because they can. 2016-11-14 18:31:02 <^7heo> +42 2016-11-14 18:38:37 actually is quite huge for the job it should do.. 2016-11-14 18:38:38 bah 2016-11-14 18:38:57 one line with curl/wget would be enought for the job.. 2016-11-14 18:39:01 *enough 2016-11-14 18:39:08 but since other distro has.. 2016-11-14 18:41:15 <^7heo> oh wait 2016-11-14 18:41:19 <^7heo> I have a suggestion too! 2016-11-14 18:41:24 <^7heo> Let's package systemd! 2016-11-14 18:41:29 <^7heo> And enable it by default! 2016-11-14 18:41:38 <^7heo> Since other distro have it, it must be goo\d! 2016-11-14 18:41:42 <^7heo> s/ 2016-11-14 18:41:50 <^7heo> s/\\d/d/ 2016-11-14 18:42:01 <^7heo> freaking European layout... 2016-11-14 18:49:41 ^7heo, removed ddclient 2016-11-14 18:49:59 happy now? :) 2016-11-14 18:50:46 <^7heo> Meh, that won't have an incidence on my happiness anywya. 2016-11-14 18:50:49 <^7heo> anyway ffs 2016-11-14 18:50:51 <^7heo> fingers... 2016-11-14 18:51:00 <^7heo> only good at fucking things up. 2016-11-14 18:51:18 <^7heo> but less perl is always a good thing. 2016-11-14 18:51:35 <^7heo> "Go, Perl sucks because it's old. What's *your* excuse?" 2016-11-14 18:53:04 C is older and sucks less. Age is not an excuse. 2016-11-14 18:54:30 <^7heo> Said like that, it's misleading. 2016-11-14 18:54:39 <^7heo> C is the invention of geniuses. 2016-11-14 18:54:57 <^7heo> Perl is the invention of common men who didn't have the experience we now have about languages. 2016-11-14 18:58:16 Go is the invention of very smart men who used experience from C. So, where did it go wrong? :P 2016-11-14 18:59:47 you got a point, skarnet ... :) 2016-11-14 19:24:56 hi 2016-11-14 19:25:09 i think i will push the new image release scripts 2016-11-14 19:25:16 so we can use it for rc1 2016-11-14 19:25:21 this will replace alpine-iso 2016-11-15 14:13:04 i guys. How can I troubleshoot this error: "Cannot mix incompatible Qt library (version 0x50600) with this library (version 0x50601)". It's gns3 that has issues with qt5 2016-11-15 14:13:08 *Hi 2016-11-15 14:13:39 ah 2016-11-15 14:13:42 gotcha 2016-11-15 14:18:43 fcolista: you found it? 2016-11-15 14:18:55 its non matching qt modules 2016-11-15 14:19:05 clandmeter, correct 2016-11-15 14:19:32 i think is due to py3-qt5 which is 5.7 2016-11-15 14:19:37 while qt is 5.6 2016-11-15 14:19:50 would that make sense? 2016-11-15 14:20:07 I'm still wondering how to troubleshoot it 2016-11-15 14:22:10 fcolista: i dont think so 2016-11-15 14:22:17 i think its patch version that doesnt match 2016-11-15 14:22:35 qt is on 5.6.1 while a module is on 5.6.0 2016-11-15 14:23:54 clandmeter, umh 2016-11-15 14:23:58 i think you are right 2016-11-15 14:24:12 how do I figure the module that is not updated? 2016-11-15 14:25:22 heh 2016-11-15 14:25:39 http://pkgs.alpinelinux.org/package/edge/main/x86_64/qt5-qtsvg 2016-11-15 14:25:44 grep pkgver= qt5*/APKBUILD 2016-11-15 14:25:44 qt5-qtbase/APKBUILD:pkgver=5.6.1_p1 2016-11-15 14:25:44 qt5-qtdeclarative/APKBUILD:pkgver=5.6.1_p1 2016-11-15 14:25:44 qt5-qtgraphicaleffects/APKBUILD:pkgver=5.6.0 2016-11-15 14:25:44 qt5-qtimageformats/APKBUILD:pkgver=5.6.0 2016-11-15 14:25:45 qt5-qtmultimedia/APKBUILD:pkgver=5.6.1_p1 2016-11-15 14:25:47 qt5-qtquickcontrols/APKBUILD:pkgver=5.6.0 2016-11-15 14:25:49 qt5-qtscript/APKBUILD:pkgver=5.6.0 2016-11-15 14:25:51 qt5-qtsvg/APKBUILD:pkgver=5.6.0 2016-11-15 14:25:53 qt5-qttools/APKBUILD:pkgver=5.6.0 2016-11-15 14:25:55 qt5-qttranslations/APKBUILD:pkgver=5.6.0 2016-11-15 14:25:57 qt5-qtwebkit/APKBUILD:pkgver=5.6.1 2016-11-15 14:26:23 are several 2016-11-15 14:26:27 i think i bumped into the same thing 2016-11-15 14:26:34 i just updated the ones that affected me. 2016-11-15 14:26:43 ncopa bumped qt to 5.6.1 2016-11-15 14:26:48 so its all his faulth 2016-11-15 14:26:55 :) 2016-11-15 14:26:57 :) 2016-11-15 14:36:01 its nice to blame him when he is away. 2016-11-15 14:36:15 when he is back we have to blame skarnet again. 2016-11-15 14:38:03 you can blame me even when ncopa is away, who cares? 2016-11-15 14:39:19 nobody, but it has to be done. 2016-11-15 15:15:52 ^7heo: ive seen some Go pkgs have !strip, any reason for that? 2016-11-15 15:17:06 <^7heo> clandmeter: doesn't go strip by default? 2016-11-15 15:17:46 i dont think so if you dont ask for it. 2016-11-15 15:17:55 <^7heo> I'm checking that. 2016-11-15 15:18:04 i just reviewed terraform pr 2016-11-15 15:18:05 <^7heo> as with ruby, it might very well depending on the version. 2016-11-15 15:18:19 it results in a 150mb binary 2016-11-15 15:18:32 with strip it cuts it 50% 2016-11-15 15:18:55 <^7heo> according to the comments on https://donatstudios.com/Golang-Binary-Sizes 2016-11-15 15:19:00 <^7heo> "Finally, please don't strip your binaries; it isn't supported, isn't tested and is known to produce broken executables." 2016-11-15 15:19:11 <^7heo> on Dec. 4, 2013 2016-11-15 15:19:17 <^7heo> But it's 3 years ago. 2016-11-15 15:19:19 <^7heo> so... 2016-11-15 15:19:49 what is the defenition of "broken executables" 2016-11-15 15:19:56 --help works fine 2016-11-15 15:20:03 is that a proper testcase? :) 2016-11-15 15:20:12 <^7heo> not really. 2016-11-15 15:20:19 <^7heo> --help usually only involves the libc. 2016-11-15 15:20:43 well if we can cut 50% of file size, we could atleast try it. 2016-11-15 15:24:51 <^7heo> are we stripping programs automatically after build? 2016-11-15 15:25:26 yes 2016-11-15 15:25:58 <^7heo> go build -ldflags "-s" should yield a stripped binary 2016-11-15 15:26:18 kind of 2016-11-15 15:26:28 <^7heo> and since there are reports of go producing broken executables, we should at least document somewhere that go packages shall use that go build command in case they break. 2016-11-15 15:26:31 <^7heo> along with !strip 2016-11-15 15:27:07 <^7heo> could we one day use some markdown-git-friendly wiki engine 2016-11-15 15:27:08 <^7heo> ? 2016-11-15 15:27:16 <^7heo> instead of requiring devs to all have a browser installed? 2016-11-15 15:27:30 <^7heo> I mean, honestly... 2016-11-15 15:27:34 we should also break abuild if one tries to use go install 2016-11-15 15:27:47 <^7heo> and go fix. 2016-11-15 15:27:56 yes 2016-11-15 15:28:04 <^7heo> c.f. the suggestion I have made in an (AFAIK open) issue. 2016-11-15 15:28:09 im going to write instructions on the wiki (when i get time) 2016-11-15 15:28:37 seems more and more projects are including deps in vendor. 2016-11-15 15:28:54 <^7heo> but about the wiki problem: what are the odds of a valuable contribution to the wiki being missed because it doesn't have HTTP editing vs the ones of missing a valuable contribution because it doesn't have git/markdown editing? 2016-11-15 15:29:18 <^7heo> IMHO we're missing a LOT of contributions because it requires HTTP editing. 2016-11-15 15:29:32 i have no idea 2016-11-15 15:29:33 <^7heo> I know I would contribute a lot more if it was via git. 2016-11-15 15:29:54 <^7heo> and it could be mirrored in gh like we do for many git repos 2016-11-15 15:30:01 <^7heo> and people could open PRs 2016-11-15 15:30:02 i think we should split wiki and docs 2016-11-15 15:30:12 <^7heo> so we would have a chance of reviewing the doc' before it goes in. 2016-11-15 15:30:22 <^7heo> clandmeter: then why have a wiki at all? 2016-11-15 15:30:58 <^7heo> I'd personally use Pelican to generate the pages 2016-11-15 15:31:08 my idea was to have docs.a.o to have some kind of official developers docs. 2016-11-15 15:31:18 <^7heo> yeah that would be great. 2016-11-15 15:31:30 <^7heo> with pelican we could have that written in markdown 2016-11-15 15:31:45 thats python right? 2016-11-15 15:31:47 <^7heo> yes. 2016-11-15 15:31:50 <^7heo> and automatically published on post-receive. 2016-11-15 15:32:02 <^7heo> that's what I'm using for my website. 2016-11-15 15:33:11 <^7heo> clandmeter: usually to deploy Pelican projects, I do: 2016-11-15 15:33:17 <^7heo> git init 2016-11-15 15:33:25 <^7heo> wget $virtualenv 2016-11-15 15:33:38 <^7heo> tar zxf virtualenv* 2016-11-15 15:33:49 <^7heo> virtualenv*/virtualenv.py pelican 2016-11-15 15:33:58 <^7heo> rm -r virtualenv* 2016-11-15 15:34:12 <^7heo> pelican/bin/pip install pelican markdown 2016-11-15 15:34:14 <^7heo> git add . 2016-11-15 15:34:15 "Pelican" is an anagram of calepin, which means "notebook" in French. 2016-11-15 15:34:19 <^7heo> yes. 2016-11-15 15:34:24 french... 2016-11-15 15:34:27 <^7heo> what? 2016-11-15 15:34:46 <^7heo> that must be the FIRST french technology I knowlingly use. 2016-11-15 15:34:56 <^7heo> s/knowli/knowi/ 2016-11-15 15:35:10 you don't use s6? I am disappoint. 2016-11-15 15:35:18 <^7heo> No I don't *yet* 2016-11-15 15:35:26 <^7heo> But I'll be glad to. 2016-11-15 15:35:28 also, clandmeter: "pélican" is also the french word for... pelican. 2016-11-15 15:35:36 <^7heo> :P 2016-11-15 15:35:42 <^7heo> ok, resuming with the listing: 2016-11-15 15:35:52 <^7heo> git commit -am "adding pelican" 2016-11-15 15:36:10 <^7heo> mkdir content 2016-11-15 15:36:24 <^7heo> echo "foo" > content/first_post.md 2016-11-15 15:36:37 <^7heo> pelican/bin/pelican-quickstart 2016-11-15 15:36:45 <^7heo> ... (answering questions) 2016-11-15 15:36:50 <^7heo> pelican 2016-11-15 15:36:56 I just do "generate_blog" 2016-11-15 15:37:00 <^7heo> # --- Done --- 2016-11-15 15:37:01 cause I'm lazy 2016-11-15 15:37:15 <^7heo> coredumb: also because you didnt' read what I wrote. 2016-11-15 15:37:21 <^7heo> s/t'/'t/ 2016-11-15 15:37:33 ^7heo: yeah that's funnier that way \o/ 2016-11-15 15:37:56 <^7heo> coredumb: I was actually describing the process of installing pelican in a virtualenv without root rights. 2016-11-15 15:39:20 <^7heo> Anyway 2016-11-15 15:39:27 skarnet: right, i didnt know that, but i dont speak french so i guess thats as expected. 2016-11-15 15:39:29 <^7heo> git published docs PLEASE. 2016-11-15 15:40:03 that would be cool 2016-11-15 15:40:15 ^7heo: so for the git noob, how would they contribute? 2016-11-15 15:40:21 and you can use something else than pelican either 2016-11-15 15:40:47 as I know you love Go that much you could use hugo for that 2016-11-15 15:42:18 <^7heo> clandmeter: github. 2016-11-15 15:42:24 <^7heo> clandmeter: github is really noob friendly. 2016-11-15 15:42:30 <^7heo> clandmeter: there even are go developers using it. 2016-11-15 15:43:33 not everybody that wants to contribure docs is a developer 2016-11-15 15:44:31 you don't have to be a dev to use git either 2016-11-15 15:46:03 It's easier to "use" Git than to install Alpine on a LVM + cryptsetup right 2016-11-15 15:47:32 <^7heo> clandmeter: again 2016-11-15 15:47:39 <^7heo> clandmeter: not every developer is contributing atm. 2016-11-15 15:47:46 <^7heo> clandmeter: because the HTTP barrier is a thing too. 2016-11-15 15:48:08 if you have a solution that can work both ways, im all for it. 2016-11-15 15:48:12 <^7heo> and what coredumb said is valid. 2016-11-15 15:48:21 <^7heo> clandmeter: I have one, but it's hacky as fuck. 2016-11-15 15:48:25 <^7heo> and in perl. 2016-11-15 15:48:29 <^7heo> still interested? 2016-11-15 15:48:34 ACTION blacklists ^7heo  2016-11-15 15:48:37 <^7heo> :D 2016-11-15 15:49:32 <^7heo> clandmeter: https://en.wikipedia.org/wiki/Ikiwiki 2016-11-15 15:49:37 <^7heo> clandmeter: just in case. 2016-11-15 15:57:51 Uh, our Hackspace used to have Wordpress that got replaced by Jekyll. Since then a lot of the content contribution stagnated since it's more complicated for the active writers to publish with their favourite text editor and git instead of a stupid text box in a stupid browser… thats my sad experience on that topic :-/ 2016-11-15 15:58:41 jomat: and I believe you 2016-11-15 15:59:04 And I wouldn't do that in all community 2016-11-15 15:59:40 but in the Alpine's community users must be fairly fluent in Git 2016-11-15 16:00:03 I'm not including Alpine's user through docker images though :D 2016-11-15 16:00:20 :-) 2016-11-15 16:02:38 And everything else is on Git 2016-11-15 16:02:46 that would make sense 2016-11-15 16:03:27 clandmeter: don't you have some stats about ppl that contribute to wiki/docs but never to anything in one of Alpine's Git repos ? 2016-11-15 16:03:46 we dont collect stats ;-) 2016-11-15 16:06:07 go in your DB and extract them then :) 2016-11-15 16:06:55 not my db :p 2016-11-15 16:13:50 coredumb: but from the top of my head, many users i see on wiki ive never seen in git. 2016-11-15 17:28:41 i seem to have lost my arrow keys 2016-11-15 17:28:48 new AL install 2016-11-15 17:28:55 anyone seem that before? 2016-11-15 17:30:10 they work fine in a tty, but in X they don't work. I use xsetkbmap to set my keyboard. works across all AL installs i have where i use X11 except this latest RPi install 2016-11-15 17:30:29 wierd 2016-11-15 17:31:17 i wonder if there is a broken/missing keymap 2016-11-15 17:32:12 ah, model is different 2016-11-15 17:34:05 xkb_symbols that work are "pc+gb+inet(evdev)", xkb_symbols that don't work are "pc+gb+inet(pc105)" 2016-11-15 19:33:59 ncopa: do you prefer that new aports are sent to the ml? 2016-11-15 19:44:27 does not really matter to me. github pr is also ok 2016-11-15 19:44:49 i am currently on vacation so i depend on someone else to look at it atm 2016-11-15 20:07:52 dsabogal: have you talked with Michael Zhou about taking over mupdf? 2016-11-15 20:15:42 ncopa: yes, i can forward the email if you'd like 2016-11-15 20:27:23 what's the best way to create a post-install message for an aport currently? Simply writting to stdout out a post-install script? 2016-11-15 20:27:42 s/stdout out a/stdout in a/ 2016-11-15 20:28:59 dsabogal: no its ok. i just push it. thanks 2016-11-15 20:40:14 ncopa: btw: are there any critical issues left for 3.5? Do we want to fix #6072 and #6029 before releasing 3.5? 2016-11-15 20:41:39 i thought i fixed #6072 2016-11-15 20:42:09 sorry didn't notice that 2016-11-15 20:42:18 those two issues where still on my list 2016-11-15 20:43:28 also #6029 may have been fixed by the recent piemode patch changes 2016-11-16 09:59:48 fabled: should we prevent stripping of Go bins? 2016-11-16 11:11:59 clandmeter, does it break stuff? 2016-11-16 11:12:36 fabled: im not sure, i see some references not to do it, but they are old. 2016-11-16 11:14:08 fabled: i see some packages have !strip which i dont personally use. i wouldnt really care but it does decrease the size of the bins by 50%. 2016-11-16 11:14:33 if -dbg subpkg is enabled stripping is also disabled 2016-11-16 11:18:59 Strip them all and see what happens! 2016-11-16 11:18:59 (I mean binaries! Of course.) 2016-11-16 11:19:43 skarnet: i tend to agree with you on #1 2016-11-16 11:22:23 you naughty one, you. 2016-11-16 11:23:13 and hungry 2016-11-16 11:23:59 lunch time! 2016-11-16 15:15:45 fabled: where did you go? I was just typing a question for you! 2016-11-16 15:16:47 ACTION is having problems with mini_httpd again 2016-11-16 15:17:01 ACTION set up a private repository using mini_httpd 2016-11-16 15:17:14 apk fetch and wget get different binaries 2016-11-16 15:17:28 the version from apk is corrupted and won't install 2016-11-16 15:21:03 fabled: you're back 2016-11-16 15:21:17 any chance you can read the backlog from when you were gone? 2016-11-16 15:21:49 ACTION set up a private repository with mini_httpd 2016-11-16 15:22:03 wget works fine, but apk fetch results in 0-byte file for one package 2016-11-16 15:22:15 repo is on edge latest 2016-11-16 15:26:51 also strange is that 'apk add' will install the package dependencies, which means that it downloads at least part of the package 2016-11-16 15:26:56 but then it fails the install 2016-11-16 15:27:31 ACTION wonders if mini_httpd has another bug with binary \0, but this time not for cgi 2016-11-16 15:34:16 hm, maybe it's a problem with apk, and not with mini_httpd, because it fails with lighttpd too 2016-11-16 15:37:22 ncopa: hi 2016-11-16 15:38:14 test:~# apk fetch -v blah 2016-11-16 15:38:14 Downloading blah-0.1.0-r0 2016-11-16 15:38:14 ERROR: blah-0.1.0-r0: No such file or directory 2016-11-16 15:38:54 how can I debug the above? because apk works for all other binaries on the repo and wget works fine for this file 2016-11-16 15:39:39 does blah provide files? 2016-11-16 15:39:44 or it's just meta package? 2016-11-16 15:39:47 yes 2016-11-16 15:40:08 are we ready for rc1? 2016-11-16 15:40:15 i have one or twho hours at disposal 2016-11-16 15:40:16 ncopa, i think so 2016-11-16 15:41:08 ACTION will stop asking about apk until release is done 2016-11-16 15:41:09 ncopa, sch-cake-grsec was requested for community 2016-11-16 15:41:13 priorities :D 2016-11-16 15:41:18 but i guess it can wait for rc2 2016-11-16 15:48:13 its in testing? 2016-11-16 15:48:54 hum 2016-11-16 15:49:05 sch-cake has 0 releases 2016-11-16 15:49:19 we'd end up maintaining a random git snapshot 2016-11-16 15:49:39 otoh, kernel should be stable 2016-11-16 15:57:35 can you please hold your git pushes for a while 2016-11-16 15:57:40 while i do the rc1 tag 2016-11-16 15:57:48 and verify that it goes all ok 2016-11-16 16:22:51 we should write some release notes for rc1 2016-11-16 16:23:04 any suggestsions what we should include? 2016-11-16 16:26:15 2016-11-16 16:29:46 tdtrask, sorry that i dont have time to follow up that now... i'm not at the office and very limited time :-( 2016-11-16 16:29:55 and bad wifi 2016-11-16 16:32:22 ACTION booted RC1 x86_64 in VirtualBox - boots but repeated "ERROR: modloop failed to start" 2016-11-16 16:32:35 ncopa: no problem, I understand 2016-11-16 16:33:33 ncopa: aarch64 :D 2016-11-16 16:33:44 ncopa: new website 2016-11-16 16:34:26 need to update "welcome to alpine 3.4" and 3.4 in repositories file after setup-alpine 2016-11-16 16:35:23 and /etc/alpine-release 2016-11-16 16:37:36 hm, fails to 'apk update' from 'http://rsync.alpinelinux.org/alpine/v3.5/main' 2016-11-16 16:38:07 probably because no networking :( 2016-11-16 16:38:42 argh 2016-11-16 16:38:53 thats because i tagged wrong 2016-11-16 16:38:59 difficult to focus here... 2016-11-16 16:39:31 ACTION didn't notice that setup-alpine doesn't ask about networking, just manual updates 2016-11-16 16:40:15 ncopa: should I keep testing? or wait for now? 2016-11-16 16:40:16 i think thats because there is an apkovl that shouldnt be there 2016-11-16 16:40:33 sounds like i need to do rc2 now... 2016-11-16 16:41:44 yeah, apkovl file in root of iso :`( 2016-11-16 16:41:47 sorry ncopa 2016-11-16 16:42:38 well, thats why we do release candidates 2016-11-16 16:46:10 <^7heo> yep 2016-11-16 16:46:13 <^7heo> (Hallo ncopa) 2016-11-16 16:46:50 hi 2016-11-16 16:47:22 ^7heo what is the status of the detached header thingy for nlplug-findfs? 2016-11-16 16:47:31 <^7heo> dormant. 2016-11-16 16:47:39 <^7heo> I'm swamped atm 2016-11-16 16:47:43 <^7heo> like, fucking swamped. 2016-11-16 16:49:45 <^7heo> but I'm looking forward to finishing it. 2016-11-16 16:51:29 the last patchset you sent me, (which i worked on) is that close to what you got? 2016-11-16 16:54:41 <^7heo> nope 2016-11-16 16:54:43 <^7heo> I fixed more stuff 2016-11-16 16:55:03 <^7heo> but really, I can't allocate brain time to that atm 2016-11-16 16:59:09 ^7heo, can you send me an email with what you got? incremental patch, or just a diff 2016-11-16 17:00:50 <^7heo> nope, because I have issues that I didn't finish solving. 2016-11-16 17:00:54 ok 2016-11-16 17:00:56 <^7heo> but look 2016-11-16 17:01:03 <^7heo> I can work on it next w-e 2016-11-16 17:01:05 <^7heo> I guess 2016-11-16 17:01:25 would be nice, but dont stress with it 2016-11-16 17:02:43 clandmeter: can you try coordinate a release notes for 3.5? you can copy 3.4.0 release notes as start 2016-11-16 17:04:19 hum 2016-11-16 17:04:24 there are no aarch64 release 2016-11-16 17:05:00 fabled, can you please check why aarch64 didnt get release? just so we make sure rc3 also has aarch64 2016-11-16 17:05:07 no stress though 2016-11-16 17:05:20 ncopa, i think we don't have any image format supporting aarch64 yet 2016-11-16 17:05:46 tar.gz? 2016-11-16 17:05:48 will that do? 2016-11-16 17:06:12 btw 2016-11-16 17:06:20 are there any cheap aarch64 platform? 2016-11-16 17:07:08 i think we want the uefi one 2016-11-16 17:07:14 clandmeter had idea on it 2016-11-16 17:07:36 ok 2016-11-16 17:07:49 can someone just verify that rc2 is not totally broken too? 2016-11-16 17:07:56 tdtrask, do you have time to verify? 2016-11-16 17:08:09 i am on a 1Mbit connection here... 2016-11-16 17:10:31 ncopa: alpine-vanilla-3.5.0_rc2-x86_64.iso -broken ( /boot/vmlinuz-vanilla failed: No such file or directory) 2016-11-16 17:10:56 ok, thanks 2016-11-16 17:11:03 does the standard work? 2016-11-16 17:12:32 looks good ( modloop failed x3 ) 2016-11-16 17:12:49 fabled: i think update-kernel creates syslinux config with "vmlinuz-vanilla" while the linux-vanilla package uses "vmlinuz" alone. not sure what we want do there 2016-11-16 17:13:13 we can either make linux-vanilla package ship kernel as boot/vmlinuz-vanilla or we will have to specialcase the linux-vanilla kernel flavor 2016-11-16 17:14:15 m4: do you think you could file a bug for linux-vanilla iso? 2016-11-16 17:14:45 i need to go 2016-11-16 17:19:01 ncopa: sorry , still don't have acc @bugs.alpine ;) 2016-11-16 17:19:26 ok maybe someone else can help with that then 2016-11-16 17:19:31 thanks for testing though. 2016-11-16 17:19:32 see u 2016-11-16 17:27:45 testing rc2: 2016-11-16 17:28:09 (standard x86_64) 2016-11-16 17:28:15 modloop failures again 2016-11-16 17:30:26 now says 3.5 in "Welcome to Alpine Linux" and in alpine-release 2016-11-16 17:30:43 setup-alpine does not ask for configuring interfaces (just manual) 2016-11-16 17:38:44 can't add modules as /lib/modules is missing 2016-11-16 18:18:46 can you add zfs-vanilla for x86_64 ? ( exists for x86 & aarch64 ) 2016-11-16 20:12:33 3.5.0_rc2 is definitely broken on x86_64 2016-11-16 20:12:46 modloop must be generated incorrectly 2016-11-16 20:13:02 works fine on x86 image 2016-11-17 05:32:39 fabled , ncopa re: sch-cake <- not some random source - github dtaht -- offical repo for https://www.bufferbloat.net/projects/codel/wiki/Cake/ 2016-11-17 05:33:41 mixing stable Alpine + edge/testing pkg works very well but with one significant limit 2016-11-17 05:33:53 we can't mix packages with kernel modules which then leads to have own repo.... 2016-11-17 10:31:05 hi, everyone! 2016-11-17 10:31:29 <^7heo> yo 2016-11-17 10:32:01 fabled: re aports 7f4d842ad53d, busybox works fine, POSIX BRE does not have alternation, it's GNU-ism extension to support it via \| 2016-11-17 10:32:40 it's almost always better to use ERE, in case of sed with -r option, then expressions usually get shorter. 2016-11-17 10:33:41 instead of (incorrect POSIX-wise) sed 's,\(^/\|\)[^/][^/]*,..,g' you can write sed -r 's,(^/|)[^/][^/]*,..,g' 2016-11-17 10:39:00 http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html#tag_09 <- Regular Expressions from POSIX.1-2008 (IEEE Std 1003.1-2008, 2016 Edition) 2016-11-17 10:39:17 (link just for the completeness) 2016-11-17 10:45:51 przemoc, ah, thanks 2016-11-17 10:46:10 it seems we had some sed-ere patch for kmod earlier. but i dunno why it was removed 2016-11-17 10:46:41 removal should be explained in commit, I guess 2016-11-17 10:48:23 przemoc, unfortunately no, it was just removed in regular package version upgrade. i guess by mistake. 2016-11-17 10:48:34 I see, ncopa did it 2016-11-17 10:48:53 I know he likes to sneak multiple changes in one commit. ;) 2016-11-17 10:49:33 possibly it was "it works w/o patch for me, let's remove it along the way." 2016-11-17 10:49:45 yeah 2016-11-17 10:56:09 sadly POSIX sed does not support ERE, but it's quite common extension. I think -E (as was used in original patch) is canonical option for enabling ERE in many implementations, -r is GNU-origin IIRC, but became rather widely supported too. at least GNU sed supports -E too, but it's not mentioned in --help or man page. 2016-11-17 11:03:30 one more thing I forgot to mention earlier. actually if ERE is used, you can simplify expression from the patch to 's,(^/)?[^/]+,..,g' which is much easier on eyes 2016-11-17 11:09:40 I hate how whenever I'm starting to find some time for AL, it's such late in release cycle. :( I'd love to get rhash into testing and moved to community before 3.5 release, but it looks it's rather too late for that. one of the few sane hashers. 2016-11-17 11:14:09 przemoc: did you submit a pr/patch? 2016-11-17 11:14:29 yes, to aports ML 2016-11-17 11:14:36 :| 2016-11-17 11:15:01 why :|? 2016-11-17 11:15:07 is aports ML deprecated now? 2016-11-17 11:15:20 some people want to make it so 2016-11-17 11:15:46 paste me the patch 2016-11-17 11:15:55 clandmeter, http://patchwork.alpinelinux.org/patch/2555/ 2016-11-17 11:16:34 thx 2016-11-17 11:16:36 ill add it 2016-11-17 11:16:39 but i dont like pw 2016-11-17 11:16:47 when i amend it would auto close 2016-11-17 11:16:52 which gives me a headache 2016-11-17 11:17:09 s/would/wont 2016-11-17 11:19:35 thx, but if ML and PW are bad, what is acceptable? only github? while I have nothing against GH per se, I think ML is more scalable even if less nice looking 2016-11-17 11:20:02 creating something with the same feature set and i will use it. 2016-11-17 11:20:10 im not on linux 2016-11-17 11:20:37 oh, that's a bummer indeed 2016-11-17 11:23:17 the CI integration is also handy in github 2016-11-17 11:23:36 all in all its better for me then ML+PW 2016-11-17 11:24:08 and im the one that setup PW, but I find it troublesome... 2016-11-17 11:26:09 I see. maybe you could write to patchwork devs/ML with some feature request that you find really lacking. IIRC in the past they used to be open for improvements, or so I heard. 2016-11-17 11:26:32 does AL's aports GH CI supports building on aarch64? 2016-11-17 11:26:41 nope 2016-11-17 11:26:52 we could only do that if we setup our own CI 2016-11-17 11:27:05 fabled has some ideas 2016-11-17 11:27:12 time is the problem 2016-11-17 11:27:46 przemoc: can you test the pkg in testing? 2016-11-17 11:28:03 if it works, ill move it. 2016-11-17 11:31:43 time is always the problem. :) I can test it in testing on x86_64 only right now, I'm actually already using my own build from testing in 3.4 for some time. 2016-11-17 12:58:42 where were the logs from building stored? was it http://build.alpinelinux.org/? what path? 2016-11-17 13:00:30 ah, it was /buildlogs/ 2016-11-17 14:27:04 ACTION slaps _ikke_ with a dark table 2016-11-17 14:27:39 <_ikke_> Why did I deserve that? :P 2016-11-17 14:27:55 yes :p 2016-11-17 14:28:04 not properly setting cmake vars 2016-11-17 14:28:10 <_ikke_> Ah 2016-11-17 14:28:16 <_ikke_> Please enlighten me 2016-11-17 14:28:32 <_ikke_> Or was that what jirutka added to the PR? 2016-11-17 14:29:18 <_ikke_> I still need to work on that (I have an update also to the latest RC) 2016-11-17 14:29:52 http://tpaste.us/Gxvr 2016-11-17 14:30:10 <_ikke_> Ah, those 2016-11-17 14:30:12 <_ikke_> ok 2016-11-17 14:30:29 and you dep on pugixml-dev when it doesnt have the dev pkg anymore 2016-11-17 14:30:37 i guess you accidently removed it when cleaning it up 2016-11-17 14:30:38 <_ikke_> Right, that was left over 2016-11-17 14:30:56 i can commit it like this 2016-11-17 14:31:01 <_ikke_> I first did a separate pugixml-dev package, but the root package became empty 2016-11-17 14:31:12 that shouldnt 2016-11-17 14:31:19 <_ikke_> It's only a lib 2016-11-17 14:31:20 it should keep the libs 2016-11-17 14:31:32 libs go in main pkg, the rest in -dev 2016-11-17 14:31:32 <_ikke_> was on advise of ncopa 2016-11-17 14:31:34 <_ikke_> right 2016-11-17 14:31:49 we dont want to ship the cmake files in regular pkg 2016-11-17 14:32:11 you problably mean -libs pkg? 2016-11-17 14:32:19 hi 2016-11-17 14:32:24 that would make no sense in this case 2016-11-17 14:32:27 does the pkg ship shared libs at all? 2016-11-17 14:32:39 yes, it is only just that 2016-11-17 14:33:02 but it has no header files 2016-11-17 14:33:15 else abuild would have borked 2016-11-17 14:34:01 and exit 1 probably doest work. 2016-11-17 14:34:25 <_ikke_> yeah, that's what jirutka already said. Was meant to use return indeed 2016-11-17 14:34:58 going to pus hit now 2016-11-17 14:35:22 <_ikke_> ok 2016-11-17 14:38:40 _ikke_: if you dont set lib dir, it will install in lib64. 2016-11-17 14:39:02 <_ikke_> but alpine only uses /lib? 2016-11-17 14:39:04 i think we should have abuild check we dont use multiarch lib directory 2016-11-17 14:39:40 and check for c++ header files 2016-11-17 14:40:51 http://pkgs.alpinelinux.org/contents?file=&path=%2Fusr%2Flib64* 2016-11-17 14:43:29 isnt there an inverted search filter option in github? 2016-11-17 15:39:15 hi guys, what if i need to use more than one users in fixing permissions in APKBUILD? 2016-11-17 15:39:16 e.g. 2016-11-17 15:39:20 pkgusers="foo" 2016-11-17 15:39:57 then in package() i can fix permission with chown $pkgusers $pkgdir/dir 2016-11-17 15:40:22 what if i have multiple dir where to change permission, with different users? 2016-11-17 15:40:31 pkgusers="foo bar" 2016-11-17 15:40:49 chown $pkgusers $pkgdir/dir1 2016-11-17 15:40:51 chown $pkgusers $pkgdir/dir2 2016-11-17 15:41:07 but for dir1 i need foo 2016-11-17 15:41:10 for dir 2 i need bar 2016-11-17 15:41:30 should/can i use, rather: 2016-11-17 15:41:37 pkgusers="foo" 2016-11-17 15:41:41 _pkgusers="bar" 2016-11-17 15:41:51 and then : 2016-11-17 15:41:53 chown $pkgusers $pkgdir/dir1 2016-11-17 15:41:57 chown $_pkgusers $pkgdir/dir2 2016-11-17 15:41:58 ? 2016-11-17 15:42:50 No, this can't work 2016-11-17 15:44:02 of course i can access to the individual entries in $pkgusers with substring, but i'm wondering if there's a better approach 2016-11-17 15:46:14 umh 2016-11-17 15:46:18 I can use set -- 2016-11-17 15:46:58 ok that's the way 2016-11-17 17:01:33 przemoc: “[12:19:35] przemoc: …while I have nothing against GH per se, I think ML is more scalable even if less nice looking” – no, it’s not more scalable, just opposite, it’s total nightmare for us, maintainers; I understand fear from too strong dependency on third-party commercial service, but it’s still much lower risk than that maintainers will burn out just because of suffer and waste of time with bad tools like Patchwork and 2016-11-17 17:01:33 lack of automation 2016-11-17 17:05:34 the clear solution is better automation for the ml (or whatever workflow that does not involve a 3rd-party commercial service) 2016-11-17 17:06:29 jirutka: what are the GH features you're relying on for the automated backend? can you estimate how much work would be needed to plug another frontend onto it ? 2016-11-17 17:06:32 skarnet: I’m still waiting for you to do that… 2016-11-17 17:07:05 skarnet: you didn’t, no one else did it, so please stop complaining against GH that works much better for us, and it’s not just about CI 2016-11-17 17:07:23 we have much bigger problems in Alpine than that 2016-11-17 17:08:43 that's a question of point of view 2016-11-17 17:08:58 but anyway I'm not insisting that it should be done *now* 2016-11-17 17:09:10 skarnet: have you ever looked into Patchwork’s API? I did and I resigned to do anything with that, b/c it’s totally unusable 2016-11-17 17:09:36 ok, so let's drop patchwork, who cares - I'm interested in any other solution 2016-11-17 17:09:42 me too 2016-11-17 17:10:09 that's why I'm asking about what you did for the GH backend 2016-11-17 17:10:11 oh crap, I forgot to finish that thesis topic for this tool 2016-11-17 17:10:18 I wanted to make some student do that :P 2016-11-17 17:10:30 all code is in abuild repo, you can look into it yourself 2016-11-17 17:11:00 it is, I presume, perfectly clear and well-documented 2016-11-17 17:11:14 yes, it is, b/c it’s just few lines of shell 2016-11-17 17:11:23 ok then :) 2016-11-17 17:11:24 with documentation comments where needed 2016-11-17 17:11:47 but the key is that we use GH and Travis features that Patchwork simply doesn’t provide… 2016-11-17 17:13:45 skarnet: and that problem with closing already merged patches, we use this https://github.com/jirutka/github-pr-closer 2016-11-17 17:14:07 skarnet: again it depends on features in API that Patchwork does not provide 2016-11-17 17:14:21 like webhooks 2016-11-17 17:14:51 I need to go, I’m painting the ceiling 2016-11-17 17:15:03 good luck scrubbing your arm afterwards 2016-11-17 17:15:31 yeah… it’s horrible job 2016-11-17 17:16:13 s/job/work/ 2016-11-17 17:16:15 I know, I thoroughly washed my bathroom ceiling this summer and I got back ache for the following 7 days 2016-11-17 17:16:40 when it comes to painting it, I'll call a pro 2016-11-17 17:40:43 should #3845 be closed? this package was recently added to testing in e69bf6cc4cee02b6178d8cf25b93b31e39d8b5d4 2016-11-17 19:47:28 skarnet: could you please reply to https://github.com/alpinelinux/aports/pull/520#issuecomment-260903357 and suggest some solution? 2016-11-17 19:52:28 the best solution would be to contact the libressl team and ask them if there's a specific reason why libressl doesn't include accelerated support for nable-ec_nistp_64_gcc_128 2016-11-17 19:52:39 so we know whether it has a chance to be fixed soon or not 2016-11-17 19:55:34 skarnet: this sounds like a long term solution, but not short term 2016-11-17 19:56:22 I don't do short-term :P 2016-11-17 19:56:58 you want a short-term solution for me? embed the static openssl bunch o'libs into tor, nobody's gonna notice the difference anyway 2016-11-17 19:57:19 skarnet: well, so in other way, could you please respond to clandmeter why it’s not a good idea to have both libressl and openssl shared libs in the system? 2016-11-17 19:58:04 honestly I have no idea. Because of the openssl binary? Because of the /usr/include/openssl link? 2016-11-17 19:58:40 Because the libs have the same name and we can't have both because we're still using fucking FHS ? 2016-11-17 19:58:54 skarnet: what if tor loads some shared lib that is linked against libressl? 2016-11-17 19:59:06 skarnet: libressl and openssl provides the same symbols, right? 2016-11-17 19:59:16 in part, yes 2016-11-17 19:59:26 and they're _supposed_ to be compatible 2016-11-17 19:59:48 so I guess that bad thinks happen when you mix them in the same process 2016-11-17 20:00:05 IIRC that’s what ncopa wrote some time ago 2016-11-17 20:00:16 s/thinks/things/ 2016-11-17 20:00:17 indeed, that's a risk, but don't we have control over what tor dlopens? 2016-11-17 20:00:21 I guess not 2016-11-17 20:00:46 i dunno 2016-11-17 20:00:55 again, if you link tor against static openssl, the problem won't occur 2016-11-17 20:01:05 it's ugly, but that's short-term for you 2016-11-17 20:01:09 i agree 2016-11-17 20:01:17 static openssl would be a solution 2016-11-17 20:02:13 but clandmeter wants to know why shared openssl should not be used and I’m really not sure about it, I just remember that ncopa or someone else wrote that it’s not a good idea, something about same symbols etc, but I don’t understand this in depth 2016-11-17 20:03:18 ncopa is probably right 2016-11-17 20:03:40 normally I'd say "screw dlopen" but that's not really an option for web browsers 2016-11-17 20:04:52 also, my preferred answer to the OP would be "suck it up, eat the performance loss 2016-11-17 20:04:54 " 2016-11-17 20:05:06 but that's not good PR 2016-11-17 20:05:12 i still dont understand why they cannot be used together? the libs have diff name 2016-11-17 20:05:34 clandmeter: do they? libcrypto and libssl? 2016-11-17 20:05:47 I think i tried 2016-11-17 20:06:12 Did you try, or do you think you tried? 2016-11-17 20:08:13 i compiled it against openssl and installed it including all libressl pkgs 2016-11-17 20:08:52 that will work, until tor dlopens some shitty lib linked against libressl 2016-11-17 20:08:55 clandmeter: have you verified that tor does not link any lib linked against openssl? 2016-11-17 20:09:06 s/openssl/libressl/ 2016-11-17 20:09:28 jirutka: try it yourself :) 2016-11-17 20:10:23 clandmeter: well, I see that tor depends on libevent that is linked against libressl… 2016-11-17 20:10:43 how the fuck can an event library link against a SSL library 2016-11-17 20:11:27 i don’t have a fucking idea 2016-11-17 20:11:30 jirutka: i didnt digg into it deeply, its also not my expertise, thats why i asked :) 2016-11-17 20:11:39 but see yourself https://pkgs.alpinelinux.org/package/edge/main/x86_64/libevent 2016-11-17 20:11:53 clandmeter: me neither, I’ve just checked it on pkgs.a.o ;) 2016-11-17 20:12:18 i dont see a big issue here either 2016-11-17 20:12:25 just keep using libressl 2016-11-17 20:12:35 if somebody needs more power, let them fix it... 2016-11-17 20:13:02 Libevent additionally provides a sophisticated framework for buffered network IO, with support for sockets, filters, rate-limiting, SSL, zero-copy file transmission, and IOCP. Libevent includes support for several useful protocols, including DNS, HTTP, and a minimal RPC framework. 2016-11-17 20:13:09 feature creep much? 2016-11-17 20:13:57 skarnet: what a moment, it can’t prepare you a coffee?! how’s that possible?! 2016-11-17 20:14:09 we already have apk for that 2016-11-17 20:17:16 tss, every event library should do that! and also it does not support FTP, ICQ and ActiveSync XD 2016-11-17 20:18:13 unfortunately it’s used by 40 packages, so we probably can’t just remove TLS suppport from it 2016-11-17 20:19:12 it's ok, we can remove the 39 other packages 2016-11-17 20:19:14 jirutka: i think we can split it 2016-11-17 20:19:53 clandmeter: well, but the question is whether tor needs libevent with TLS 2016-11-17 20:20:15 10 bucks say it does 2016-11-17 20:21:04 luchtbucks? 2016-11-17 20:21:28 only _ikke_ will understand that one... 2016-11-17 20:22:14 skarnet: thanks for your comment! 2016-11-17 20:22:21 np 2016-11-17 20:22:23 sorry, i just consumed two beers. i should remove myself from the computer. 2016-11-17 20:22:34 lol, remove myself from the computer XD 2016-11-17 20:22:51 apk del clandmeter XD 2016-11-17 20:22:57 --purge 2016-11-17 20:23:09 cannot be removed, clandmeter is required by alpine 2016-11-17 20:23:48 is that what they call a hard dependency? 2016-11-17 20:23:53 :) 2016-11-17 20:24:44 speaking of openssl vs libressl 2016-11-17 20:24:46 ok, have fun guys fixing this. going to join my loved one. 2016-11-17 20:24:57 has anyone managed to make "openssl certhash" work? 2016-11-17 20:25:07 (it's libressl's replacement for c_rehash) 2016-11-17 20:25:13 have fun clandmeter! 2016-11-17 20:25:42 clandmeter: see ya! 2016-11-17 20:26:31 \me also would like to have a “loved one” *insert forever alone meme* 2016-11-17 20:26:38 oh crap 2016-11-17 20:26:40 ACTION also would like to have a “loved one” *insert forever alone meme* 2016-11-17 20:27:54 less packaging crap for Alpine, more working on your game and hanging in places where you have a chance of meeting women 2016-11-17 20:30:58 >more working on your game 2016-11-17 20:31:07 skarnet: what do you mean? 2016-11-17 20:31:13 oh, we are on -devel :x 2016-11-17 20:39:48 skarnet: working on my game? i’m not a game developer… 2016-11-17 20:41:00 https://wompwompwomp.com/ 2016-11-18 01:33:56 On a general note; use ip link or use brctl? 2016-11-18 01:39:47 I'm rather surprised that so many cli tools don't have a -m option for machine parseable output. 2016-11-18 01:39:59 And when they do, the format usually suck anyway. 2016-11-18 01:40:26 Imho it's often simpler to just parse what's in /sys/ and perhaps /proc. 2016-11-18 02:38:29 three ways how to compare version in POSIX shell http://paste.fedoraproject.org/484061/94366881/ :) 2016-11-18 02:39:18 I’m just insane, can’t stop until find the best solution (in this case the shortest and still reasonable correct) 2016-11-18 06:26:38 skarnet: :D 2016-11-18 08:01:02 hi climbers 2016-11-18 08:01:23 I'd like your suggestions about this: 2016-11-18 08:01:23 http://sprunge.us/RDfd 2016-11-18 08:01:57 i had to do that ugly _fixpermissions to have it a little bit more good-looking APKBUILD 2016-11-18 08:02:41 i'd like to have it in a script 2016-11-18 08:03:18 since ossec-hids actually have it, even if should be fixed for Alpine 2016-11-18 08:03:47 the script is this: http://sprunge.us/gBMD 2016-11-18 08:13:10 i need to "export" in the script the pkgusers and pkggroups 2016-11-18 08:16:42 how to do that? 2016-11-18 09:36:41 fcolista: what do you mean? making information seep back from a script to the caller? 2016-11-18 09:50:07 skarnet, i ended up in passing variables to install script 2016-11-18 09:50:20 http://sprunge.us/SLBb 2016-11-18 09:50:51 the install script of ossec-hids is not designed with packaging in mind 2016-11-18 09:50:55 so i've patched it: 2016-11-18 09:50:56 http://sprunge.us/ITDT 2016-11-18 09:52:00 well yes, makes sense. Passing variables to something you call is easy, I thought you had the opposite problem - getting variables FROM something you call - which is trickier. :) 2016-11-18 09:52:40 basically my problem is how to easily manage more than one "pkgusers" 2016-11-18 09:52:57 and i've done with set -- $pkgusers 2016-11-18 09:53:23 once i can access directly to each one of those entries, then that would be easire 2016-11-18 09:53:28 *easier 2016-11-18 09:55:19 I would pass $pkgdir and $pkggroups first, then you can use "$@" and pass an arbitrary number of pkgusers 2016-11-18 09:57:17 skarnet, can you please make an example? 2016-11-18 09:57:56 I would not try to package it in the first place... 2016-11-18 09:59:15 but its almost weekend, so who cares :D 2016-11-18 09:59:47 https://linux.die.net/man/1/ash 2016-11-18 10:00:07 in the APKBUILD: ./InstallServer.sh $pkgdir $pkggroups "$@" 2016-11-18 10:00:33 yes 2016-11-18 10:00:40 im trying to write a contributors.md so ppl can start submitting proper PR's (but i suck at writing docs) 2016-11-18 10:00:45 figured from https://linux.die.net/man/1/ash 2016-11-18 10:00:51 in the InstallServer.sh script: DIR=$1/var/ossec; GROUP=$2; shift 2; 2016-11-18 10:00:58 and then all your args are users 2016-11-18 10:01:51 shift 2: what does it do? 2016-11-18 10:02:10 turns $3 into $1, $4 into $2 and so on 2016-11-18 10:02:12 I can use $3, $4 and $5 2016-11-18 10:02:26 ah 2016-11-18 10:02:27 ok 2016-11-18 10:02:31 sure you can, but you can't loop over $@ 2016-11-18 10:02:38 after a shift you can 2016-11-18 10:02:55 if you know you'll only ever have 3 users, don't change anything 2016-11-18 10:03:10 but if you need more, looping over $@ is the way to go 2016-11-18 10:03:26 I know i'll ever have 3 users, but is good to know that 2016-11-18 10:03:35 I never used those expansions in sheel 2016-11-18 10:27:58 clandmeter, which board are you using for aarch64 build environment? 2016-11-18 10:35:46 thunderx 2016-11-18 10:36:53 go ahead and post your twitter link 2016-11-18 10:36:58 we all know you want to 2016-11-18 10:40:14 :D 2016-11-18 12:06:20 skarnet: actually I was waiting for it :< 2016-11-18 13:23:23 ... 2016-11-18 13:23:25 umh.. 2016-11-18 13:23:26 abuild checksum 2016-11-18 13:23:26 abuild-fetch: unrecognized option: 0 2016-11-18 13:23:26 Unkonwn option '?' 2016-11-18 13:23:33 it's only me? 2016-11-18 13:25:33 Yes it's only me 2016-11-18 13:25:34 nevermind 2016-11-18 13:26:36 <^7heo> can do. 2016-11-18 14:54:07 hmm, booting a rpi fails with "can't run /sbin/openrc': nsfod" 2016-11-18 14:54:24 looks like init isn't unpacking the apks 2016-11-18 14:55:22 anyone seen something like that before? 2016-11-18 14:56:42 I'll try reducing the memory allocated to the gpu 2016-11-18 21:36:52 _ikke_: hey. i may be reading the output wrong. is darktable-dev a separate package? https://pkgs.alpinelinux.org/contents?branch=edge&name=darktable-dev&arch=x86&repo=testing 2016-11-18 21:37:02 that header really really should be in main package 2016-11-18 21:38:45 it's used by all the opencl programs, which are installed by main package, see https://github.com/darktable-org/darktable/blob/master/data/kernels/basic.cl#L21 2016-11-19 00:22:12 bashism in configure.ac, what kind of fucking idiot can do that?! https://github.com/acassen/keepalived/blob/512e2d324b9ebad5fb4b415a1361f1cab5efa6ec/configure.ac#L426 2016-11-19 00:25:30 what is a proper reaction into bug report for this? i think that “you fucking retards” is very polite for this… 2016-11-19 00:46:59 go nuts! 2016-11-19 00:53:05 =) 2016-11-19 01:10:24 can someone explain what is happening here: http://pastebin.com/QRC5ANaS ? i am trying to build a package for geoclue2. i have dependencies like networkmanager and when trying to abuild networkmanager i am getting exactly the same error... 2016-11-19 01:10:54 i wanted to say, that i have the same deps like in networkmanager... 2016-11-19 01:11:59 i needed to switch arch="" to arch="all" in networkmanager APKBUILD to test. 2016-11-19 01:16:20 this is my APKBUILD file: http://pastebin.com/pXuu1pBX 2016-11-19 01:19:04 generated changelogs are evil, totally useless 2016-11-19 01:19:59 hanez: i have no idea 2016-11-19 01:20:15 hanez: ofc, arch="" basically means taht the package is not build for any arch, i.e. it’s disabled ;) 2016-11-19 01:20:51 jirutka: okay, may because of the same problem. i wonder why it is in community then... ? 2016-11-19 01:21:57 hanez: well… probably someone hoped that (s)he will fix it and din’t want to move it into unmaintained 2016-11-19 01:22:22 ok, i will try to figure that out and fix networkmanager too... ;) 2016-11-19 01:22:39 thx anyway 2016-11-19 01:23:51 i really do not like al that fredesktop stuff but when using redshift it is nice to set the location by geoclue... 2016-11-19 01:25:47 you can contact author of NetworkManager if you need help, it’s pavlix on Freenode 2016-11-19 01:25:55 I know him in person 2016-11-19 01:26:22 s/it’s/he’s/ :P 2016-11-19 01:27:03 jirutka: oh, good idea. i will give it a try... ;) 2016-11-19 01:27:48 btw. are some alpine dev at chaos congress in hamburg this year? 2016-11-19 01:28:52 dunno :/ 2016-11-19 01:59:03 My head is exploding. 2016-11-19 01:59:53 If I add a vif to my domU with xl network-attach bla bla bla, then remove it with xl network-detach bla bla, the remove is instantaneous. 2016-11-19 02:01:06 If I shutdown the domU, after it says "Performing poweroff." on its console, after 5 secs (5*HZ in the src) it says: [xxx.xxx] xenbus: xenbus_dev_shutdown: device/vif/0 timeout closing device 2016-11-19 02:01:19 Then [ xxx.xxx] reboot: System halted 2016-11-19 02:01:34 I'm going ape shit crazy over this. 2016-11-19 02:03:22 hanez: you're going to be at 33c3? 2016-11-19 02:20:00 jomat: yes, i will be there... 2016-11-19 02:57:47 will be there, too :-) 2016-11-19 02:59:43 oh, nice... :) 2016-11-19 03:00:13 may we could get a drink together then... ? 2016-11-19 10:20:27 _ikke_: https://pkgs.alpinelinux.org/contents?file=*.cl&path=&name=darktable&branch=edge&repo=testing&arch=x86 <_ they depend on common.h; it's not some api header, it is a internal opencl header; then i guess darkable package needs to depend on darktable-dev :) and not makedepend, it is a runtime dep 2016-11-19 11:21:48 <_ikke_> LebedevRI: So it reads common.h at runtime? 2016-11-19 11:25:40 _ikke_: .cl files contain opencl kernels. they are compiled at run-time, because they are compiler for specific GPU. these .cl files contain #include common.h; so yeah, it reads common.h at runtime 2016-11-19 11:27:11 <_ikke_> Right 2016-11-19 11:27:15 <_ikke_> I understand 2016-11-19 11:27:27 s/are compiler/are compiled/ 2016-11-19 11:27:47 <_ikke_> Didn't know opencl code was compiled at runtime 2016-11-19 11:35:05 now you know more :) 2016-11-19 11:36:30 <_ikke_> Correct 2016-11-19 11:36:46 <_ikke_> Which is one of the reasons I do these kinds of packages 2016-11-19 13:06:13 _ikke_: 2 more notes: it's more true to specify not arch="all !armhf" but arch="x86_64 x86 aarch64" we don't specifically disable armhf, we only explicitly only support only these 3 2016-11-19 13:06:53 <_ikke_> LebedevRI: clandmeter did that 2016-11-19 13:07:07 _ikke_: and, release-2.2.0rc0.tar.gz is a github autogenerated tarball, which we highly recommend not to use at the very beginning of release notes 2016-11-19 13:18:59 <_ikke_> LebedevRI: where? 2016-11-19 13:19:22 https://github.com/darktable-org/darktable/releases/tag/release-2.2.0rc0 2016-11-19 13:19:25 as always, please don't use the autogenerated tarball provided by github, but only our tar.xz. the checksum is: 2016-11-19 13:20:06 <_ikke_> Out of curiosity, what is the reason for that? 2016-11-19 13:20:25 at least, we drop usermanual sources from it, those are huge 2016-11-19 13:20:26 <_ikke_> LebedevRI: I was looking at RELEASE_NOTES, there I couldn't find it 2016-11-19 13:21:34 (just diff these 2 tarballs) and our tarball also has proper version_gen.c included 2016-11-19 13:21:37 bbl 2016-11-19 16:15:58 i’m starting to hate python… to be more specific, apps written in python… 2016-11-19 16:16:27 docutils and sphinx declares compatibility with python 3, but actually does not work on python 3.5 2016-11-19 16:30:59 <_ikke_> hmm 2016-11-19 16:33:39 van mora? 2016-11-19 16:34:18 ? 2016-11-19 16:35:18 <_ikke_> dutch commercial 2016-11-19 16:35:30 :) 2016-11-19 16:37:18 but its without h, but you kind of pronouce it in dutch. 2016-11-19 16:43:49 _ikke_: where is your ops? 2016-11-19 16:48:46 <_ikke_> clandmeter: gone when i got disconnected 2016-11-19 16:49:04 ncopa didnt add you to the list? 2016-11-19 16:49:11 <_ikke_> He didn't know how 2016-11-19 16:49:19 <_ikke_> said you arrange that normally 2016-11-19 16:49:35 is your nick regged? 2016-11-19 16:49:37 <_ikke_> yes 2016-11-19 16:49:48 ok lets lookup the manual again 2016-11-19 16:49:59 last time was 8 years ago i think 2016-11-19 16:51:38 <_ikke_> /query chanserv flags #alpine-dev _ikke_ +oO 2016-11-19 16:53:45 hatseflats 2016-11-19 16:54:46 may the force be with you channel master 2016-11-19 16:55:08 <_ikke_> ohai 2016-11-19 17:00:13 clandmeter: can I also get master role, master? :)) 2016-11-19 17:00:49 of course 2016-11-19 17:00:57 _ikke_: what did you pay ncopa? 2016-11-19 17:01:10 :p 2016-11-19 17:01:15 <_ikke_> Cannot say, have NDA 2016-11-19 20:06:47 uff, enough for today :) 2016-11-20 02:35:08 what does nlplug-findfs do? it's used in /init for the initram but I can't work out what its actually doing 2016-11-20 02:44:59 I'm trying to deduce why fstab options arent obeyed... 2016-11-20 07:22:37 tavixvi, nlplug-findfs handles hotplug events, loads modules based on that, handles LVM, crypt and raid device setup until root disk or boot media/starutp config is found 2016-11-20 15:01:02 _ikke_: https://github.com/darktable-org/darktable/releases/tag/release-2.2.0rc1 2016-11-20 16:10:17 <_ikke_> new RC 2016-11-20 21:50:03 darktable builds on musl, but seg faults on exec. does that release fix the issue? 2016-11-20 21:52:11 but maybe you knew that, looks like theres' 2016-11-20 21:52:20 been some talk about it here 2016-11-20 21:52:24 :) 2016-11-21 05:56:57 <_ikke_> ScrumpyJack: I do not have a graphical alpine installation, so I cannot test it myself 2016-11-21 05:57:45 <_ikke_> Anyone knows how good alpine works with qemu / kvm? 2016-11-21 06:25:57 likely as good as any other 2016-11-21 07:49:06 morning. happy monday! 2016-11-21 07:50:06 _ikke_: alpine as dom0 or domU 2016-11-21 08:54:20 <_ikke_> No experience with that 2016-11-21 08:56:24 <_ikke_> ScrumpyJack: But it's for on my laptop, so no dedicated server or something 2016-11-21 09:00:37 Alpine works fine as a host for qemu/kvm 2016-11-21 09:00:44 no experience with Alpine as a guest 2016-11-21 09:01:13 but there's no reason it wouldn't work 2016-11-21 09:02:59 _ikke_: sorry, i misread - thought you meant zen 2016-11-21 09:04:13 <_ikke_> I mean as a guest, with X11 2016-11-21 09:04:24 <_ikke_> I heard virtualbox has issues 2016-11-21 09:05:09 the X11 issues should be surmountable 2016-11-21 09:06:28 are you using any wrapper around qemu? I would recommand using pure qemu on the command line 2016-11-21 09:07:25 <_ikke_> No, I'm not using anything yet 2016-11-21 09:07:36 <_ikke_> Just looking for a good approach 2016-11-21 09:07:40 who is the host? 2016-11-21 09:08:05 (as in distro) 2016-11-21 09:08:11 <_ikke_> Archlinux 2016-11-21 09:08:55 there's your problem :D 2016-11-21 09:09:11 <_ikke_> Works for me 2016-11-21 10:02:12 i get openrc-run: line 250: can't create /sys/fs/cgroup/openrc/klogd/tasks on booting AL-rpi 2016-11-21 10:02:16 anyone seen that before? 2016-11-21 10:03:27 klogd is started, but perhaps not early enough? 2016-11-21 10:16:34 now it's swclock 2016-11-21 13:42:18 I've been using rhash from edge/testing in recent days on x86_64 and I didn't notice any problems with it. it would be great if someone could move it to community. 2016-11-21 13:42:23 http://paste.przemoc.net/alpine/rhash/0001-community-rhash-Move-from-testing.patch 2016-11-21 13:48:25 przemoc, pushed 2016-11-21 13:49:13 fabled: thanks! 2016-11-21 13:56:40 jirutka: I believe that having var per line is easier to maintain and gives better diffs if there are any changes needed in future 2016-11-21 13:57:12 przemoc: hm, that’s probably right 2016-11-21 13:58:22 however it’s unlikely that any var in `make install DESTDIR="$pkgdir" PREFIX=/usr` would be modified 2016-11-21 13:58:32 s/would/will/ 2016-11-21 13:59:04 but there may be added new ones for the sake of new platforms for instance, and then new var is clearly visible and not hide in long oneliner 2016-11-21 13:59:24 przemoc: then you can add such line on the next line ;) 2016-11-21 13:59:38 s/such line/such var/ 2016-11-21 13:59:51 but I have also to change current line to add \ 2016-11-21 14:00:09 just stating my viewpoint 2016-11-21 14:00:16 in this case it's fine 2016-11-21 15:20:23 fabled: what are your thoughts about building binutils with --enable-deterministic-archives in AL? reproducible builds in general should be in line with AL way of doing things, right? 2016-11-21 16:17:25 ^ +1 2016-11-21 18:02:40 przemoc, sounds acceptable to me 2016-11-21 18:04:33 hey 2016-11-21 18:05:17 looks like you all have been busy while i have been afk 2016-11-21 18:05:29 are we ready to ship rc3? 2016-11-21 18:06:55 i suppose it might be an idea to upgrade the kernels 2016-11-21 18:09:40 ncopa, i think modloop building failed for _rc2 x86_64 2016-11-21 18:09:46 i dunno what happened there 2016-11-21 18:10:05 i thnk i know how to fix the vanilla iso at least 2016-11-21 18:10:09 ok 2016-11-21 18:10:32 i've been working on fixing nlplug-findfs and a bit of s390 port 2016-11-21 18:10:40 i earlier worked on efi boot too 2016-11-21 18:10:47 i saw your email 2016-11-21 18:10:48 very nice 2016-11-21 18:11:02 yes, i know that we need gpt for efi 2016-11-21 18:12:08 so we need fix the partition creation 2016-11-21 18:13:39 hm... there is a conflic in arch/sparc/include/asm/uaccess_64.h 2016-11-21 18:14:09 we have bug about that now too 2016-11-21 18:14:17 if you have few minutes, take a look at http://git.alpinelinux.org/cgit/mkinitfs/log/?h=tteras-work 2016-11-21 18:14:22 the four last commits 2016-11-21 18:14:48 it's in attempt to fix #6469 2016-11-21 18:15:09 the last commit on mkinitfs master should've fixed #6473 2016-11-21 18:15:29 setup-disk fixes for efi is #6470 2016-11-21 18:16:23 re #6469, i run a similar setup at home 2016-11-21 18:17:32 but good, those are the issues that we should try fix now at this stage 2016-11-21 18:17:34 very good 2016-11-21 18:17:45 also means we get more testing 2016-11-21 18:18:32 so 2016-11-21 18:18:40 for rc3: 2016-11-21 18:18:43 - new kernels 2016-11-21 18:18:48 - mkinitfs fixes 2016-11-21 18:18:59 - verify modloop generation 2016-11-21 18:19:15 anything else? 2016-11-21 18:20:45 i think that is enough for rc3 2016-11-21 18:28:00 ncopa: http://www.simplesystems.org/libtiff/v4.0.7.html (many CVE fixes) 2016-11-21 18:28:33 dsabogal, thanks! 2016-11-21 19:13:14 <_ikke_> clandmeter: LebedevRI mentioned that it makes no sense to have common.h in a separate -dev package for darktable, it's needed for opencl at runtime 2016-11-21 19:13:30 i saw it 2016-11-21 19:13:42 its just that single header file? 2016-11-21 19:13:49 <_ikke_> Looks like it 2016-11-21 19:13:55 <_ikke_> and rc2 is out 2016-11-21 19:14:00 <_ikke_> Should I update it? 2016-11-21 19:14:06 then do a custom dev() with default_dev 2016-11-21 19:14:17 <_ikke_> https://pkgs.alpinelinux.org/contents?branch=edge&name=darktable-dev&arch=aarch64&repo=testing 2016-11-21 19:14:32 <_ikke_> default_dev? 2016-11-21 19:14:43 what happends if you dont provide -dev? 2016-11-21 19:14:53 <_ikke_> https://wiki.alpinelinux.org/wiki/APKBUILD_Reference 2016-11-21 19:14:57 does abuild error? 2016-11-21 19:15:02 <_ikke_> let me try 2016-11-21 19:15:05 <_ikke_> Haven't looked yet 2016-11-21 19:15:06 no 2016-11-21 19:15:09 it will work fine 2016-11-21 19:15:21 it doesnt auto detect headers? 2016-11-21 19:15:30 it does if you ask it to 2016-11-21 19:15:39 if you don't (by not having a -dev package), then it doesn't 2016-11-21 19:15:49 i mean auto in your face if you dont :) 2016-11-21 19:16:00 <_ikke_> like with man files etc 2016-11-21 19:16:01 then, no it doesn't 2016-11-21 19:16:53 right, i must be confused with -doc 2016-11-21 19:16:59 no 2016-11-21 19:17:00 <_ikke_> ACTION wonders if git should depend on gnu less, busybox less does not support colors :P 2016-11-21 19:17:04 it is the same with -doc 2016-11-21 19:17:33 if you don't request the subpackage, it does nothing. it may suggest using a subpackage, but that's it 2016-11-21 19:17:52 no 2016-11-21 19:18:00 -doc for sure will error 2016-11-21 19:20:16 _ikke_: most of abuild buildin functions you can overide. 2016-11-21 19:20:41 <_ikke_> right 2016-11-21 19:20:42 and then call them again with default_functname within that fucntion 2016-11-21 19:21:12 <_ikke_> clandmeter: You did not address the other commend for jirutka ? 2016-11-21 19:21:17 <_ikke_> re -dev packages 2016-11-21 19:21:36 which one? 2016-11-21 19:22:23 <_ikke_> https://github.com/alpinelinux/aports/pull/374#pullrequestreview-6349727 2016-11-21 19:22:57 ai 2016-11-21 19:23:00 i didnt catch that 2016-11-21 19:24:04 remove all -dev to makedepends 2016-11-21 19:24:10 move* 2016-11-21 19:24:16 <_ikke_> I did that because LebedevRI said most of them were also runtime deps 2016-11-21 19:24:25 <_ikke_> But perhaps only the ones without -dev 2016-11-21 19:24:29 i'm not a packager, what do i know? :) 2016-11-21 19:24:34 <_ikke_> hehe 2016-11-21 19:24:51 and yes, i probably meant the ones without -dev 2016-11-21 19:25:01 LebedevRI: why do you need them at run time? 2016-11-21 19:25:13 "them" ? 2016-11-21 19:26:30 we do not need -dev packages at run time, i probably worded it wrongly back when i said that 2016-11-21 19:26:39 right 2016-11-21 19:26:46 but you need the opencl header 2016-11-21 19:27:01 <_ikke_> common.hg 2016-11-21 19:27:05 <_ikke_> common.h* 2016-11-21 19:27:21 yes, that one needs to be installed together with *.cl 2016-11-21 19:27:23 right 2016-11-21 19:27:24 sorry 2016-11-21 19:28:02 and then, opencl is *optional*, if user wants, he needs to manually make sure that opencl libs are presets 2016-11-21 19:28:07 *are present 2016-11-21 19:28:42 _ikke_: can you fix those? 2016-11-21 19:28:46 <_ikke_> Sure 2016-11-21 19:28:49 <_ikke_> Working on it 2016-11-21 19:28:51 :) 2016-11-21 19:29:31 (and once more, if possible, please use .tar.xz, and do check it's shasum and gpg sig instead of github autogenerated tar.gz) 2016-11-21 19:30:23 <_ikke_> LebedevRI: Yes, was just fixing that 2016-11-21 19:30:37 <_ikke_> Not sure if abuild supports gpg keys 2016-11-21 19:30:41 <_ikke_> gpg sigs 2016-11-21 19:31:01 at least the sha256sum :) 2016-11-21 19:36:47 _ikke_: BTW i have lowered the *setting* for minimal stack size dt wants (read: increases stack size to) down to 256Kb (from 1Mb), based on my testing it works, but who knows.. 2016-11-21 19:37:05 <_ikke_> Ok, I'll verify 2016-11-21 19:37:12 <_ikke_> LebedevRI: Should dt work under qemu? 2016-11-21 19:37:21 <_ikke_> The checksum verifies now 2016-11-21 19:38:22 i'm not sure what you mean about qemu. we do not have any checks against running under qemu. it may be slow, and may not work because of not enough ram 2016-11-21 19:38:51 <_ikke_> I don't have an alpine desktop, so if I want to actually test running the GUI, I have to use a VM 2016-11-21 19:39:19 X forwarding? may be faster than qemu 2016-11-21 19:39:36 (or, chroot?) 2016-11-21 19:44:06 <_ikke_> It doesn't have to be that fast for me (unless it takes a long time to even start) 2016-11-21 19:45:06 <_ikke_> The real test can best be done by someone actually using it 2016-11-21 19:46:42 i did try it by changing the check to set stack size, not just increase it, and it worked *for me* with 256kb stacksize (and did not work with 128kb) 2016-11-21 19:48:55 <_ikke_> Compiling it now 2016-11-21 20:02:03 <_ikke_> Why does abuild say it cannot find libdarktable.sop? 2016-11-21 20:02:08 <_ikke_> libdarktable.so* 2016-11-21 20:07:00 because it's dark, so it has trouble finding it 2016-11-21 20:07:10 try turning on more lights! 2016-11-21 20:07:34 <_ikke_> s/dark/light 2016-11-21 20:07:38 <_ikke_> Better? 2016-11-21 20:07:59 liblighttable.so: not found 2016-11-21 20:09:46 skarnet: https://travis-ci.org/darktable-org/darktable/jobs/177693711#L1588 <- different libs with same names, but different subdirs, installed by the one package is not cool :) 2016-11-21 20:11:36 it's cool if they have different sonames... and if the distribution doesn't insist on a strict FHS installation 2016-11-21 20:11:41 ACTION whistles. 2016-11-21 20:11:46 <_ikke_> Hmm, got relocate errors 2016-11-21 20:12:12 <_ikke_> Looks like some paths are incorrect 2016-11-21 20:13:18 <_ikke_> http://sprunge.us/TNGM 2016-11-21 20:14:47 which gtk version did you compile dt against? it is probably newer than the one dt is linked against 2016-11-21 20:15:02 all(?) these symbols were added in gtk-3.22 2016-11-21 20:15:08 <_ikke_> Let me check 2016-11-21 20:15:39 i.e. at runtime, gtk <3.22 is used 2016-11-21 20:15:45 <_ikke_> Yeah 2016-11-21 20:15:50 <_ikke_> I need to upgrade my VM 2016-11-21 20:15:58 <_ikke_> switched to edge repos, but did not upgrade 2016-11-21 20:18:18 <_ikke_> Ok, it's running 2016-11-21 20:21:30 <_ikke_> clandmeter: Should I update the existing PR, or create a new PR for darktable? 2016-11-21 20:27:26 _ikke_: isn’t existing PR already closed? 2016-11-21 20:27:38 <_ikke_> jirutka: yes, it is 2016-11-21 20:27:45 _ikke_: then open new one 2016-11-21 20:27:49 <_ikke_> ok 2016-11-21 20:32:17 <_ikke_> https://github.com/alpinelinux/aports/pull/544 2016-11-21 20:34:07 darktable-${_ver}.$_rc.tar.xz <- will need changes for non-rc releases 2016-11-21 20:34:25 url="http://www.darktable.org/" <- https ? 2016-11-21 20:35:10 <_ikke_> re first point, yes, I know, but was the easiest way at least to follow rc's 2016-11-21 20:35:32 <_ikke_> Updated url 2016-11-21 20:35:47 <_ikke_> Waiting for the travis build to finnish 2016-11-21 20:36:03 hopefully next time we won't let cert expire, again 2016-11-21 20:36:06 <_ikke_> The version is there in so many formats 2016-11-21 20:36:10 <_ikke_> LebedevRI: hehe 2016-11-21 20:36:21 <_ikke_> I actively monitor the expire dates of my certs 2016-11-21 20:38:02 LebedevRI: you're a darktable dev? 2016-11-21 20:38:08 ncopa: yes 2016-11-21 20:38:33 cool! nice that you hang around with us alpine ppl :) 2016-11-21 20:42:30 have a nice evening/night 2016-11-21 20:44:36 <_ikke_> woohoo, build succeeded 2016-11-22 00:08:18 fabled : Hi I am the guy experimenting s390x port 2016-11-22 00:09:14 just want to tell you that with your suggestion on patching musl : mips* | s390*) _ld="ld.so.1" ;; , now I finished up to building linux-vanilla 2016-11-22 00:09:49 I am compiling linux-vanilla and will write an email to the list soon 2016-11-22 00:09:56 Thank you :) 2016-11-22 00:17:57 *finished up to building linux-vanilla without the /lib/ld-musl-s390x.so.1 problem I mentioned in http://lists.alpinelinux.org/alpine-devel/5425.html 2016-11-22 04:55:29 tmh1999, nice! 2016-11-22 04:56:49 tmh1999, i actually had the final gcc build fail in "make install" for some weird reason. possibly related to ada. and did not have time to figure it out. 2016-11-22 04:57:01 everything else cross built just fine 2016-11-22 07:55:00 fabled: do we have something lua based that can read/parse apkbuilds? 2016-11-22 08:12:57 clandmeter, not natively. lua-aports does parse them but only after shell expansion 2016-11-22 08:13:25 the problem is that there's lot of shell conditionals used to construct parts of the apkbuild 2016-11-22 08:13:49 we've been talking quite a bit of that problem with ncopa and how to solve it, but we don't have any good alternative yet 2016-11-22 08:14:22 i guess the only viable thing to do eventually is to brew some yaml+inline shell scripts type of format 2016-11-22 08:14:38 but it's non-trivial to design 2016-11-22 08:16:57 fabled: so its best to source the apkbuild in my lua code and just echo whatever i need? 2016-11-22 08:19:30 clandmeter, yes, that's how lua-aports works; see: http://git.alpinelinux.org/cgit/lua-aports/tree/aports/db.lua#n74 2016-11-22 08:20:21 right ok thx. 2016-11-22 08:48:37 fabled : http://sprunge.us/AAcA This was the error I sent in the email. For now, there is no ERROR on /lib/libcrypto.so.38.0.0, but /lib/ld-musl-x86_64.so.1 still exists. I am trying to modify /usr/bin/abuild to get past of this error, to see any other error after this. 2016-11-22 08:51:30 tmh1999, i think you can workaround it by adding "!tracedeps" to options 2016-11-22 08:51:41 the actual error is probably related to kernel config 2016-11-22 08:51:52 it builds probably some tools that get installed to -dev package 2016-11-22 08:51:52 I see, I am working on it. 2016-11-22 08:51:58 Have 2 version of kernel config 2016-11-22 08:52:19 the problem is likely that the kernel builds tools that runs on the build computer 2016-11-22 08:52:27 but -dev package is marked to be target package 2016-11-22 08:52:58 i think the tools should be installed at all; or be split to separate -tools package that is marked to run on CBUILD_ARCH 2016-11-22 08:55:19 hah 2016-11-22 08:55:26 understood 2016-11-22 08:55:48 thanks 2016-11-22 08:55:49 or even better, when cross-building kernel, it should also cross-build the tools 2016-11-22 08:56:07 it'd need host-built versions to build kernel image; and cross-built ones to go to -dev 2016-11-22 08:56:25 but curiously this was not a problem when i bootstrapped something else 2016-11-22 08:56:51 so either it's kernel config related, or something in newer kernels (compared to when i tested it) 2016-11-22 09:00:22 by "some tools", you mean kernel modules in /lib/modules ? 2016-11-22 09:01:51 I think I understand what you say haha I took me a while 2016-11-22 09:03:08 the kernel config, I try to read kernel Kconfig document + cross check from Debian, OpenSUSE and RedHat 2016-11-22 09:03:54 there are some options for s390x, some are distro specific. Since I am not s390x expert, it gotta take me a while 2016-11-22 09:04:46 is checking with Alpine's too, as you suggested before :) 2016-11-22 09:39:44 do we have anything to accelarate X11 on the RPi in the repos? 2016-11-22 09:51:46 <^7heo> busybox has the `rm` builtin. 2016-11-22 11:37:56 fcolista: please never, ever use `go get` in apkbuild! https://github.com/alpinelinux/aports/commit/444333574820740cf91a2aea1a35d7371b5ff132 2016-11-22 11:39:06 jirutka, why? 2016-11-22 11:39:14 we have it in community 2016-11-22 11:39:33 and this is in testing.. 2016-11-22 11:39:35 fcolista: b/c it downloads random dependencies without any verification, so it produces inreproducible builds 2016-11-22 11:39:37 <^7heo> fcolista: because it doesn't allow for reproducible builds. 2016-11-22 11:39:43 <^7heo> fcolista: go get is evil. 2016-11-22 11:39:50 fcolista: which apkbuilds in community? 2016-11-22 11:39:57 lego/dockerize 2016-11-22 11:40:03 <^7heo> v_v 2016-11-22 11:40:09 <^7heo> we definitely need some more testing about that. 2016-11-22 11:40:23 <^7heo> gosh I need to make up some time to work on the mkinitfs thing and this. 2016-11-22 11:40:38 ^7heo: please look at community/dockerize and community/lego 2016-11-22 11:41:06 ^7heo: try to fix it, or suggest to remove them if cannot be 2016-11-22 11:41:31 so this means that i need to go through each dependency and package it 2016-11-22 11:41:38 withouth knowing that in advance 2016-11-22 11:41:41 no 2016-11-22 11:42:03 <^7heo> jirutka: I have a giant deadline coming up at the end of this month 2016-11-22 11:42:11 <^7heo> jirutka: I'll try my best but I can't spend too much time on it. 2016-11-22 11:42:43 im adding a page to the wiki explaining how to properly write go apkbuilds 2016-11-22 11:42:53 clandmeter: you mean https://wiki.alpinelinux.org/wiki/APKBUILD_examples:Go ? 2016-11-22 11:43:04 yes its a start.. 2016-11-22 11:43:19 <^7heo> I wish I could edit that. 2016-11-22 11:43:21 doing to many things at the same time 2016-11-22 11:44:01 clandmeter: I suggest to remove (or move to unmaintained) all apkbuilds which use `go get`, until someone fix them, WDYT? 2016-11-22 11:44:41 could be a bit harsh 2016-11-22 11:44:48 what about moving them to testing? 2016-11-22 11:45:00 imo better than keeping trash in aports tre 2016-11-22 11:45:02 tree 2016-11-22 11:45:16 okay, moving to testing is good compromise 2016-11-22 11:45:34 jirutka, clandmeter : we should make abuild warn/error out on those things 2016-11-22 11:45:42 we should add a hook to abuild to check for go get 2016-11-22 11:45:44 fabled: agree 2016-11-22 11:45:44 otherwise people just keep submitting junk 2016-11-22 11:46:01 glad we are on the same page here :) 2016-11-22 11:46:11 fabled: and maybe even block internet connection when running abuild, except in fetch phase 2016-11-22 11:46:14 yes 2016-11-22 11:46:17 that's in my plans 2016-11-22 11:46:31 "and maybe even block internet connection when running abuild, except in fetch phase" 2016-11-22 11:46:31 i'm hoping to wrote abuild-fakeroot and abuild-chroot using unshare 2016-11-22 11:46:34 sounds a good idea 2016-11-22 11:46:43 thats even possible? 2016-11-22 11:46:46 yes 2016-11-22 11:47:10 i actually of proof-of-concept done 2016-11-22 11:47:13 have* 2016-11-22 11:47:19 set the source fqdn in blackhole route :) 2016-11-22 11:47:37 <^7heo> < jirutka> fabled: and maybe even block internet connection when running abuild, except in fetch phase 2016-11-22 11:47:40 <^7heo> +42 2016-11-22 11:48:14 <^7heo> but without killing the connection for the whole host please. 2016-11-22 11:48:15 i'm hoping to implement as first step fakeroot+chroot using unshare. it simplifies and speeds up fakeroot greatly. and chroot would enable abuild to build stuff in chroot without network 2016-11-22 11:48:34 it's basically creating isolated namespace for the build. lightweight container. 2016-11-22 11:48:44 nice 2016-11-22 11:48:45 so it can be run in no network mode. 2016-11-22 11:48:49 <^7heo> please refrain from using the word "container" in here. 2016-11-22 11:48:55 <^7heo> most of us have nights terrors about it. 2016-11-22 11:48:59 :) 2016-11-22 11:49:08 <^7heo> please think of all the PTSD-affected veterans in here. 2016-11-22 11:50:16 ^7heo, you should add s/container/kernel namespace/g or similar in your irc client then ;) 2016-11-22 11:50:35 ^7heo: why you cannot edit pages on wiki? 2016-11-22 11:50:59 clandmeter: because he’s busy with his deadlines :P 2016-11-22 11:51:03 <^7heo> clandmeter: because it only supports a protocol that requires X and a mouse. 2016-11-22 11:51:10 <^7heo> and what jirutka said too,. 2016-11-22 11:51:25 jirutka: why did you move lego? 2016-11-22 11:51:37 please move it back 2016-11-22 11:51:50 we use it in our infra, and uses a snapshot (for now) 2016-11-22 11:51:59 fcolista: look into community/gogs for example how to deal with go trash 2016-11-22 11:52:21 hm, actually, not the best example 2016-11-22 11:52:31 check hugo 2016-11-22 11:52:32 <^7heo> clandmeter: we use that in our infra!? 2016-11-22 11:52:57 <^7heo> jirutka: yeah gogs is kind of bastard'ed at the moment. 2016-11-22 11:53:00 fcolista: community/caddy is probably better example 2016-11-22 11:53:01 <^7heo> jirutka: we should correct it. 2016-11-22 11:53:09 <^7heo> yeah caddy is a consistent example. 2016-11-22 11:53:14 or check hugo 2016-11-22 11:53:18 i did that recently 2016-11-22 11:53:22 <^7heo> yeah I saw it. 2016-11-22 11:53:22 clandmeter: b/c lego calls go get 2016-11-22 11:53:31 <^7heo> jirutka: hugo != lego 2016-11-22 11:53:37 jirutka: only in snapshot 2016-11-22 11:53:43 <^7heo> jirutka: I know it's all go crap in four letters but... 2016-11-22 11:53:52 clandmeter: aha, pardon, I overlooked that it use snapshot 2016-11-22 11:55:29 clandmeter: why the heck we use lego in infra?! 2016-11-22 11:55:51 clandmeter: there are dozens of better ACME tools 2016-11-22 11:55:58 you mean the python crap is any better? 2016-11-22 11:56:35 or should i use some kind of bash style version 2016-11-22 11:56:44 clandmeter: https://kristaps.bsd.lv/acme-client/ 2016-11-22 11:56:45 fabled: please keep me informed when you're working on implementing a fakeroot via namespaces, I'm interested. 2016-11-22 11:56:54 jirutka: it doesnt work 2016-11-22 11:57:08 clandmeter: but to be honest, yes, I’d rather use that one written in Python or even simple shell than any Go shit 2016-11-22 11:57:20 fabled: me too! :) 2016-11-22 11:57:35 clandmeter: I’ve moved lego back to community 2016-11-22 11:57:41 skarnet, it's probably not going to be universal. doing it via namespace requires the user to be root of the new namespace. so it has certain security implications. but 'abuild' group members can do admin stuff anyway, so that's how i plan to do it 2016-11-22 11:58:08 i have proof-of-concelt patch for bubblewrap 2016-11-22 11:58:11 clandmeter: why acme-client does not work? :( 2016-11-22 11:58:30 i dont know, and i already spend too much time on that. 2016-11-22 11:58:30 but planning to write it as abuild-fakeroot/chroot as part of abuild.git 2016-11-22 11:58:39 so i just choose an more simple client 2016-11-22 11:58:53 fabled: does it need access to /dev or anything that would forbid an unprivileged container? 2016-11-22 11:59:10 i dont think go is a bad language, the whole community around it just sucks. 2016-11-22 11:59:21 clandmeter: and that makes it a bad language… 2016-11-22 11:59:35 clandmeter: but even without shitty community it’s really bad language 2016-11-22 11:59:52 but don’t want to start a flamewar now :) 2016-11-22 11:59:57 +100 2016-11-22 11:59:58 need to go to lunch 2016-11-22 12:00:12 see, go is everywhere 2016-11-22 12:00:13 jirutka: I disagree on your lumping language and community together, but agree on agreeing to disagree :) 2016-11-22 12:00:22 even close to your lunch ;-) 2016-11-22 12:00:23 skarnet, the uid map needs to be done stat the real user maps to root in container; and it also needs an uid range where to map all other container uids. so i just need to reserve enough uids from parents high uid range to map to containers system uids 2016-11-22 12:00:25 clandmeter: and that makes me very sad 2016-11-22 12:00:48 skarnet, in other words: the 'fakeroot' user will get access to the mapped uids 2016-11-22 12:01:23 alternatives dont make me sad, if somebody wants to make acme-client work im glad to replace lego. 2016-11-22 12:02:04 fabled: makes sense, but why do you need several host uids? 2016-11-22 12:02:27 fakeroot maps every guest uids onto the host's uid 2016-11-22 12:02:28 skarnet, uids need one-to-one mapping. if uid in container cannot be mapped to host, it's not allowed to be used. 2016-11-22 12:02:39 otherwise kernel cannot enforce it 2016-11-22 12:02:39 ah. 2016-11-22 12:02:44 well that sucks. 2016-11-22 12:02:45 fakeroot cheats 2016-11-22 12:02:45 btw is there some English word I can use instead of “go” in all contexts so I can avoid using this corrupted word entirely? :) 2016-11-22 12:03:03 move 2016-11-22 12:03:04 :) 2016-11-22 12:03:19 I need to move to lunch… hmm, sounds weird :P 2016-11-22 12:03:28 fakeroot runs as users, but uses LD_PRELOAD to overload all libc calls and hooks the uid info from local database/db daemon 2016-11-22 12:03:34 fabled: seems to me like the best solution would still be to have an archive format that takes a uid mapping description 2016-11-22 12:03:34 relocate 2016-11-22 12:03:45 relocate myself to restaurant XD 2016-11-22 12:04:02 skarnet, it's problematic in many ways. and breaks when ever new libc/kernel function is added 2016-11-22 12:04:26 fabled: I know how fakeroot works and why it's problematic, I agree it needs changing 2016-11-22 12:04:38 another similar is: https://www.yoctoproject.org/tools-resources/projects/pseudo 2016-11-22 12:05:22 yeah, still LD_PRELOADing 2016-11-22 12:05:23 pseudo is supposed to be better than fakeroot, but I've never really used it 2016-11-22 12:06:18 we don't really want to fake root, we just want to set uid/gids on files in an archive 2016-11-22 12:06:45 it would be nice if the archiver could take an uid mapping file 2016-11-22 12:06:49 skarnet, rpm does that 2016-11-22 12:06:52 we wouldn't need dirty tricks at all 2016-11-22 12:07:14 but it's problematic approach too; and pretty much all "make install" using non-root users would fail 2016-11-22 12:07:15 well for once rpm is doing something right :) 2016-11-22 12:07:42 why would it fail? 2016-11-22 12:07:48 chown fails 2016-11-22 12:07:52 make bails out 2016-11-22 12:08:03 i also saw some wrapper for 'install' command that writes a log on the permissions/users wanted 2016-11-22 12:08:06 uh 2016-11-22 12:08:15 but too many "make install" things just use cp and mkdir 2016-11-22 12:08:23 to build a package, you always make install in a user-owned DESTDIR 2016-11-22 12:08:30 skarnet, that's not the problem 2016-11-22 12:08:44 the problem is when package does "chown user:group " for the just installed file 2016-11-22 12:08:59 when user, that fails. that's the whole purpose of fakeroot to allow those commands to succeed 2016-11-22 12:09:27 one option would be to inject abuild's version of cp/chmod/install/mv etc. that tracks the uid/gids 2016-11-22 12:09:46 but each upstream project seems to have their funky way of installing files 2016-11-22 12:09:51 overwriting the utilities instead of the libc calls... not as dirty, but still dirty 2016-11-22 12:09:57 yeah, exactly 2016-11-22 12:10:21 so the universal ways to do it are LD_PRELOAD, or kernel level 2016-11-22 12:10:53 uid namespaces sound good indeed... but why do you need a 1:1 mapping o.O 2016-11-22 12:10:55 kernel level you have user containers with the uid_map issue; or possibly using ptrace or similar 2016-11-22 12:11:04 kernel needs the 1:1 mapping 2016-11-22 12:11:10 that's silly 2016-11-22 12:11:12 so it can record the uid/gid on disk 2016-11-22 12:11:23 and do proper permission checks 2016-11-22 12:11:34 those are not real containers 2016-11-22 12:11:38 that's a kernel-level hack 2016-11-22 12:12:06 <^7heo> if you go low level enough, everything is a hack. 2016-11-22 12:12:09 third option is to start a new kernel in VM 2016-11-22 12:12:16 "we can't implement recursion so we'll just do a goto and pretend we're in a subroutine" 2016-11-22 12:12:56 the problem with fakeroot is that LD_PRELOAD is hacky too, and fakeroot is very slow 2016-11-22 12:13:04 etc 2016-11-22 12:13:06 <^7heo> skarnet: well, that's what recursion is anyway :P 2016-11-22 12:13:11 honestly, building a package on an entirely new VM doesn't sound so bad - that would prevent us from having to build on edge, for instance :P 2016-11-22 12:13:24 the only downside in user namespace is that you need 1:1 uid mapping. but everything else will just work. 2016-11-22 12:13:27 ^7heo: no, when recursing you have a stack 2016-11-22 12:13:31 <^7heo> indeed. 2016-11-22 12:13:49 <^7heo> you can also manage the stack manually and do a goto. 2016-11-22 12:14:03 <^7heo> it's just a matter of malloc/realloc and pointer arithmetic. 2016-11-22 12:14:13 it will automatically support everything the kernel does, and works in all scenarios the user land does. and it's blazing fast since all the magic happens inside kernel. 2016-11-22 12:14:22 fourth option is to invent installfs that can export tar ;) 2016-11-22 12:14:37 true 2016-11-22 12:14:42 would probably be simple with fuse 2016-11-22 12:14:55 fabled: but to have an accurate 1:1 mapping you basically need to duplicate every system uid ever invented 2016-11-22 12:15:04 skarnet, no the uid mapping can be partial 2016-11-22 12:15:13 not sure whether it would be faster than LD_PRELOAD, though 2016-11-22 12:15:29 let's think about performance once we get correctness right 2016-11-22 12:15:46 but it should be less hacking indeed 2016-11-22 12:15:59 przemoc, it would be. since LD_PRELOAD has per-system call overhead, and it talks to daemons over sockets on them = slow. with installfs kernel would do all caching, and just write uid/gid once to disk. 2016-11-22 12:17:04 containers would have the advantage over installfs that they can be expanded upon to get a whole buildlab 2016-11-22 12:17:33 I'm still not over the fact that you need a working edge in order to build apks 2016-11-22 12:17:55 and the perspective of a working buildlab appeals to me 2016-11-22 12:18:23 you can build in non-edge too 2016-11-22 12:18:38 when I do, jirutka yells at me 2016-11-22 12:19:21 yes, i really want to have 'abuild --chroot' mode that downloads all build prerequisites to chroot, and builds inside one 2016-11-22 12:19:23 well, aports get stuff via master, so it does need edge, but for your own use you can perfectly use v3.4 for instance 2016-11-22 12:19:51 and you can just select --repository to use as base so you can easily build for any stable release 2016-11-22 12:20:09 <^7heo> I agree that building should happen in edge, because then we have consistent results. 2016-11-22 12:20:10 fabled: yes, and that integrates seamlessly with namespaces, but not with installfs 2016-11-22 12:20:23 <^7heo> but pepole shouldn't be required to have to use edge on their workstation. 2016-11-22 12:20:26 yes, that's why i need abuild-chroot and abuild-fakeroot 2016-11-22 12:20:33 <^7heo> yep 2016-11-22 12:20:43 they probably share 50-80% of code too 2016-11-22 12:20:50 <^7heo> myeah 2016-11-22 12:20:53 <^7heo> depends when and what 2016-11-22 12:20:54 and should not be more then 500-100 lines of codes 2016-11-22 12:20:54 <^7heo> but yeah 2016-11-22 12:21:22 i did prototype the fakeroot with patched bubblewrap; and seemed to work as designed 2016-11-22 12:21:43 <^7heo> "seemed to work as designed" 2016-11-22 12:21:45 <^7heo> famous last words. 2016-11-22 12:21:50 :) 2016-11-22 12:22:04 i was able to build several packages, and all worked. :) 2016-11-22 12:22:25 <^7heo> #define several 2 2016-11-22 12:22:32 <^7heo> ACTION hides 2016-11-22 12:22:48 another good thing with namespaces based fakeroot is that we can write-protect all but DESTDIR so we catch bad stuff also with that 2016-11-22 12:22:57 indeed 2016-11-22 12:23:12 <^7heo> yep 2016-11-22 12:23:13 ^7heo, hey. comeone, some respect please. 2016-11-22 12:23:17 i tested at least 3 2016-11-22 12:23:18 ;) 2016-11-22 12:23:20 <^7heo> :D 2016-11-22 12:23:27 we still need to make user/group creation into apk built-in feature. unfortunately I still didn't get into creating my own user/group management library (supporting sysroot other than /, of course) that could be used by apk 2016-11-22 12:23:42 przemoc, yes, on my to do list. 2016-11-22 12:23:45 <^7heo> nah but I'm really fine if we can use simple but clean isolation 2016-11-22 12:23:54 <^7heo> a-la jail 2016-11-22 12:24:09 <^7heo> maybe we should use docker in abuild?! 2016-11-22 12:24:11 przemoc, i'm in progress of planning new apk formats. 2016-11-22 12:24:12 <^7heo> ACTION hides 2016-11-22 12:24:17 <^7heo> ACTION hides some more 2016-11-22 12:24:25 przemoc, should have the uid/gid additions in it 2016-11-22 12:24:50 I have a co-worker who did some very simple namespace management, I need to take the time to clean up what he did and publish it 2016-11-22 12:25:17 i really tried to look for nice unshare utility to do fakeroot/chroot for building, but did not find good fit yet. 2016-11-22 12:25:20 bubblewrap was closest 2016-11-22 12:25:24 fabled: I remember there was some thread on ML, but not sure how it ended and what's the current status of your work 2016-11-22 12:25:30 it was a while ago, so maybe something has come up since that 2016-11-22 12:26:08 another thing is that i'd really want it to be simple to use. instead of having to specify commandline with 20 arguments 2016-11-22 12:26:24 well there are a ton of stuff you want to be able to configure 2016-11-22 12:26:40 so it's either that, or environment variables, or a config file 2016-11-22 12:26:41 at least provide sane defaults, that can be still altered when needed 2016-11-22 12:27:58 fabled: support for hooks for eteckeeper-like kind of use is also on your list? 2016-11-22 12:29:51 possibly. though in general i dislike keeping etc in git. it should be server side tracking only, to minimize running system overhead. 2016-11-22 12:30:11 jirutka, re: caddy 2016-11-22 12:30:24 i do have pretty much all details for apk-tools design fixed now. it's just starting to write it. 2016-11-22 12:30:33 but first i hope to get done with the chroot/fakeroot issues 2016-11-22 12:30:35 should i use glide for that? 2016-11-22 12:31:14 being able to write down notes about recent changes in configuration via some scm can be super handy. you tend to forget special tuning that was needed otherwise. 2016-11-22 12:32:55 fabled: do you have some outline of this finalized details of apk-tools-ng written down that you could post for ML? 2016-11-22 12:35:00 IIRC you were going to switch to binary format and while I understand it performance-wise, being able to look at textual db yourself and process it via text tools is sometimes nice. 2016-11-22 12:35:49 will libapk be provided too? 2016-11-22 12:44:38 i think so, and i plan to have dump applet that will give you the data in text format too 2016-11-22 12:45:39 so you've started working on apk-tools-ng? I'm also interested in the details :) 2016-11-22 12:47:42 i'm working on the design and implementation details currently. i hope to start writing code in few weeks time 2016-11-22 12:48:13 should probably document the internals in better detail this time since there's several parties interested on them 2016-11-22 12:48:33 yes - as przemoc says, please publish your ideas before starting to code, we may have questions and comments 2016-11-22 12:49:47 the basic idea is to have all meta-data in djb cdb style database, but make it binary encoded structures instead of key-value pairs 2016-11-22 12:49:59 so loading index is just mapping it 2016-11-22 12:50:05 mmapping* 2016-11-22 12:51:24 oh, I'm not so much interested in implementation details as in features - for instance, something vital that Alpine *needs* is clean support for having multiple versions of the same package 2016-11-22 12:52:05 and if you're rewriting apk, it's the perfect time to address those issues 2016-11-22 12:56:42 that would mean having built-in alternatives system, because for instance different lib versions can still give same ABI and unchanged .so.NUMs 2016-11-22 12:56:56 it will have built-in alternatives system 2016-11-22 12:57:10 but i'd rather still not support installing multiple versions of same package name 2016-11-22 12:57:20 that just fights against the 'keep it small' principle 2016-11-22 12:59:21 I guess it shouldn't be turned on by default, but supporting it would be very nice. imagine testing different version of musl-libc against BRE expression handling in sed, which would require only switching alternative via apk. 2016-11-22 12:59:31 ;) 2016-11-22 13:00:08 there are indeed several good reasons to support it 2016-11-22 13:00:18 hint: python2 and python3 :P 2016-11-22 13:00:37 software depending on specific versions of a library 2016-11-22 13:00:42 etc. 2016-11-22 13:01:35 skarnet, yes, i can see the ideal. but the fact with many of those, e.g. python2/3 is that all modules depend on specific major version, and changing package version is not interchangeable 2016-11-22 13:01:53 and when you want app1 and app2 that depend on conflicting package versions. what then? 2016-11-22 13:02:16 why would several package versions conflict? 2016-11-22 13:02:20 you need to be able to have both 2016-11-22 13:02:30 then you need to design filesystem layout to support that 2016-11-22 13:03:36 but that's non-trivial too 2016-11-22 13:03:48 you'd probably need per-package layout for everything 2016-11-22 13:04:14 nothing wrong with that :P 2016-11-22 13:05:18 except that it will take lot of system resources (memory / inodes) to do all that wrapping 2016-11-22 13:05:38 if you really want all potential versions same time, you're probably better of with docker or your favourite container system 2016-11-22 13:05:49 closest we can get w/o overhauling fs layout is to have stuff installed w/ suffixes and provide canonical suffix-less symlinks, that can be switched (via alternatives system) 2016-11-22 13:06:15 przemoc, yes, that's something like what i have in plans 2016-11-22 13:06:23 ... seriously, you're telling me to install a container when I want two different versions of a library? 2016-11-22 13:06:27 anybody try easy-rsa with libressl? 2016-11-22 13:06:37 you can have packages provide same file, and get some control over which packages binary is used 2016-11-22 13:07:04 skarnet, that works only if the library properly uses unique SONAME per version 2016-11-22 13:07:21 obviously, and it should 2016-11-22 13:07:50 i think that's why some packages already split libs to libfoo$pkgmajorver 2016-11-22 13:08:12 well, libfoo-2.4.0 and libfoo-2.4.1 will have the same soname, but the point is, in that case it doesn't matter which one you're using 2016-11-22 13:08:32 it may matter 2016-11-22 13:08:43 libfoo is then still allowed to provide new symbols 2016-11-22 13:08:48 and package can have libfoo>=2.4.1 dependency 2016-11-22 13:08:54 in which case 2.4.0 is not allwed 2016-11-22 13:08:59 but if 2.4.1 is has bug 2016-11-22 13:09:04 and there can be regressions 2016-11-22 13:09:13 you are in the same problem again 2016-11-22 13:09:35 if it matters, then packages depending on it should not rely on just the soname 2016-11-22 13:10:08 but yes, filesystem support is hands down the easiest way of doing that 2016-11-22 13:10:17 there might be other reasons why it's not interchangeable also. like rebuilding against some different dependency (like openssl->libressl switch recently) 2016-11-22 13:11:16 but my point here is that there is no easy way to generalize the solution 2016-11-22 13:11:29 ditch FHS. Done. 2016-11-22 13:11:30 it always is more or less application specific 2016-11-22 13:12:23 also the point is that i rather have only one version of package than multiple unless absolutely necessary 2016-11-22 13:12:42 we are also targetting embedded, which means bloat is bad 2016-11-22 13:13:03 we rather fix the project, then try to invent hacks how to install versions x, y and z side-by-side 2016-11-22 13:13:08 that's for the user to decide, and you can easily make it so the default is to upgrade rather than install the new version additionally to the old one 2016-11-22 13:13:30 of course bloat is bad, and of course the default should be only 1 version 2016-11-22 13:13:53 but I believe it's important to have the *ability* to have several versions, in a clean way. 2016-11-22 13:13:57 technically, the new solution could install multiple versions side-by-side 2016-11-22 13:14:03 you still can use one of them at a given time 2016-11-22 13:14:16 unless the files it contains are disjoint 2016-11-22 13:14:35 disjoint set* 2016-11-22 13:15:57 and the point of apk is to provide working runnable system. 2016-11-22 13:16:23 I don't think anyone argued the opposite :D 2016-11-22 13:16:36 so.. 2016-11-22 13:16:44 if i have app1 depending on libfoo=1 and app2 on libfoo=2 2016-11-22 13:16:46 so will apk install old version of some lib for some program that has that version set explicitly in depends, because program doesn't work with new version? 2016-11-22 13:17:01 and apk installed app1, app2 libfoo-1 and libfoo-2 2016-11-22 13:17:11 but libfoo 1 vs 2 had overlapping files 2016-11-22 13:17:18 either of the apps gets broken 2016-11-22 13:17:24 ditch FHS 2016-11-22 13:17:27 problem solved 2016-11-22 13:17:43 it's still non-trivial problem even without FHS 2016-11-22 13:17:50 ... 2016-11-22 13:18:05 I think I've outlined the trivial solution several times in this chat 2016-11-22 13:18:36 and everytime we say it's a can of worms we don't want to open. 2016-11-22 13:19:04 then what do you want me to say? stay buggy and broken 2016-11-22 13:19:12 sxs windows dll hell is called hell for a reason 2016-11-22 13:19:26 installing stuff side-by-side does not solve the problems. usually it creates them. 2016-11-22 13:19:51 no, what's creating them is lazy packaging that *relies* on sxs 2016-11-22 13:20:17 having sxs as a possibility doesn't mean that less effort should be directed towards having compatible deps 2016-11-22 13:22:27 it's just like people who say "but having a supervision system incites admins not to fix bugs when a program is crashing, since it will be restarted anyway". No dude, you shouldn't be blaming supervision for that, you should be blaming your admins 2016-11-22 13:23:27 http://marc.info/?l=openbsd-ports&m=144578740817527&w=2 2016-11-22 13:24:56 fabled: so if libfoo-1.2 provides libfoo.so.1.0 and libfoo-1.2.1 provides libfoo.so.1.1 it will be all fine and libfoo.so.1 will symlink to latest version with possibility to be changed via alternatives system, right? but it won't support cases when libfoo-1.2.1 and libfoo-1.2.2 provide same named libfoo.so.1.1, right? 2016-11-22 13:26:27 przemoc, yes, but that works already now correctly if the library is split to libfoo$sonamever, since abuild tracks sonames 2016-11-22 13:27:25 the thing is to avoid creating artifical libfoo$VER splits 2016-11-22 13:29:09 so will new apk work with libfoo-1.2.1 and libfoo-1.2.2 providing same named libfoo.so.1.1? they obviously cannot be provided simultaneously, but at least can be chosen the one used for whole system. 2016-11-22 13:31:39 in case of files that are provided by more than one package, their name could be appended with .v$PKGVER and symlink would be created w/o suffix, manageable via apk 2016-11-22 13:32:29 I mean you can perfectly serve different SONAMEs version simultaneously and always have one chosen version for same SONAMEs 2016-11-22 13:36:04 fabled: is there a way i can still have openssl installed including libressl? 2016-11-22 13:36:20 brb. rebooting. 2016-11-22 13:37:46 jirutka: you moved dockerize and lego to testing/ again due to a violation of the "QA rules”, right? Where can I find the QA rules? 2016-11-22 13:39:57 nmeum: the commit msg is not really clear 2016-11-22 13:40:03 I think the only manageable way to support binaries with different lib versions if explicit version is needed via APKBUILD's depends would be to patch binaries after building to append .v$PKGVER to given NEEDED lib 2016-11-22 13:40:30 the idea is that no pkg should have "go get/install/fix" 2016-11-22 13:40:54 and always provide .v$PKGVER symlink for libs 2016-11-22 13:40:57 I get that, I was just wondering where I could find the document which defines those rules because we didn't have any rules regarding that before 2016-11-22 13:41:00 clandmeter: ^ 2016-11-22 13:41:18 and I know a bunch of other package which call go get from a script community/hub for example 2016-11-22 13:41:21 you are correct, there are non except irc log... 2016-11-22 13:41:44 and im trying to write them on the wiki regarding go. 2016-11-22 13:41:45 good thing that I have those :) 2016-11-22 13:41:50 that would be great 2016-11-22 13:41:58 when i get to it. 2016-11-22 13:42:01 sure 2016-11-22 13:42:27 I don't have a lot of free time these days thus I can't always read the irc log 2016-11-22 13:42:38 therefore it would be great if those kind of rules would be document somewhere 2016-11-22 13:42:49 im not sure if we can ever prevent go get from some script/makefile 2016-11-22 13:42:56 anyway, should I move other packages using go get to testing/ as well? 2016-11-22 13:43:04 not really 2016-11-22 13:43:19 yes we should move them or fix them 2016-11-22 13:43:27 alright 2016-11-22 13:43:55 you can use glide to fix it 2016-11-22 13:44:05 if they dont support proper vendoring 2016-11-22 13:44:21 and this .v$PKGVER thing should also support vMAJOR(.MINOR(.PATCH)) symlink collapsing, so you could require 1.2.x for instance and it would work with any 1.2.x version (installing latest 1.2.x by default, of course) 2016-11-22 13:44:51 nmeum: or any other go dep manager if the project supports it. 2016-11-22 13:45:03 ok 2016-11-22 13:45:13 community/hub even seems to support vendoring nowadays 2016-11-22 13:45:46 nmeum: https://wiki.alpinelinux.org/wiki/APKBUILD_examples:Go 2016-11-22 13:46:04 I would like to have a few examples so others could use them. 2016-11-22 13:46:28 but still, some go project have custom makefile magic which probable prevents easy packaging... 2016-11-22 13:47:11 well, .v$PKGVER symlinks shouldn't need to be always provided, they could be created only if there is package installed that depends on particular versions 2016-11-22 13:48:01 because providing them for all libs by default would easily add lot of files not really needed and used on most systems 2016-11-22 14:02:30 nmeum: have you read the commit message? what’s not clear?: “`go get` must not be used in APKBUILD, it downloads random dependencies 2016-11-22 14:02:30 from Internet without any verification, leads to unreproducible build.” 2016-11-22 14:02:50 nmeum: ofc we have rules, just not written yet 2016-11-22 14:02:58 jirutka: that wasn't my question I was assuming there were some kind of written rules 2016-11-22 14:03:07 *that 2016-11-22 14:03:37 nmeum: no, I checked that, there are no more pkgs in main/community using `go get`, except lego 2016-11-22 14:04:42 yeah community/hub seems to vendor dependencies nowadays 2016-11-22 14:04:43 nmeum: well, when you open a pull request with new aport, someone of us tell you that in review; the problem is with people who don’t know rules and have push rights 2016-11-22 14:06:57 nmeum: unfortunately there quite a lot stuff not written anywhere :( that makes the review process even more important (but ofc it’s not excuse for lack of documentation) 2016-11-22 14:07:59 nmeum: but hey, I hope that everyone know that downloading random sources without any verification (checksum) by the build tool of the software being packaged is forbidden, for very good reason 2016-11-22 14:08:27 nmeum: the problem is probably that not everyone knows what this go crap actually do 2016-11-22 14:10:04 probably. Besides it is pretty hard to detect if it is called from a makefile or build script 2016-11-22 14:10:28 pretty hard := you have to look at the makefile (which most people probably don't do) 2016-11-22 14:20:58 nmeum: that build script of hub is pretty bad aswell. probably better to just build by hand and remove bash. 2016-11-22 14:21:21 if you look at the build script provided by go developers.... 2016-11-22 14:21:38 makes you worry about the actual code 2016-11-22 14:30:13 <^7heo> s/the build script/anything/ 2016-11-22 14:30:32 <^7heo> s/the actual code/life/ 2016-11-22 14:32:43 nmeum: that’s why fabled is planning to forbid internet connection when running apkbuild, except the fetch phase ;) 2016-11-22 14:34:07 nmeum: i would use something like this: http://tpaste.us/Gx0w 2016-11-22 14:34:22 nmeum: so we must also review all existing go-shit apkbuilds if there’s no `go get` buried in crappy Makefile, great :( 2016-11-22 14:35:35 we should add it to the go build docs users should try to prevent (or mimic) the build scripts 2016-11-22 14:36:24 maybe it’d be easier to just forbid go… :P 2016-11-22 14:36:28 ACTION hides… 2016-11-22 14:36:47 Go away! 2016-11-22 14:36:59 o/ 2016-11-22 14:37:02 <^7heo> $ Go tohell 2016-11-22 14:37:15 ACTION reallocating myself to kitchen to make some coffee 2016-11-22 14:37:22 :D 2016-11-22 14:37:47 are you sure you are not statically linked to go? 2016-11-22 14:38:39 relocate yourself, don't reallocate yourself - you don't *know* where you end up when you realloc 2016-11-22 14:44:11 clandmeter: looks good to me, just push it? 2016-11-22 14:44:22 jirutka: yep 2016-11-22 14:44:49 nmeum: i didnt look closely what else they do in the build script 2016-11-22 14:44:54 i read something about tests 2016-11-22 14:45:14 they also add pass some ldflags to go build you might want to pass those as well 2016-11-22 14:45:20 s/add// 2016-11-22 14:45:23 nmeum: you also prevent stripping of go bins 2016-11-22 14:45:34 do you have bad experiances with it?> 2016-11-22 14:46:05 actually I am not the maintainer of that package and I don't use but last time I checked the go developers discouraged stripping of go binaries 2016-11-22 14:46:11 *use it 2016-11-22 14:46:32 i tried to look for it, but couldnt really find a up-to-date advise. 2016-11-22 14:46:41 and the bins get soo much smaller 2016-11-22 14:47:54 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717172 2016-11-22 14:47:57 yeah the ldflags is just to pass the version number 2016-11-22 14:48:21 yep 2016-11-22 14:48:44 ok 2016-11-22 14:50:45 i think we can provide ldflags to not include symbols 2016-11-22 14:51:06 and there was another flag to remove something else 2016-11-22 14:57:05 nmeum: what about using go build -v -ldflags '-s -w' 2016-11-22 15:02:55 skarnet: XD 2016-11-22 15:06:07 I haven't ended my thoughts before, because I lost internet connection and became busy w/ other stuff. 2016-11-22 15:06:31 clandmeter: I don't know if that is a good idea, we might want to ask upstream if that is supported? Maybe stripping is supported for binary compiled by the go 1.7 compiler, I don't know... 2016-11-22 15:07:00 is that the same as stripping? 2016-11-22 15:07:24 fabled: not sure whether you read what I wrote after your rebooting message. the lacking part is: patchelf --replace-needed /bin/or/lib/path $DEPSONAME $DEPSONAME.v$DEPPKGVER is what could be done post-build before packaging if particular version is required via APKBUILD's depends. apk would only need to provide those .v$PKGVER symlinks when needed. 2016-11-22 15:16:36 need to run. can continue discussion tomorrow. 2016-11-22 15:17:06 coredumb: well the -s ldflags omits all symbol information from the output file... 2016-11-22 15:17:12 *clandmeter (sorry) 2016-11-22 15:17:30 correct 2016-11-22 15:17:40 but thats not what the dveloper said about what goes wrong. 2016-11-22 15:17:48 it strips too much 2016-11-22 15:18:06 but this is not stripping if i read it correctly, its not adding. 2016-11-22 15:21:05 clandmeter: to be honest: I don't know isn't there some kind of 'official' go documentation on this? 2016-11-22 15:29:51 if there was we wouldnt have this dicussion :) 2016-11-22 15:41:48 community/hub also invokes `go get` 2016-11-22 16:46:33 i am trying to figure out why rc2 has broken modloop 2016-11-22 16:46:39 i have no idea what goes wrong 2016-11-22 17:07:05 ncopa, temporary network issue? 2016-11-22 17:10:43 it should build the modloop from local repo 2016-11-22 17:13:59 where and when modloop is created? 2016-11-22 17:16:44 BTW fabled, new apk cache should support downloading not-installed-yet upgrades, to support offline upgrade as separate step 2016-11-22 17:16:56 przemoc, yes, on list 2016-11-22 17:17:13 as well as apk cache that can be on network / shared mount between containers 2016-11-22 17:20:29 (I bind mount it already for lxc containers as I have /var/cache/apk-{v3.4,edge} on host. I do use separate /var/cache/apk for host's apk, though, just to be on the safe side.) 2016-11-22 17:24:18 alpine-iso's Makefile it seems 2016-11-22 17:26:54 jirutka: where? 2016-11-22 17:27:08 nmeum: in makefile 2016-11-22 17:27:55 new xen vulnerabilities http://xenbits.xen.org/xsa/ 2016-11-22 17:28:03 jirutka: it doesn't have a makefile 2016-11-22 17:28:31 sry, build script 2016-11-22 17:29:13 przemoc, it'll mostly work now; there's few race conditions in it. but in normal use they should not be an issue. 2016-11-22 17:30:00 nmeum: from apkbuild: # XXX this sucks a lot, it simply sets up GOPATH 2016-11-22 17:30:01 # and invokes go get afterwards thus we cannot 2016-11-22 17:30:01 # verify the integrity of the downloaded packages. 2016-11-22 17:30:26 but there’s a vendor directory, so maybe this comment is outdated? 2016-11-22 17:30:28 BTW I don't like mksquashfs, as it's not deterministic in my experience. with same input you get different images with each invocation. 2016-11-22 17:30:47 jirutka: the comment was out of date, I removed it http://git.alpinelinux.org/cgit/aports/commit/?id=cf4500f88be12b1c3c46ee90489758f9148d0c60 2016-11-22 17:30:56 and afterwards you moved the package to testing 2016-11-22 17:32:04 huh 2016-11-22 17:32:55 maybe i’ve read that on build machine and forgot to pull? 2016-11-22 17:34:20 but this pkg still don’t have a mantainer 2016-11-22 17:40:37 jirutka: should the source tarball in community/libvterm be more descriptive (e.g. $pkgname-$pkgver.tar.gz)? 2016-11-22 17:41:17 dsabogal: definitely, how the heck I’ve missed that 2016-11-22 17:41:22 ncopa: do you have logs from building isos? if not, then it would be good to keep them in future to investigate problems like in the case of modloop. is iso building automated and triggered by something (like new tag in aports)? 2016-11-22 17:41:22 dsabogal: thanks, I’ll fix it 2016-11-22 17:43:45 nmeum: slock 1.4 was released and includes fix for CVE-2016-6866 2016-11-22 17:44:01 ACTION is afk (relocation time) 2016-11-22 17:44:46 dsabogal: uhh, it didn't want to upgrade it before 3.5 is released but that changes things… 2016-11-22 17:48:27 I guess I will just backport the patch 2016-11-22 18:03:04 dsabogal: fixed, thanks for the heads up 2016-11-22 18:14:55 jirutka: it seems CVE-2016-1248 also applies to neovim (nmeum already fixed it for vim) 2016-11-22 18:15:21 dsabogal: could you please send PR? don’t have time now 2016-11-22 18:15:46 nmeum: you're not by chance already working on this one are you? 2016-11-22 18:16:22 dsabogal: I don't use neovim thus I am not working it 2016-11-22 18:16:40 ok, i'll look into this 2016-11-22 18:17:28 great