2018-02-01 00:53:02 Building an AMI, noticed that setting SWAP_SIZE and using `-s 0` doesn't actually prevent the swap partition being created. Had to hotpatch it out of setup-disk. Known bug? 2018-02-01 09:30:42 hi there! 2018-02-01 10:14:21 there’s a packages for bats, a shell testing framework, in community/bats. this project is abandoned, and succeeded by bats-core, a friendly(?) fork of it. as bats-core has quite some bugfixes that i need, i’d like to package it. however, bats-core doesn’t have any releases yet, so i’d need a git-version-package. first: if freezing on a commit, and noting in the version is that okay? 2018-02-01 10:16:23 secondly, would you prefer an update to the current package, or a new package? — since it’s a fork, i’d have intuitively started a new package named bats-core. 2018-02-01 10:17:34 if doing so, the question is how to tag the package? provides="bats" is not quite right, and i don’t see conflicts= (which is used by some packages) in dhe apkbuild docs … then there’s replaces, which seems to be made for moving file-owning between packages, so also not quite right 2018-02-01 10:17:36 what’s the most alpine-y way to solve this, if going that route? 2018-02-01 10:38:56 you have to make a snapshot and host it somewhere, i think the alpine infra has a storage for that, but i have no details. 2018-02-01 10:39:32 the snapshot can even be served by github 2018-02-01 10:40:09 something like https://github.com/bats-core/bats-core/archive/b1da565f92ad9dabf66831d0877542dcacc735b8.zip 2018-02-01 10:43:21 the more interesting question is whether creating a new package for this is the right way — and if so, how to properly handle the conflicting relation between the 2 packages 2018-02-01 10:49:33 i think there is a !replaces or so tag for dependencies 2018-02-01 10:51:36 yes, but the documentation says: »This package will "take over" files owned by packages listed in the replaces variable« … which is not quite what’s the case here 2018-02-01 10:52:23 i mean, most of bats-core has the same filenames/paths as bats, but it should simply not be possible to have both installed at the same time — not having both, with bats-core masquerading the files of bats(?) 2018-02-01 10:58:11 that's not what it means 2018-02-01 10:58:44 mh, then i misread the meaning of that field, sorry 2018-02-01 10:59:29 sorry, i can't really help you further right now as my headache is killing me, hopefully someone else can soon 2018-02-01 10:59:54 ah, a good example might be kodi that replaces="xbmc" 2018-02-01 10:59:55 oh, do get well! please don’t strain yoursel :/ 2018-02-01 11:01:03 in any case thanks :-) 2018-02-01 13:48:36 Nebukadneza: I guess bats-core continued exacly where bats it self ended, why not change upstream on the current bats package then, instead of creating a new one? 2018-02-01 13:49:45 HRio: that was my question exactly, i’m not sure myself :-) 2018-02-01 13:49:46 would everyone be okay with updating current bats from a release-version to a git-snapshot, i wonder? 2018-02-01 13:50:16 Nebukadneza: it seems only three packages in aports declare bats as checkdepends (and two of them are maintained by me). 2018-02-01 13:51:08 HRio: then this boils down to: are YOU fine with a git snapshot? :-) 2018-02-01 13:51:17 the third package is maintained by jirutka 2018-02-01 13:51:57 i can try to build these with the current snapshot … 2018-02-01 13:51:58 if you prepare a PR I can test my packages against that PR and comment in it :-) 2018-02-01 13:52:06 thanks 2018-02-01 13:52:20 sure, will do then, gimme 10 minutes :-) 2018-02-01 13:53:08 then I guess its also up to ncopa, if he is fine with a package built from a snapshot in community 2018-02-01 13:53:12 btw, how do you feel about ncurses as a dependency? i think having tput available really makes bats behave nicer 2018-02-01 13:53:35 does it work in travis with ncurses? 2018-02-01 13:53:54 well, it only uses tput from ncurses 2018-02-01 13:54:04 for some initialization magic 2018-02-01 13:54:13 if it detects a non-interactive terminal, not difference is seen 2018-02-01 13:54:24 so jenkins, travis, etc just stay working 2018-02-01 13:55:23 https://git.alpinelinux.org/cgit/aports/tree/community/bats/0001-test-bats-Add-fake-tput-to-fix-Alpine-tests.patch 2018-02-01 13:55:45 yes, that’s pretty much included now, we can get rid of that patch 2018-02-01 13:56:47 OK 2018-02-01 13:57:20 for me ncurses does not matter as its just a checkdepend, that also pulls bash :-) 2018-02-01 14:03:41 HRio: https://github.com/alpinelinux/aports/pull/3182 here it is … 2018-02-01 14:03:44 i hope you’re fine with this … 2018-02-01 14:03:54 please poke me if i fucked up anything ^_^ 2018-02-01 14:07:17 Nebukadneza: have you reported it upstream? 2018-02-01 14:07:28 you can file a bug upstream "please tag a new release" 2018-02-01 14:08:33 agreed, that’s probably a good idea too 2018-02-01 14:09:20 oh bummer https://github.com/bats-core/bats-core/issues/16 2018-02-01 14:10:22 TL;DR 2018-02-01 14:10:51 TL;DR, they’re a bit too relaxed about it 2018-02-01 14:10:57 i’m going to poke into this 2018-02-01 14:11:21 thank you! 2018-02-01 14:12:04 ✔ 2018-02-01 14:13:21 would you prefer waiting in this case? cough since i need it, i’d really like to have a snapshot-version somewhat soon~ish 2018-02-01 14:13:30 etckeeper and apt-dater-hosts, works fine with new bats, and also this PR https://github.com/DE-IBH/apt-dater-host/pull/24 2018-02-01 14:15:00 thanks for testing, you were a bit quicker than me :-) 2018-02-01 14:19:29 also git-secret from jirutka has !check 2018-02-01 14:19:50 so it will pass with new bats ;-) 2018-02-01 14:21:03 the reason they are disabled are that some of the tests are interactive 2018-02-01 14:22:34 yay 2018-02-01 14:25:54 ncopa: we have kind of the same situation with colormake, but that is stuck in testing due to no tags (or changes) from upstream. What do you think can we move it to community now? We are using it in a CI/CD setup without noticible issues. 2018-02-01 14:29:14 HRio: if we ship a git snapshot, then we are basically taking the responsability of making the release. I want upstream to do that for us 2018-02-01 14:29:24 and would like to avoid @edge http://url.../edge/testing in /etc/apk/repositories as there are warnings from apk due to this... and warnings shall trigger "stuff" 2018-02-01 14:29:33 if its working, why are upstream not tagging a release? 2018-02-01 14:29:47 upstream does not seem to do anything on github... 2018-02-01 14:30:03 https://github.com/pagekite 2018-02-01 14:30:14 are we talking colormake or bats now? 2018-02-01 14:30:17 they probably dont want support it? 2018-02-01 14:30:58 my thinking is: if does not want make release, the may have a reason for it 2018-02-01 14:30:59 they dont want support the code at current stage 2018-02-01 14:31:33 they have 18 repostiries all stale 2018-02-01 14:31:36 if we make a release for them, we end up taking the support too 2018-02-01 14:32:01 mhh 2018-02-01 14:32:07 sounds like upstream is dead? 2018-02-01 14:32:08 ok 2018-02-01 14:32:32 do we want support it? 2018-02-01 14:32:47 what im trying to say is, i want be careful 2018-02-01 14:33:41 mm, its kind of "feature" complete... but the compilers are a bit of a moving target. 2018-02-01 14:33:46 ;-) 2018-02-01 14:33:57 if you are ok to maintain it for upstream, then great! if not, then we should be careful 2018-02-01 14:35:22 I will think about it. its not that much code https://github.com/pagekite/Colormake/blob/master/colormake.pl, but its perl ;-( 2018-02-01 14:38:12 quite readable for perl though :-) 2018-02-01 14:38:55 ;-) and the best thing is that it works :-) 2018-02-01 14:41:46 nothing short of 2 miracles 2018-02-01 14:41:48 can i get an amen 2018-02-01 14:48:54 ncopa: last time we discussed colormake I opened this https://github.com/pagekite/Colormake/issues/22 2018-02-01 14:49:04 so, ncopa … you’d prefer to wait for an upstream release in the case of bats-core? 2018-02-01 15:14:34 jirutka: bah, I was considering going to FOSDEM with a belgian friend, but I'll be busy :( 2018-02-01 15:19:09 looking at kernel config 2018-02-01 15:19:18 CONFIG_BPF_SYSCALL=y is only set on s390x 2018-02-01 15:19:28 do we want that on x86_64 too? 2018-02-01 15:19:49 i thought grsec disabled that 2018-02-01 15:20:04 aha 2018-02-01 15:20:10 that is possible 2018-02-01 15:20:18 due to its risky? 2018-02-01 15:21:24 or maybe it was just BPF JIT 2018-02-01 15:23:20 new kernel got a new knob CONFIG_BPF_JIT_ALWAYS_ON 2018-02-01 15:25:07 https://www.spinics.net/lists/netdev/msg476553.html 2018-02-01 15:25:31 which depends on BPF_SYSCALL 2018-02-01 15:25:31 so it only showed up on s390x 2018-02-01 15:25:34 yes 2018-02-01 15:25:51 thats why i ask about BPF_SYSCALL 2018-02-01 15:26:10 BPF is quite useful on its own for diagnosing problems, performance issues 2018-02-01 15:26:26 i think we should either disable BPF_SYSCALL on s390x or we should enable it on the other arches 2018-02-01 15:29:56 personally I prefer to have more available tools to diagnose problems, so it would be nice to have it everywhere. 2018-02-01 15:31:16 but if there are good reasons against having it, then well, s390x will need to have it disabled too 2018-02-01 15:32:01 something else is enabling it on s390x 2018-02-01 15:32:05 ok its lunch.. bbl 2018-02-01 16:13:54 hum 2018-02-01 16:14:04 ok so what do i write in commit message for enabling BPF_SYSCALL? 2018-02-01 16:14:13 "may be nice to have"? 2018-02-01 16:14:26 -m "¯\_(ツ)_/¯@ 2018-02-01 16:14:27 we need better reason than that 2018-02-01 16:14:30 damn keyboard 2018-02-01 16:14:35 s/@/"/ 2018-02-01 16:15:37 i guess we wait with enable BPF_SYSCALL til there is a specific need/request for it 2018-02-01 16:15:40 we do have a request for AUDIT though 2018-02-01 16:15:43 https://bugs.alpinelinux.org/issues/8401 2018-02-01 16:23:39 ok its AF_KCM that pulls in BPF_SYSCALL 2018-02-01 16:23:46 its set to 'm' on s390x 2018-02-01 16:23:54 nobody cared about it on x86_64 apparently 2018-02-01 16:26:24 kernel connection multiplexor 2018-02-01 17:57:02 hi, what is the best way to get access to a ppc64le alpine box right now 2018-02-01 18:14:45 kaniini: is a lxc container enough? 2018-02-01 18:16:46 yes 2018-02-01 18:16:58 i have ppc64(be) but not ppc64le right now 2018-02-01 18:17:11 in theory same code works for either, but never know ;) 2018-02-01 18:32:23 ok i'll set a container up for you 2018-02-01 19:12:46 I enabled new issue announcement from redmine in this channel. Any issue with the format let me know. 2018-02-01 19:13:44 great! 2018-02-01 19:13:47 thanks! 2018-02-01 19:15:08 i guess only new issue announcements are of interest. else it could get a bit too verbose. 2018-02-01 19:16:00 Natanael Copa: there is currently no limit on project, so if we have private projects, that could be an issue. 2018-02-01 19:18:42 heh, color filter 2018-02-01 19:20:07 clandmeter: did you add that issue just to test? 2018-02-01 19:20:46 yes, and i will close it as fixed :) 2018-02-01 19:20:49 \o/ 2018-02-01 19:37:14 I can vouch for the validity of https://github.com/alpinelinux/aports/pull/3151 fwiw, that was originally a PR to Adelie and I redirected them to submit it to Alpine instead once I verified it fixed the issue 2018-02-01 19:41:05 https://github.com/alpinelinux/aports/pull/3141 needs applying ASAP, since tf won't run as-is. (mea culpa.) 2018-02-01 20:28:49 kaniini: do you know where we are on the kernel 4.14 upgrade? 2018-02-01 20:28:57 what is needed for us to switch to vanilla in the 3.7-stable? 2018-02-01 20:33:58 ipt-netflow and dahdi-linux are still missing 2018-02-01 20:36:09 i believe i can sort ipt-netflow, but i need help on dahdi 2018-02-01 20:41:11 i think in reality 2018-02-01 20:56:32 i took care of both ipt-netflow/dahdi-linux 2018-02-01 20:57:47 good! thanks! 2018-02-01 20:58:10 oh 2018-02-01 20:58:13 virtualbox 2018-02-01 21:00:04 isnt virtualbox in testing? 2018-02-01 21:00:22 i think i have some virtualbox work in some branch that i never finished 2018-02-01 21:00:35 virtualbox-guest-modules is in community 2018-02-01 21:00:44 ok 2018-02-01 21:00:59 needs fix then 2018-02-01 21:01:01 let me find the commit i have 2018-02-01 21:02:39 took care of that 2018-02-01 21:02:58 ok 2018-02-01 21:03:14 looks like we have a virtualbox-guest-additions in testing too 2018-02-01 21:12:03 i'm inclined to just leave that alone 2018-02-01 21:13:02 ok 2018-02-01 21:13:16 next step is to annotate the vanilla packages with provides= 2018-02-01 21:13:32 this will force apk to upgrade to vanilla 4.14 from hardened 4.9 2018-02-01 21:13:49 i think we should let that sit over the weekend 2018-02-01 21:14:01 see if there is any troubles 2018-02-01 21:14:14 if all is good, then we backport it all to 3.7 2018-02-01 21:14:29 there are definitively problems 2018-02-01 21:14:36 bootloader configs 2018-02-01 21:14:43 custom boot loaders 2018-02-01 21:14:47 xen 2018-02-01 21:14:56 iso image generation scripts 2018-02-01 21:15:02 indeed 2018-02-01 21:15:17 probably more unforseen 2018-02-01 21:15:33 so in that case i think we need to consider how to move forward with the migration 2018-02-01 21:15:34 sec fixes info was missed in this merge https://git.alpinelinux.org/cgit/aports/commit/?id=580f3ad70a6283a31bc29856820355ffbebea61b, it was here however https://github.com/alpinelinux/aports/pull/3144/files 2018-02-01 21:16:25 from apk side, to do the migration it is just a matter of rebuilding the packages with the proper annotations 2018-02-01 21:16:31 linux-grsec -> linux-hardened as requested by spender was not too bad 2018-02-01 21:16:48 but this is removing an entire profile, so more things will be affected 2018-02-01 21:19:58 so at this point, all of the modules we care about 2018-02-01 21:20:31 are available on -vanilla 2018-02-01 21:20:43 good. very good 2018-02-01 21:20:53 so it's literally just rebuild with the annotations now 2018-02-01 21:20:54 but i am not sure if we want to do this yet 2018-02-01 21:21:30 fabled: can you add the secfixes info for the clamav update? 2018-02-01 21:22:27 HRio, didn't see the github one. my bad. 2018-02-01 21:22:55 ncopa, since you're the one maintaining linux-hardened kernel on paper, i think i leave that decision to you :) 2018-02-01 21:23:11 :-) yes there are a few t-security on github 2018-02-01 21:24:02 the annotations we will want to do are 2018-02-01 21:24:22 provides="linux-grsec=${pkgver}-r${pkgrel} linux-hardened=${pkgver}-r${pkgrel}" 2018-02-01 21:24:26 for the main kernel(s) 2018-02-01 21:24:29 and 2018-02-01 21:24:40 provides="whatever-grsec=${pkgver}-r${pkgrel} ..." 2018-02-01 21:24:42 for the modules 2018-02-01 21:24:58 assuming all of that is there, apk will replace linux-hardened with linux-vanilla 2018-02-01 21:25:25 HRio, I merged the github PR's secinfo in a way that the PR should get closed 2018-02-01 21:25:32 we also need replaces 2018-02-01 21:25:33 i think 2018-02-01 21:26:00 replaces should not be necessary for either, but adding it to the main kernel packages would not be harmful 2018-02-01 21:26:21 if replaces were needed, you would not be able to install both kernel variants at the same time 2018-02-01 21:26:29 hm 2018-02-01 21:26:31 true 2018-02-01 21:26:45 fabled: great! 2018-02-01 21:27:18 ok i need to go 2018-02-01 21:27:27 lets discuss migration strategy tomorrow 2018-02-01 21:27:31 i need to go as well 2018-02-01 21:30:41 one thought i had 2018-02-01 21:31:04 instead of using annotations for the main package, we could use a transitional package which includes a symlink 2018-02-01 21:31:15 i am not sure how that would play out with some bootloaders, though 2018-02-01 21:31:32 diskless is fat32, som symlinks.... 2018-02-01 21:31:36 so 2018-02-01 21:31:37 but need to leave for real now 2018-02-01 21:33:41 fabled: as you are working on patchwork, be careful with the shadow change 2018-02-01 21:35:14 I was not subscribed to the list when it was posted, so I could not reply to it, but have been discussing it with Drew 2018-02-01 21:35:26 hrio: diskless is irrelevant 2018-02-01 21:35:58 diskless setup the kernel booted is the one on the ISO 2018-02-01 21:36:00 ok, as long as update-kernel handles the change of pkg name? 2018-02-01 21:38:35 are we getting rid of the hardened kernel? 2018-02-01 21:43:49 4.9 was their last release https://grsecurity.net/passing_the_baton.php 2018-02-01 21:43:59 for the community 2018-02-01 21:51:48 Yeah. 2018-02-01 22:05:07 freenode_ceruleis[m]: this channel is also on matrix see topic. 2018-02-01 22:18:02 Looks like gdb http://build.alpinelinux.org/buildlogs/build-edge-ppc64le/main/gdb/gdb-8.0.1-r5.log is failing to build. I'll take a look at it unless someone else has any insights? 2018-02-01 22:26:31 clandmeter: neat ty 2018-02-01 22:26:46 yw 2018-02-01 22:27:17 Don't suppose you have any comments on my swap issue? :^) 2018-02-01 22:29:42 not today, about to go to bed. i can check it tomorrow. 2018-02-01 22:32:37 np ty 2018-02-01 22:48:37 chromium's build system sucks too complicated 2018-02-01 23:08:03 for abuild.conf the default is 2 jobs but TOP reports more spawn compile units. its there a way to cap it? to the number of cpu cores? 2018-02-01 23:09:29 or N-1 cores 2018-02-02 01:08:03 no 2018-02-02 01:08:04 you have to specify 2018-02-02 02:10:06 i need a way to cache the github clone 2018-02-02 02:10:18 it takes too long trying to download 2018-02-02 02:14:05 If I clone then tar.gz it and reference it in sources= it will unpack the local copy right? 2018-02-02 02:14:49 place it in the same location as the patches 2018-02-02 02:16:05 the package system is very immature 2018-02-02 02:38:17 I don't understand what that means 2018-02-02 02:38:33 If you download the .tar.gz referenced in sources= and put it in /var/cache/distfiles, then it will work, yes. 2018-02-02 02:48:13 I have a C question, not really Alpine thing. The executable has a symbol _abc_xyz but when I run it in gdb, its value is zero. What might be the catch ? 2018-02-02 02:59:49 what i am saying is will abuild precheck the server before checking distfiles 2018-02-02 03:00:53 on gentoo you can tell ebuild (equivalent to abuild) to not check by putting a fetch restriction 2018-02-02 03:03:59 i don't think it will check because it would check the hash first. 2018-02-02 03:13:00 before stepping in? 2018-02-02 03:13:16 or on return? 2018-02-02 05:13:14 it checks to see if file is in /var/cache/distfiles 2018-02-02 05:13:18 if it does not match the right checksum 2018-02-02 05:13:20 it will delete it 2018-02-02 05:13:23 and redownload 2018-02-02 05:13:52 because our "very immature" package system is clearly inferior to gentoo in all ways 2018-02-02 05:13:55 ACTION eyerolls 2018-02-02 05:27:27 good night kaniini 2018-02-02 05:31:40 not really immature but lacking certain things friendly to package creators 2018-02-02 05:33:09 like extra modules or functions per different build system like the eclass system in gentoo 2018-02-02 05:33:48 if that is not created then it creates duplicate code within the packages itself 2018-02-02 05:35:14 Because kernel-2 and toolchain are the epitome of packaging, right? >_> 2018-02-02 05:36:10 the duplicate code creates problems like the patching boilerplate code doesn't do dry run so what happens is that it is a partial patch then i end up trying to disable up to the patch 2018-02-02 05:36:47 Patching is done by abuild now. Any package that does it in prepare is old and should be updated. 2018-02-02 05:37:13 I wish Matrix had hostmasks, I would request recovering-gentoo-victim.foxkit.us <_< 2018-02-02 05:37:33 then people like in the rust APKBUILD don't do return sanity checks return 1 2018-02-02 05:38:14 APKBUILDs are run with -e 2018-02-02 05:38:34 'return 1' isn't required either and is line noise 2018-02-02 05:39:30 for sed commands will still pass through as if okay it is all good 2018-02-02 05:39:44 even though it didn't patch it properly 2018-02-02 05:40:29 `sed` should not be used to patch. 2018-02-02 05:40:53 Also, packages with fetch restrictions shouldn't be packaged for Alpine. Alpine requires all packaged software to be libre, free, and redistributable. 2018-02-02 05:41:14 depends on the convention 2018-02-02 05:41:22 here is is not okay 2018-02-02 05:41:42 in Arch and Gentoo it is okay 2018-02-02 05:42:14 > There is also RESTRICT="fetch", which prevents Portage from trying to fetch anything manually. The pkg_nofetch function will be called if any SRC_URI components cannot be found. This should only be used if a license requires it. 2018-02-02 05:42:27 Any package with such a license is not compatible with Alpine's packaging guidelines 2018-02-02 05:43:06 Or are you talking about RESTRICT="primaryuri"? Because abuild will /always/ try the actual source URL listed 2018-02-02 05:46:50 no there is a trick 2018-02-02 05:47:14 Okay. Why don't you tell me what this "trick" is... 2018-02-02 05:48:38 We've already given you the answer to your original question (yes, abuild checks /var/cache/distfiles before it downloads files from the server, but it will skip /var/cache/distfiles if the checksum doesn't match the checksum in the APKBUILD sha512sums) 2018-02-02 05:49:00 i meant that you don't want the ebuild/portage to refer to the SRC_URI you can use the RESTRICT="fetch" and use git functions 2018-02-02 05:50:14 And, as someone who spent many years of their life trying to improve Gentoo to be shut out and dismissed over petty crap perpetuated by comrel, I think I know a great deal more about Gentoo than most everyone here 2018-02-02 05:50:31 You don't fetch-restrict live ebuilds, you override fetch 2018-02-02 05:50:48 Er, src_unpack that is 2018-02-02 05:51:06 i don't really remember i was just guessing 2018-02-02 05:51:16 https://devmanual.gentoo.org/ebuild-writing/functions/src_unpack/svn-sources/index.html 2018-02-02 05:51:49 what I was looking for was for abuild to cache the git but doesn't do that here 2018-02-02 05:51:59 or doesn't say in the APKBUILD document 2018-02-02 05:52:13 See main/kamailio 2018-02-02 05:52:44 The preferred way is to make a snapshot using git fetch and git archive, upload that to Alpine servers as a snapshot archive .tar.gz, and use that 2018-02-02 05:53:08 There's a few others if you grep -r 'git clone' **/*/APKBUILD in aports.git 2018-02-02 05:53:46 That way you aren't wasting network bandwidth, CPU time, disk space, etc on every builder (which Alpine have many, for different versions and different CPU architectures) with `git` 2018-02-02 05:54:40 And indeed, rootbld doesn't even support network access during builds (think FEATURES="network-sandbox" enforced) 2018-02-02 05:55:18 So you can't hit git in `unpack`, it's too late to make a network connecti othen 2018-02-02 05:55:23 Network connection then* 2018-02-02 06:45:54 I created the snapshot but I cannot create a checksum for it 2018-02-02 06:48:51 is scp upload public and how long will it stay up there for snapshot? 2018-02-02 06:50:38 or is that only available for the builder? 2018-02-02 06:50:45 machine 2018-02-02 09:21:07 ncopa: re. main/ncurses@3.6-stable it seems that 20171125 $source tarball is no longer available on mirror 2018-02-02 09:21:37 ncopa: likewise for kbd, it seems to have relocated to https://www.kernel.org/pub/linux/utils/kbd/kbd-2.0.4.tar.gz 2018-02-02 10:52:18 Hi All, a qq 2018-02-02 10:53:06 Any idea as when would the latest version of puppeteer be supported on Alpine? As of now it is 0.12.0, I am looking for 0.13.0 or 1.0.0 2018-02-02 11:44:37 <_ikke_> Amount of open issues on github is increasing: https://zabbix.alpinelinux.org/history.php?action=showgraph&itemids[]=28584 2018-02-02 12:11:25 clandmeter: you not coming t o FOSDEM? 2018-02-02 13:32:01 jailbox: ncurses is a mess :-/ 2018-02-02 13:58:37 ncopa: no need to 'hurry' a fix for my sake, i just tried to unpack and noticed, so i did a "s/p20171125/p20180121/" to get some src 2018-02-02 14:41:35 Shiz: im afraid not. 2018-02-02 14:41:39 Shiz: you need a ride? 2018-02-02 14:41:43 nah i'm already there 2018-02-02 14:41:53 was just hoping for more cool peeps to show up 2018-02-02 14:42:47 ah nice. I think i will try to attent next year. 2018-02-02 14:43:11 tmh1999: gdb 8.1 fails to build on s390x: 2018-02-02 14:43:17 ACTION sent a long message: ncopa_2018-02-02_14:43:12.txt  2018-02-02 14:43:33 the current s390x patch does not apply so i removed it 2018-02-02 15:08:39 "authetification" 2018-02-02 15:51:29 ncopa : working on it. currently doing the setup-disk.in script 2018-02-02 16:14:33 is there a policy on which version of qt and gtk to compile with? for edge. does alpine officially default to gtk3, it is up to upstream to decide, or we can force gtk3? 2018-02-02 16:15:09 i prefer gtk3 because of smooth scroll 2018-02-02 16:16:25 on electron they force gtk2 by default but you can repatch it with gtk3 2018-02-02 16:17:13 hah this fpreg again... we've had it before in s390x. 2018-02-02 16:28:56 when it comes to py2/py3 packages, I build and install for each python version into the respective $subpkgdir 2018-02-02 16:29:15 but the py-$pkgname package is tiny compared to the other ones, what is the logic behind this, exactly? 2018-02-02 16:32:44 i think py-$pkgname is like a meta package the dependency will choose either py2 or py3 2018-02-02 16:33:28 thought as much 2018-02-02 16:34:00 but it's supposed to be an "empty" metapackage, right? 2018-02-02 16:34:29 ah screw it, it's for patchwork - mind reviewing it in a bit, clandmeter? it'll go to alpine-aports@lists.a.o 2018-02-02 16:34:48 i don't know but it could be a placeholder 2018-02-02 16:34:58 the committer will see 2018-02-02 16:36:52 god dammit, I just reproduced a package nearly to detail due to a typo when first looking for an existing package 2018-02-02 16:37:50 oh well, git reset and git pull it is 2018-02-02 18:10:31 <^7heo> I'm convinced it's very wrong to export PS1 in the /etc/profile 2018-02-02 18:10:52 <^7heo> it relies on every shell to set their own PS1 at invokation, and that cannot be reliably done. 2018-02-02 18:11:01 <^7heo> especially since ash does NOT read any rc file. 2018-02-02 18:11:11 <^7heo> (unless invoked as login shell) 2018-02-02 18:12:09 I feel like I'm missing context; that started with "especially since ash does NOT read any rc file." 2018-02-02 18:12:15 Did the Matrix bridge skip a few lines? 2018-02-02 18:12:20 <^7heo> nope. 2018-02-02 18:12:30 <^7heo> ash does not read any rc file if it's not started as login shell. 2018-02-02 18:12:44 <^7heo> if it is started as login shell, then it does read various profile files. 2018-02-02 18:12:50 Same with bash 2018-02-02 18:13:07 <^7heo> bash always reads bashrc. 2018-02-02 18:13:14 <^7heo> no matter if started as login shell or not. 2018-02-02 18:13:21 <^7heo> and zsh also does. 2018-02-02 18:13:58 <^7heo> the only files read by ash when started are /dev/tty, ~/.ash_history and /etc/passwd 2018-02-02 18:14:17 <^7heo> if started as login shell, you will also have: /etc/profile and /etc/profile.d/*.sh 2018-02-02 18:14:58 <^7heo> (btw when I said 2018-02-02 18:15:07 ACTION sent a long message: AWilcox[m]_2018-02-02_18:15:07.txt  2018-02-02 18:15:12 <^7heo> "zsh also does", I meant: it also reads its own rc file) 2018-02-02 18:15:17 I just put `echo "It's bashrc..."` in /etc/bash/bashrc 2018-02-02 18:15:59 <^7heo> yeah in /etc/bash/bashrc, but I'm talking about your ~HOME/.bashrc there. 2018-02-02 18:16:17 <^7heo> I actually never use bash, so I'm not sure what is the behavior of bash. 2018-02-02 18:16:28 Oh. 2018-02-02 18:16:34 <^7heo> I know that zsh reads .zshrc when starting tho; no matter if it's a login shell or not. 2018-02-02 18:17:10 Yes, and bash reads your $HOME bashrc. 2018-02-02 18:17:21 <^7heo> yeah 2018-02-02 18:17:26 <^7heo> but my point is: ash does not read anything. 2018-02-02 18:17:30 I don't know what that has to do with PS1 though, or ash. 2018-02-02 18:17:40 <^7heo> so the ONLY way to be sure that every child of the login shell will have the proper PS1 is to export it. 2018-02-02 18:17:45 <^7heo> However, this is wrong. 2018-02-02 18:17:59 <^7heo> Because you cannot unexport a variable. 2018-02-02 18:18:09 <^7heo> You can unset one, but if re-set it will be exported again. 2018-02-02 18:19:12 It sounds like ash is just a pain to deal with if you want a custom PS1 2018-02-02 18:19:24 <^7heo> So long story short; since ash does NOT read any file when starting; if you export PS1 when executing the login shell, and then another shell comes around and sets it (without exporting it mind you) to its own value; then any subsequent call of ash will use that PS1 2018-02-02 18:19:46 <^7heo> AWilcox[m]: all that is needed is for ash to read a simplistic $HOME/.ashrc 2018-02-02 18:20:03 <^7heo> but fixing it by exporting PS1 is just plain wrong. 2018-02-02 18:20:07 <^7heo> and that's what Alpine is doing. 2018-02-02 18:20:13 I agree. 2018-02-02 18:21:03 <^7heo> Yeah so, should I open a PR? 2018-02-02 18:21:10 <^7heo> 'cause I already commited a fix locally. 2018-02-02 18:25:03 Do you have a patch for ash to read .ashrc? 2018-02-02 18:25:56 <^7heo> no I did not write that part. 2018-02-02 18:25:59 <^7heo> but it should be trivial. 2018-02-02 18:26:14 <^7heo> I only unborked alpine so far. 2018-02-02 18:26:40 <^7heo> AWilcox[m]: https://github.com/7heo/aports/commit/c18e2c023fbfd0bf6ac24c1b54bf2ca02627e4ab 2018-02-02 18:27:26 <^7heo> AWilcox[m]: that would be the commit that would be in the PR I would open. 2018-02-02 18:27:52 <^7heo> I am not sure if I should spend the time to contribute to busybox; as my patch will likely be rejected. 2018-02-02 18:28:04 <^7heo> (at least I expect any patch, ever, to likely be) 2018-02-02 18:28:14 <^7heo> (not specifically with busybox) 2018-02-02 18:29:27 That is not a very compatible /etc/profile heh 2018-02-02 18:29:38 <^7heo> AWilcox[m]: I just changed the export. 2018-02-02 18:29:41 <^7heo> AWilcox[m]: I'm not gonna fix the rest. 2018-02-02 18:29:49 <^7heo> I mean, I remember the patch trying to implement less -r; being rejected directly because someone mentionned systemd in the context of the patch. 2018-02-02 18:30:04 and that's a bad thing because? 2018-02-02 18:30:07 :P 2018-02-02 18:30:17 <^7heo> skarnet: because refusing a patch for the wrong reasons is wrong. 2018-02-02 18:30:23 The escape sequences aren't standardised 2018-02-02 18:30:31 <^7heo> yeah well... 2018-02-02 18:30:39 <^7heo> At this rate, the output of ls also isnt. 2018-02-02 18:30:43 https://code.foxkit.us/adelie/adelie-base/blob/master/tree/etc/profile < this is a POSIX /etc/profile 2018-02-02 18:30:45 <^7heo> s/isnt/isn't/ 2018-02-02 18:31:27 <^7heo> AWilcox[m]: I'd double quote the EDITOR value and PAGER value. 2018-02-02 18:31:36 <^7heo> You never know if they were previously set with spaces in them. 2018-02-02 18:32:01 it's a login shell. 2018-02-02 18:32:13 You're supposed to know what the environment is like at this point. 2018-02-02 18:32:18 Ooh, good point! 2018-02-02 18:32:52 skarnet: The order of initialisation scripts is implementation-defined. /etc/profile may be read first, or last, or intermediately, compared to other shell-specific initialisation scripts. 2018-02-02 18:32:56 <^7heo> AWilcox[m]: I'm eating POSIX sh for breakfast those days. Those are not happy days; but I hopefully spot stuff like that better ;) 2018-02-02 18:33:21 if you can't swear what the value of EDITOR and PAGER are by the time /etc/profile is run, then I don't want to have anything to do with your login system. 2018-02-02 18:33:39 <^7heo> AWilcox[m]: also kudos for using whoami and uname -n in the PS1 2018-02-02 18:34:00 <^7heo> skarnet: you can swear they contain spaces; in some cases. 2018-02-02 18:34:11 ... 2018-02-02 18:34:18 <^7heo> what? People do weird things. 2018-02-02 18:34:21 <^7heo> Really. 2018-02-02 18:34:52 what part of "at this point, the user is JUST logging in, so you should know the state the process is in" is hard to understand? 2018-02-02 18:35:36 <^7heo> the part where the profile script is getting that information from the process itself. 2018-02-02 18:36:00 the process comes from login(8). The state it's in is DOCUMENTED. 2018-02-02 18:36:14 knowing what your system does is so 2017 2018-02-02 18:36:40 <^7heo> skarnet: is it documented anywhere that the env variables EDITOR and PAGER shall not contain any space character? 2018-02-02 18:36:48 <^7heo> because if so, that's news to me. 2018-02-02 18:37:18 <^7heo> (or, maybe that NO variable in the environment shall contain space characters; maybe. But same, that'd be news to me) 2018-02-02 18:37:45 Okay, I've just checked 2018-02-02 18:38:08 Yes, /etc/profile is read in first, before any other shell rc, by every shell we (Adelie) ship except fish 2018-02-02 18:38:19 <^7heo> except fish :D 2018-02-02 18:38:51 This is documented by the maintainers of fish: "fish is not a POSIX 1003.1-compliant shell, and does not read /etc/profile. If you are using Linux, use /etc/environment; otherwise, consider /etc/login.defs." 2018-02-02 18:39:01 <^7heo> AWilcox[m]: but can you swear that any login(8) any user will ever use will let EDITOR and PAGER unset? 2018-02-02 18:39:52 I can audit the code of login(8) later tbh 2018-02-02 18:39:55 I have actual work to do today lol 2018-02-02 18:39:59 <^7heo> sure :D 2018-02-02 18:40:01 ^7heo: you don't seem to understand what I'm saying 2018-02-02 18:40:07 <^7heo> skarnet: maybe I'm not. 2018-02-02 18:40:19 <^7heo> skarnet: I'd actually not be against learning :) 2018-02-02 18:40:48 login descends from getty, which descends from init (more or less). All this chain of processes is controlled by root. So you're supposed to *know exactly what your environment is* at this point. 2018-02-02 18:41:10 Nowhere in this chain do users have the opportunity to mess up the environment the machine is configured with. 2018-02-02 18:41:20 they mess up the environment _later_. 2018-02-02 18:41:33 <^7heo> well, they'd do so, by replacing the components; if at all. 2018-02-02 18:41:47 <^7heo> and if POSIX does NOT specify what login(8) should NOT do with the environment... 2018-02-02 18:41:54 <^7heo> it'd still be posix to set EDITOR or PAGER. 2018-02-02 18:42:22 ok, I give up. I'll try again when you've turned your brain on. 2018-02-02 18:42:29 <^7heo> :D 2018-02-02 18:42:40 <^7heo> I'll tell you when I'm sober. 2018-02-02 18:43:34 FWIW, login(8) etc are not specified by POSIX on purpose. 2018-02-02 18:43:37 POSIX provides a list of variables it is unwise to tinker with. that is about the only reference it makes to PAGER and EDITOR, AFAICT: http://pubs.opengroup.org/onlinepubs/7908799/xbd/envvar.html 2018-02-02 18:43:43 The Open Group doesn't touch authentication, leaving it (on purpose) up to the implementation 2018-02-02 18:43:45 <^7heo> AWilcox[m]: yeah that I didn't know tho. 2018-02-02 18:44:02 <^7heo> I was currently wondering why login wasn't on opengroups 2018-02-02 18:45:07 <^7heo> But so there's no way to know what a POSIX system would do with the environment prior to calling /etc/profile, or is there? 2018-02-02 18:45:13 ENVIRON_FILE (string) 2018-02-02 18:45:14 If this file exists and is readable, login environment will be read from it. Every line should be in the form name=value. 2018-02-02 18:45:34 That's the man page of shadow's login.defs(5) 2018-02-02 18:45:46 <^7heo> yeah. 2018-02-02 18:45:47 So yes, you definitely can set EDITOR and PAGER before /etc/profile is read 2018-02-02 18:45:57 But that is implementation-defined 2018-02-02 18:46:01 <^7heo> great. 2018-02-02 18:46:23 <^7heo> so you could set crap there, including spaces; before /etc/profile is read. And still be POSIX. 2018-02-02 18:46:42 I don't know if shadow would accept spaces; it says name=value 2018-02-02 18:46:46 yes, if you're an admin 2018-02-02 18:46:50 Now I really need to audit the code of login(8) to be sure :P 2018-02-02 18:46:58 can a USER change that environment? 2018-02-02 18:47:03 <^7heo> skarnet: yeah well; anyone's an admin those days. 2018-02-02 18:47:12 <^7heo> this is one of those handholding vs education discussions. 2018-02-02 18:47:20 okay, so 2018-02-02 18:47:24 <^7heo> should we let the clueless admins break their systems or not. 2018-02-02 18:47:28 skarnet, no, but the point is adelie's /etc/profile should be usable even if an administrator changes ENVIRON_FILE. 2018-02-02 18:47:37 <^7heo> AWilcox[m]: ^ what I said. 2018-02-02 18:47:46 This argument is literally about adding two sets of double-quotes to a shell script 2018-02-02 18:47:50 It's 4 bytes to make everything safe 2018-02-02 18:48:02 AWilcox[m]: that's the first sensible thing I've heard on this subject, and I can't object to that 2018-02-02 18:48:06 <^7heo> yeah but skarnet has a point: maybe we WANT them to learn it's not safe. 2018-02-02 18:48:07 hi theo welcome back 2018-02-02 18:48:29 <^7heo> kaniini: hey kaniini; I'm just here to complain, don't worry, I'll be gone asap :D 2018-02-02 18:48:40 <^7heo> damn I should not drink so much before IRCing. 2018-02-02 18:48:47 <^7heo> sorry for the double highlight. 2018-02-02 18:48:57 <^7heo> bbl. 2018-02-02 18:49:12 It's one thing to know you shouldn't, but it's another thing to actually stop doing it :) 2018-02-02 18:49:21 <^7heo> AWilcox[m]: fair 'nuf. 2018-02-02 18:49:21 this argument isn't about two sets of doublequotes, it's about knowing what state your processes are in. But if the goal is supporting admins who change that state, then okay. 2018-02-02 18:49:29 <^7heo> that ^ 2018-02-02 18:49:52 <^7heo> I'll go play pool now; I will have less chances to do weird crap. 2018-02-02 18:49:53 <^7heo> laters. 2018-02-02 18:50:34 inb4 hospital calling, patient came in with a cue stick stuck in weird places 2018-02-02 19:07:30 actually. 2018-02-02 19:07:33 ACTUALLY. 2018-02-02 19:10:43 ACKCHUYALLY 2018-02-02 19:24:40 wrong chat :p 2018-02-02 19:25:44 "should we let the clueless admins break their systems or not." 2018-02-02 19:25:47 well 2018-02-02 19:25:58 when it comes to alpine, i mean, i don't really care either way 2018-02-02 19:26:55 when it comes to adelie, if some clueless person opens a ticket complaining their system is broken, well, that takes resources away from assisting people who actually know what they are doing and need our help for something interesting 2018-02-02 19:28:04 so it seems like if we can go out of our way to mitigate the possibility of a clueless admin breaking their system, that's probably good for business right? 2018-02-02 19:30:22 yes 2018-02-02 19:30:31 I have no objection to more safety :P 2018-02-02 19:38:40 OSHA-compliant computing experiences obviously 2018-02-02 21:17:22 The update we did in ncurses crashes anything that is based libtermkey/unibilium and tmux 2018-02-02 21:17:54 I guess it is this https://github.com/mauke/unibilium/issues/30 2018-02-02 21:18:59 which means my computer turned completey useless, I have to edit in nano without tmux! 2018-02-02 21:59:06 Hello. Is there some well known issue with php7 on 3.7 ? I am getting segfaults 2018-02-02 22:12:08 nvm, php5 seems to work 2018-02-03 01:37:02 can we use patches from arch linux to build an alpine package? or do we need to do chinese wall cleaning room design? some of these are just 1 liner patches 2018-02-03 01:39:13 depends on what kind of patch 2018-02-03 01:39:35 pkgbuilds and apkbuilds are for entirely different systems, just so that's clear 2018-02-03 01:39:57 if it's shell, it has to be ash, and if it's anything C, it has to build with musl 2018-02-03 01:42:48 it's for webkit and electron. i can eliminate some patches to be less dependent on them 2018-02-03 01:43:20 oh god 2018-02-03 01:43:28 CEF and electron is gonna be a great deal of fun 2018-02-03 01:43:33 electron is a platform for building gui apps for javascript 2018-02-03 01:43:40 i am fully aware of what it is and how it works 2018-02-03 01:43:49 :') 2018-02-03 01:43:51 i have it someone compiling 2018-02-03 01:44:02 what? 2018-02-03 01:45:01 [1659/19991] still bugs third_party/WebKit/Source/platform/wtf/Assertions.cpp:146:3: error: unknown type name 'Dl_info' 2018-02-03 01:47:41 that's a struct from dlfcn.h 2018-02-03 01:47:56 which exists in musl-dev 2018-02-03 02:42:19 I think the problem was the conditional. I changed !defined(__UCLIBC__) to defined(__GLIBC__). 2018-02-03 04:55:26 wtf i put abuild startx and it launches X how is that possible 2018-02-03 05:02:44 :D :D :D 2018-02-03 05:03:03 abuild just execs whatever is $1 2018-02-03 05:03:04 you can even do 2018-02-03 05:03:07 abuild rm -rf / 2018-02-03 05:03:12 ;) 2018-02-03 05:03:12 well 2018-02-03 05:03:13 not really 2018-02-03 05:47:45 I can't hook ccache to GN/ninja 2018-02-03 06:22:39 lmao 2018-02-03 06:23:42 i fixed it 2018-02-03 06:24:17 had to add cc_wrapper = "ccache" 2018-02-03 06:24:47 i should distcc this 2018-02-03 06:25:50 good luck with that 2018-02-03 06:29:42 it doesn't really speed things up maybe shave off an hour or 3 for chromium 2018-02-03 06:30:36 the people at google use goma they said it takes 30 mins 2018-02-03 06:31:06 best case 2018-02-03 19:53:52 <_ikke_> clandmeter: ^ nice 2018-02-03 23:35:28 hum my emojis can't load when I startx 2018-02-04 00:01:38 err noto-color-emoji is a bit broken on chromium and it doesn't work on xfce4-terminal 2018-02-04 00:01:55 on my gentoo setup i had it working on both 2018-02-04 00:02:49 okay I see that it is disabled in cairo 2018-02-04 00:02:59 i will make a pull request to enable it 2018-02-04 00:14:01 err apk add is complaining about breakage. i incremented the pkgrel and there should be no change in the ABI. 2018-02-04 00:14:32 oh that is because cairo-dev 2018-02-04 00:28:12 In Alpine does it store information about version information of dependency on the main package? 2018-02-04 00:29:33 It would require to compile the main package if I update the dependency's package rel right? 2018-02-04 00:50:33 apk del is being rebellious won't allow me to remove package it keeps installing instead 2018-02-04 00:52:46 if you have other rules which pull in the particular package, apk won't let you remove it. 2018-02-04 00:55:41 i think i found out why its because the .makedepends 2018-02-04 04:56:42 are there any "rules" on sequence of abuild cmd's (or maybe inter-depends between cmd's) that one should know about? like is there any diff between 'unpack, clean, undeps' and 'unpack, undeps, clean' etc. 2018-02-04 05:00:28 there at least used to be a part in abuild itself that has the sequence neatly in one place 2018-02-05 02:02:15 ncopa : the gdb bug is s390x thing or ppc thing ? it seems to be okay after the gdb ppc patch few days ago ? 2018-02-05 04:31:58 oh crap it is pulling more npm packages. i gotta check a ton of licenses again. 2018-02-05 09:16:18 what does flagged mean in the package database? 2018-02-05 09:16:29 flagged for removal? 2018-02-05 09:20:36 oh out of date 2018-02-05 09:54:40 flagged out of date 2018-02-05 18:41:58 https://lists.spdx.org/pipermail/spdx-legal/2018-February/002462.html 2018-02-05 18:42:26 Y'all may want to keep up with that thread. I'm trying to figure out what license identifier to use for main/bind. They have a few special licenses that aren't in any of {OSI, FSF, SPDX}... 2018-02-05 22:36:01 Should packages that have .zips makedepends="unzip"? 2018-02-05 22:36:12 Or should unzip be added to abuild's depends=? 2018-02-05 22:36:17 good question 2018-02-05 22:36:36 i think the latter, because xz for example is a dependency of abuild 2018-02-05 22:36:39 abuild already has lzip and such in depends=, so it may make more sense to put unzip in there 2018-02-05 22:37:07 yes 2018-02-05 22:45:14 i think i didnt add unzip as depends since busybox provides an unzip 2018-02-05 22:47:59 Ad§' 2018-02-05 22:48:01 er 2018-02-05 22:48:15 Adélie doesn't use busybox. 2018-02-05 22:49:24 That's our problem. I didn't realise it was a busybox thing. I'll just carry a patch in our abuild package, no worries 2018-02-05 22:51:03 probably have busybox provides="unzip" then have abuild depend on unzip, then? 2018-02-05 22:51:10 yes, i think that is the way to do it 2018-02-05 22:52:39 we dont automatically add all the busybox's provides=cmd:... 2018-02-05 22:52:52 becase the symlinks are not shipped with the package 2018-02-05 22:53:00 the busybox package is a hack basically 2018-02-05 22:56:48 Not only that, but if unzip is installed then busybox stops providing it because of the way the trigger works (iirc) 2018-02-05 22:58:50 yes 2018-02-05 22:59:15 are there many package that uses .zip? 2018-02-05 22:59:43 i think fixing provides for busybox is in the apk3 roadmap 2018-02-05 23:04:37 docbook-xml is so far the only one 2018-02-05 23:05:14 But do note, I haven't built the entirety of main/ yet for Adelie 2018-02-05 23:10:32 ncopa: there are some things in the roadmap towards apk3 that will enable busybox to be less of a hack yes 2018-02-05 23:10:51 It's just docbook-xml, espeak, fts, glm, hunspell-en, logtail, lua-sqlite, proxychains-ng, five very old py-* modules, qextserialport, uvncrepeater, and then a few ttf-* fonts. 2018-02-05 23:10:54 That's all the packages that use .zip 2018-02-05 23:11:22 And three of those are just because they are using the GitHub auto-zip thing that can also do .tar.gz 2018-02-05 23:13:08 auto-zip? that's uh, downloading a commit/branch directly? 2018-02-05 23:13:28 releases provides at least zip, usually tgz and a tar.bz2 2018-02-05 23:14:05 Yes 2018-02-05 23:18:03 It doesn't seem like _FORTIFY_SOURCE=0 is needed any more for findutils (we removed it in Adelie almost a year ago and haven't seen any bad things, and in fact the test suite passes as well). Should I remove it as part of our PRs? 2018-02-05 23:18:18 The commit log comment was that "gnulib breaks fortify source, so for now we disable it" 2018-02-05 23:20:36 they probably fixed it upstream 2018-02-05 23:20:47 i think the simplest thing to do for now is add unzip as makedepends for those few packages that needs it 2018-02-05 23:21:40 we could make unzip an abuild dependency too, but it would add another package needed to be boostrapped 2018-02-06 06:43:25 the font-noto is missing chinese, korean, japanese (cjk) use same package or seperate? 2018-02-06 06:47:26 there is no free alternative for comic sans in the package database. we could package Comic Neue. https://en.wikipedia.org/wiki/Comic_Neue 2018-02-06 06:49:26 fantasque-sans is the monospaced comic sans for programmers https://github.com/belluzj/fantasque-sans 2018-02-06 07:48:02 i packaged Comic Neue. working on fantasque-sans. the latter has some dependencies not found in the package database. 2018-02-06 08:13:34 *morning 2018-02-06 08:14:09 ncopa: say … about our recent bats-on-git-snapshot discussion: while my upstream comment got lots of upvotes, nothing seems to have moved 2018-02-06 08:19:18 (on upstream-side, that is) 2018-02-06 08:19:20 how do you feel about the idea meantime…? 2018-02-06 08:41:05 this is a dependency nightmare 2018-02-06 09:04:08 i need to run paxmark before run.py ./mksnapshot is run but GN script makes it difficult to do compared to simple edits with autotool scripts 2018-02-06 15:27:16 fabled: i think the s390x build failure may be an apk-tools bugg 2018-02-06 15:27:37 `apk add lua-dev` fails on the builder, but not in my dev env 2018-02-06 15:28:35 huh 2018-02-06 15:28:42 i dunno if we want investigate it closer 2018-02-06 15:28:56 lua5.1-dev has a provides=lua-dev 2018-02-06 15:31:25 i think it is related that it does not have access to the http repos 2018-02-06 15:31:45 i mean, only local repos are in /etc/apk/repositories 2018-02-06 15:32:57 fabled: would you like to analyze it or should i just work around it 2018-02-06 15:33:12 i think i can change makdepends=lua-dev to makedepends=lua5.1-dev 2018-02-06 15:33:30 and it will work 2018-02-06 15:35:39 so what's the problem? 2018-02-06 15:35:47 i think apk is working as expected 2018-02-06 15:35:57 you ask for lua-dev, but it's pure virtual provides so it's not auto selected 2018-02-06 15:36:12 lua5.1-dev should have provides=$pkgver-r$pkgrel instead 2018-02-06 15:36:42 oh 2018-02-06 15:36:49 or it's the provider_priority now 2018-02-06 15:37:46 provides priority is not in .PKGINFO 2018-02-06 15:37:51 maybe just recompile lua5.1 ? 2018-02-06 15:37:56 it was probably built with too old abuild 2018-02-06 15:38:12 aha 2018-02-06 15:38:30 that may make sense 2018-02-06 15:38:37 so, first update abuild, then rebuild lua5.1 2018-02-06 15:38:39 let me try that 2018-02-06 15:38:53 y 2018-02-06 15:39:44 yup 2018-02-06 15:39:46 that worked 2018-02-06 15:40:15 thats a thing we need to fix with the new build infra 2018-02-06 15:40:38 first check everything in the build-base and abuild tree 2018-02-06 15:40:38 and build those first 2018-02-06 15:40:51 abuild is not in the dependency tree and may be built late 2018-02-06 15:42:29 thanks! 2018-02-06 15:42:57 you're welcome 2018-02-06 15:43:37 on armhf: /usr/lib/gcc/armv6-alpine-linux-musleabihf/6.4.0/../../../libboost_context-mt.so: undefined reference to `std::__get_once_mutex()' 2018-02-06 15:43:49 i think i have seen something similar earlier 2018-02-06 15:51:44 tmh1999: s390x has a test in 'gc' that fails 2018-02-06 16:08:37 yoho 2018-02-06 16:08:50 … regarding what to do with the bats/bats-core package 2018-02-06 16:09:41 hi 2018-02-06 16:09:52 ncopa: can i quickly get on your nerves again a bit? 2018-02-06 16:09:59 i'd like to continue ping upstream 2018-02-06 16:10:04 (also, broken internet here messed my message order … sorry) 2018-02-06 16:10:16 i need to reloace 2018-02-06 16:10:16 relocate 2018-02-06 16:10:18 bbl 2018-02-06 16:12:13 mh, ok — so you oppose merging the current snapshot proposal? 2018-02-06 16:12:13 should i (or can you?) close the issue in that case? or shall we leave it open as a flag for upstream? 2018-02-06 16:12:16 np, laters :-) 2018-02-06 16:16:14 im ok keeping it open 2018-02-06 16:22:54 oki, let’s stay with that then 2018-02-06 16:47:09 ncopa, you think https://github.com/alpinelinux/aports/pull/3140/files is ok? 2018-02-06 16:55:28 do I change up community/py-pyldap's setup.cfg? 2018-02-06 16:55:33 # Linux distributors/packagers should adjust these settings 2018-02-06 16:55:39 and we're only making a minimal build 2018-02-06 17:23:53 is there a way to specify mutual exclusive package? 2018-02-06 17:24:17 yes 2018-02-06 17:24:20 put the other package as !package in depends 2018-02-06 17:25:33 fabled: well, we need to make sure file is cross-compileable 2018-02-06 17:36:04 i think it was for mips 2018-02-06 17:36:27 i can look into getting us some help with mips, i have an idea about someone who can help 2018-02-06 17:36:34 they might just provide build hw too 2018-02-06 17:38:15 im ok with it (give file is crosscompileable) 2018-02-06 17:38:15 i mean, im ok with https://github.com/alpinelinux/aports/pull/3140/files assuming its possible to crosscompile file. 2018-02-06 17:40:15 considering i've seen it everywhere and it's a standard unix program, i would assume so 2018-02-06 18:00:48 ncopa: seems like collectd is still not picking up lua-dev. hum 2018-02-06 18:01:09 doing the gc thing 2018-02-06 18:04:10 koldbrutality: koldbrutality, would it be a good idea to have aliases for pkgname either a metapkg or embedded in pkg itself (various languages), this could reduce some related complexities 2018-02-06 18:06:17 I think the same could be done for licenses in aports (eg. apkbuild.meta file) 2018-02-06 18:06:27 example "GPL-2.0+" is equally valid to "GPL-2.0-or-later" 2018-02-06 18:07:36 or a single file in eg aports/.meta OR aports/.meta/aliases 2018-02-06 18:10:46 as for other language pkg name, even search could be applied, and on advanced apk/installer specify lang=chinese in command line, then 2018-02-06 18:11:22 but that is just rough idea 2018-02-06 18:12:59 gtg, would read logs, if someone replies ;) 2018-02-06 18:17:02 oops, sorry, I misread koldbrutality's msg 2018-02-06 18:18:05 was trying to digest logs, I took it as other lang chars in pkg name ;) 2018-02-06 18:21:38 kaniini: can you review https://github.com/alpinelinux/aports/pull/3154 for me? 2018-02-06 18:30:26 wow, the ifdefs in `gc` for detecting and setting thread stack size is impressively complicated 2018-02-06 18:30:47 lots of ifdefs for misc platforms 2018-02-06 18:31:03 does abuild not honor the EXTRADEPENDS_BUILD env var? 2018-02-06 18:31:51 i'm trying to setup a cross compile to other arches and its appearing that its not actually installing the stage2 gcc that gets built 2018-02-06 18:43:31 Does anyone see why it is breaking CI for https://github.com/alpinelinux/aports/pull/3215 ? 2018-02-06 18:46:22 koldbrutality, https://travis-ci.org/alpinelinux/aports/builds/338137426?utm_source=github_status&utm_medium=notification 2018-02-06 18:46:27 seems temporary networking glitch 2018-02-06 18:48:10 i see what what went wrong... it has a different implementation of mv 2018-02-06 18:48:29 and the log didn't expand the full log 2018-02-06 18:50:22 mv on remote doesn't support -t 2018-02-06 18:53:11 my system has coreutils version of mv but the remote has the busybox version of mv 2018-02-06 18:53:20 how did that happen? 2018-02-06 18:53:42 I thought the toolchain was isolated 2018-02-06 19:11:44 vkrishn: just stick to what is listed in https://spdx.org/licenses/ no alias needed 2018-02-06 19:16:21 clandmeter: you created the noto package. merge or seperate package for noto-cjk? for the chinese-japanese-korean set 2018-02-06 19:26:10 figured out my issue, local abuild was too old 2018-02-06 19:26:36 also had to add make to gcc and musl dev depends to get bootstrap.sh to succeed 2018-02-06 19:26:45 and learnt don't bootstrap more than one arch at a time 2018-02-06 19:28:28 second question, anyone try installing alpine linux on a nvidia tx2? 2018-02-06 21:09:06 ncopa : gc indeed, can you just allow the build-edge-s390x to continue to build and upload packages to https repo, instead of just stucking in main ? 2018-02-06 21:09:25 gc sometimes 2 segfault for me on s390x. sometimes 1. still working 2018-02-06 21:15:47 in fact the bug was introduced since 7.6.0, not just 7.6.4 2018-02-06 21:16:17 tmh1999: test runs out of stack 2018-02-06 21:17:21 iirc musl is 81920 hum 2018-02-06 21:17:42 tmh1999: https://github.com/ivmai/bdwgc/issues/202 2018-02-06 21:18:09 okay you are too quick ncopa 2018-02-06 21:18:16 yes, code i supposed to deal with it but hits a cornercase 2018-02-06 21:18:36 vkrishn, if you're still around: there's no real need to do all that because SPDX 3 tools are required to support SPDX 2 terms. the problem lies more in the ambiguity of terms like 'GPL-2.0'. 2018-02-06 21:18:36 i spent a while trying to figure out what really happens 2018-02-06 21:18:51 thanks a lot 2018-02-06 21:20:00 still working on it. seems interesting one. could learn a little bit more o/ 2018-02-06 21:20:31 code is misleading 2018-02-06 21:20:51 what happens is not what you would expect after reading the code 2018-02-06 21:21:06 i can tell what i did 2018-02-06 21:21:33 first thing was i noticed there was a segfault 2018-02-06 21:21:34 so i enabled core dumps 2018-02-06 21:21:53 well first thing is to report it upstream, they often have an idea why things goes wrong 2018-02-06 21:22:31 after i got a core dump i did a backtrace which looked like a recursive function 2018-02-06 21:22:34 500 calls deep or so 2018-02-06 21:22:47 at that point i was pretty convinced it ran out of stack 2018-02-06 21:22:57 since its a common problem with musl 2018-02-06 21:23:29 so i searched the code with 'ag' (the_silver_searcher) 2018-02-06 21:23:32 ag pthread_create 2018-02-06 21:23:34 or similar 2018-02-06 21:23:47 and found tests/test.c 2018-02-06 21:24:14 no, actually, i looked for the c file generating gctest, and found tests/test.c 2018-02-06 21:26:06 where i found the define DEFAULT_STACK_MAYBE_SMALL 2018-02-06 21:26:06 i injected a #error foo within the #ifdef to see if it was set at compile time 2018-02-06 21:26:07 and found out that it was not set 2018-02-06 21:26:28 a comment the include/private/gccconfig.h indicated that it was supposed to be set for musl (NO_GETCONTEXT should be set with musl libs) 2018-02-06 21:27:06 tat was basically it 2018-02-06 21:27:08 except that there are 2 pthread_create calls 2018-02-06 21:27:21 https://code.foxkit.us/adelie/patches/blob/master/dev-libs/boehm-gc/boehm-gc-7.4.2-testsuite.patch I think this maybe never got upstream 2018-02-06 21:27:21 I'm not sure 2018-02-06 21:27:56 first is not a problem (and code does reverse of what you'd expect) 2018-02-06 21:28:40 A. Wilcox: aha 2018-02-06 21:28:43 yeah that may make sense 2018-02-06 21:29:19 nice ! 2018-02-06 21:29:27 in general, the code is messy and upstream seem to prefer fix it by adding more mess 2018-02-06 21:29:36 :D 2018-02-06 21:33:54 tm1999: main finally built on s390x 2018-02-06 21:35:27 beautiful 2018-02-06 21:36:29 o/ yay uploading 2018-02-06 21:49:07 looking at its issues page, it has history with musl before 2018-02-06 21:49:40 looks like upload hang 2018-02-06 21:55:57 jirutka: im gonna disable mruby on armhf. build fails 2018-02-06 22:13:29 ncopa : there were time when we/you had to disable s390x, maybe you left some config somewhere that not allowing it to upload packages ? 2018-02-06 22:14:35 no, i think its network issue 2018-02-06 22:15:18 what's up with s390x? 2018-02-06 22:15:29 dunno 2018-02-06 22:15:36 what are the symptoms and guesses? 2018-02-06 22:15:42 builder does rsync, but it seems to have hung 2018-02-06 22:15:50 strace show anything interesting? 2018-02-06 22:16:08 and is a connection made and the protocol initialized? 2018-02-06 22:17:45 also `rsync -v` or `rsync -vv` (older rsync) 2018-02-06 22:18:06 strace lacks needed permissions 2018-02-06 22:18:53 strace: Process 55046 attached 2018-02-06 22:18:54 select(9, [8], [], [8], {38, 629149} 2018-02-06 22:19:02 thats the local process 2018-02-06 22:19:04 nothing happens 2018-02-06 22:19:56 same with the ssh rsync --server 2018-02-06 22:22:27 lacks permissions, bleh 2018-02-07 04:24:26 is there an APKBUILD template to create desktop menu entry? 2018-02-07 04:25:59 i think i found something 2018-02-07 04:51:09 musl doesn't have isnanf? 2018-02-07 04:56:39 isnan should work on floats and doubles 2018-02-07 05:01:29 yeah i used that with #define isnanf isnan 2018-02-07 05:02:20 i'm packaging the godot game engine right now 2018-02-07 07:37:56 i got 3.0 godot to run but i can't load the demos... going to try 2.1.4 stable 2018-02-07 09:46:17 godot 2.1.4 works but i'm not getting 3d acceleration for some reason with the 3d platformer demo 2018-02-07 09:47:01 the 2d platformer demo is fast enough 2018-02-07 10:03:36 the truck town level was more faster but not too slow 2018-02-07 10:20:50 scons doesn't autodetect ccache 2018-02-07 13:57:04 bah 2018-02-07 13:57:22 no way to compile qt5 5.10 with libressl 2018-02-07 14:20:02 fcolista: qt 5.10 does not support libressl? 2018-02-07 14:20:32 nope...and i can't find a patch to make it work 2018-02-07 14:21:29 tried to patch it but still having error on OPENSSL_STACK undeclared 2018-02-07 14:37:40 same... 2018-02-07 14:38:06 tried it, patch doesn't apply and trying to patch it manually still errors out 2018-02-07 14:41:20 PureTryOut[m], me too 2018-02-07 14:41:38 i need qt5 for gns4 and wireshark 2018-02-07 14:41:43 which crashed on qt5 as well 2018-02-07 14:41:57 Error relocating /usr/lib/libQt5Widgets.so.5: _ZN16QFileSystemEntry10isRootPathERK7QString: symbol not found 2018-02-07 14:48:56 i need to follow up on the bash hang bug 2018-02-07 14:49:08 which is not yet fixed for 32bit 2018-02-07 14:49:43 https://bugs.alpinelinux.org/issues/8447 2018-02-07 14:50:01 i also need get the s390x build complete and upload the packages properly :-/ 2018-02-07 15:03:22 ncopa, i'm looking at package upgrades 2018-02-07 15:03:29 anything against https://github.com/alpinelinux/aports/pull/2964 ? 2018-02-07 15:03:39 or https://github.com/alpinelinux/aports/pull/3053 ? 2018-02-07 15:11:41 im ok with upgrading wine 2018-02-07 15:12:00 im trying to figure out that bash hang bug 2018-02-07 15:12:12 apparently it still affects 32bit 2018-02-07 15:13:21 im ok with docker upgrade too 2018-02-07 15:17:03 ok 2018-02-07 15:17:17 how about the boost upgrade to 1.66.0 ? 2018-02-07 15:17:42 im ok as long as we rebuild everything needed at the same time 2018-02-07 15:17:55 it may require some work... 2018-02-07 15:17:58 i see 2018-02-07 15:20:45 ocaml-csv build fails 2018-02-07 15:32:19 since we are doing mass rebuilds 2018-02-07 15:32:30 opinion on swapping openssl-dev back as default ssl (and keeping libressl-dev for things that use libtls etc) 2018-02-07 15:33:04 2038 bug and increasing upstream API divergence are the main concerns 2018-02-07 15:45:00 re 2038 bug and libressl 2018-02-07 15:45:08 LibreSSL folks clearly state that they don't guarantee they will fully implement later OpenSSL APIs 2018-02-07 15:45:15 later than 1.0.1 2018-02-07 15:45:31 upstream libressl says its a problem in linux kernel, due to time_t being 32bit 2018-02-07 15:45:51 they will not work around that 2018-02-07 15:45:56 przemoc: that is not problem 2018-02-07 15:46:20 przemoc: there are *regressions* in the support of openssl 1.0.1 APIs 2018-02-07 15:46:32 which basically means we have to chose between: replace kernel or replace libressl 2018-02-07 15:46:42 kaniini: ok, so that's even worse than I thought. 2018-02-07 15:47:44 beyond that, libressl would still not be a valid provider of openssl because they do not follow upstream, imo 2018-02-07 15:48:06 that said, they're right when they say the 2038 bug is due to time 2018-02-07 15:48:09 _t being 32bit 2018-02-07 15:48:20 time_t needs to be 64-bit before 2038, there's no way around that 2018-02-07 15:48:59 while true 2018-02-07 15:49:01 it is being worked on upstream 2018-02-07 15:49:52 I meant that because not whole world switched to libressl, not supporting openssl APIs later than 1.0.1 can be bothersome to say the least and problem may increase in future. but regressions in existing 1.0.1 API are much worse 2018-02-07 15:50:04 and they removed support for code that did work correctly (by using a structure instead of time_t) 2018-02-07 15:50:35 yeah, the major problem is the 1.0.1 regressions that have been introduced in later libressl releases 2018-02-07 15:51:29 i don't really have any opinion on libressl itself, i just do not think it is good to say "libressl is equivalent to openssl" 2018-02-07 15:52:09 my opinion on the openssl API is essentially "try to use anything else wherever possible" 2018-02-07 15:54:14 skarnet: its true, but its not an easy switch. will break ABI, so it is going to take time. kernel itself does not need to support y2038 yet, but certificate handling needs to handle it now 2018-02-07 15:54:14 (the time_t thing is one of several API regressions really) 2018-02-07 15:54:14 and we dont parse certificates in kernel 2018-02-07 15:54:15 probably the most painful though ;) 2018-02-07 15:54:15 so we need a temporary workaround til kernel time_t is fixed 2018-02-07 15:54:44 BTW is there any collective ticket regarding all these regression against openssl 1.0.1 found in libressl? 2018-02-07 15:54:49 is this telling me that the cross built gcc conflicts with gcc? https://gist.github.com/mitchty/38f099adb81268782ae6aa354e9aef55 2018-02-07 15:54:50 that one screws you at build time (if code used the calendar math structures) as well as runtime 2018-02-07 15:55:28 libressl upstreams response is "we dont support broken kernels" which translates to "we dont support linux" 2018-02-07 15:55:38 mitchty: yes basically 2018-02-07 15:56:01 which makes one wonder why bother with a libressl portable at all ;) 2018-02-07 15:56:02 if so, how exactly do I run bootstrap.sh as /usr/share/abuild/functions.sh looks for gcc when you source it in bootstrap.sh 2018-02-07 15:57:15 the issue is g++ not gcc 2018-02-07 15:57:15 ;) 2018-02-07 15:57:46 (more helpfully, your bootstrap.sh adventure should probably begin in a chroot) 2018-02-07 15:58:25 kaniini: +1 on the "libressl portable" 2018-02-07 15:58:25 looks like its more libstdc++ 2018-02-07 15:58:41 so i think 2018-02-07 15:58:47 we should swap back 2018-02-07 15:58:51 keep libressl around for now, for libtls 2018-02-07 15:58:54 see if we can isolate it out 2018-02-07 15:59:12 fabled: what do you think about switching back to openssl? 2018-02-07 15:59:36 we need keep libressl around for a while yes 2018-02-07 15:59:51 should ask what void linux ppl thinks too 2018-02-07 16:01:35 i'm not sure what that has to do with anything but ok 2018-02-07 16:10:19 mitchty: yes, but g++ is what is pulling in libstdc++ 2018-02-07 16:16:19 kaniini: right but it appears abuild depends on it as well, so I'm a bit unclear how i can bootstrap without abuild present 2018-02-07 16:20:31 example https://gist.github.com/mitchty/c711464d6f5f0436ba564909ccb797aa 2018-02-07 16:22:43 i'm a bit confused how a chroot will help in this regard, unless i just copy /usr|/bin|etc into the chroot and then run off an apk db that is mostly empty/lies? 2018-02-07 16:29:55 ncopa, i'm not sure on openssl. but it seems akamai picked up openssl and it has significant development since. 2018-02-07 16:30:23 otoh, libressl went ahead to delete stuff like the engine api so it's slowly becoming more limited on what it can do 2018-02-07 16:30:39 so it might be an idea to revisit the question... or at least to reply something on the mailing list thread 2018-02-07 17:31:00 mitchty, that tripped me up for months 2018-02-07 17:31:12 mitchty, then I realised: the issue there is you have -r5 installed on your host and -r6 as your cross. 2018-02-07 17:31:33 mitchty, if all the -rX match, it DOES work 2018-02-07 17:34:04 AWilcox[m]: O.O that... is super unintuitive thanks, guess I need to update from edge then 2018-02-07 17:38:16 AWilcox[m]: wow, first time i'm seeing bootstrap.sh get to building the kernel, danke 2018-02-07 17:39:25 mitchy: cool, but I thought fabled already made the aarch64 cross- work done ? 2018-02-07 17:39:59 tmh1999: i'm trying to get ghc building for all the other arches 2018-02-07 17:40:39 mitchy: ah ghc. it's been for a while, isn't it 2018-02-07 17:41:31 kudo to fabled made the bootstrap.sh and apk-tools, abuild so clean for cross-compiling 2018-02-07 17:41:37 tmh1999: yeah, and i hit bugs with armhf for 8.2.2 due to ... something but for now 8.0.2 is cross compilable similar to how I got it onto AL originally 2018-02-07 17:42:31 basically its like go, build first compiler then build off that natively, i'm wanting to make sure it all works 2018-02-07 17:43:04 plus people were asking for 32bit x86, and i wanted 64 bit arm as well so might as well kill all those birds while i'm at it 2018-02-07 17:43:17 and ppc i suppose if/when i get to it 2018-02-07 17:45:47 unless there is an easier way to go about this i'm unaware of 2018-02-07 17:53:16 adélie has been working on x32. unfortunately, llvm is kinda a stumbling block due to the single-.so build being >4GB (in part due to insisting on leaving in debug symbols) 2018-02-07 19:41:58 Aerdan, that is solved 2018-02-07 19:42:08 Aerdan, we shipped llvm4 on x86 shortly after the parasites were gone 2018-02-07 19:42:31 oh. well then. 2018-02-07 19:42:31 mitchty, you're welcome :) I had to stumble on it for almost three months 2018-02-07 19:42:45 mitchty, if you need ppc computer access let me know 2018-02-07 19:43:11 Aerdan, also fwiw x32 is "32-bit pointers on 64-bit". x86 is "32-bit x86". and x86_64 or x64 is "64-bit x86" (though x64 can be confused with Itanium, because Windows calls Itanium x64) 2018-02-07 19:44:09 mitchty, I have ppc32 and ppc64 (not ppc64le). I can give you an account on the ppc32, it is basically available to any Alpine/Adelie person (at least skarnet and kaniini have accounts) 2018-02-07 19:47:44 Aerdan, anyway the way I solved it was very unclean but it did work fully. I used 64-bit computer to compile it with the 32-bit binutils, so it used PAE or whatever and went right ahead and used up 6.1 GB. then stripped it, down to 1 GB :) 2018-02-07 19:52:55 jeez. 2018-02-07 19:54:38 glad I don't have to deal with that mess, tbh. 2018-02-07 20:09:55 tmh1999: fftw tests seems to hang 2018-02-07 20:09:56 on s390x 2018-02-07 20:10:06 ncopa : i saw that 2018-02-07 20:10:17 my guess is that it is related to openmp 2018-02-07 20:10:19 we had similar issue with imagemagick 2018-02-07 20:10:40 i ended up disable openmp for imagemagick on s390x 2018-02-07 20:32:05 not sure if make -j1 helps, but i am building 2018-02-07 20:35:07 i dont think make -j1 will help 2018-02-07 20:35:32 i think its the openmp feature in gcc that is broken and deadlocks 2018-02-07 20:38:02 i disabled openmp in fftw on s390x 2018-02-07 20:38:05 would be nice to fix openmp though 2018-02-07 20:38:19 eg, fix gcc 2018-02-07 20:40:55 ncopa: noted that. i will do the overhaul of the git log for s390x. 2018-02-07 20:42:22 i wonder if there are some libgomp testsuite 2018-02-07 20:42:28 we need a testcase to reproduce it 2018-02-07 20:42:43 GCC has a rather massive test suite of all of its libraries 2018-02-07 20:42:59 yeah 2018-02-07 20:43:01 Unfortunately, when I ran it on Adelie, about 12000 test cases out of the 39000 failed 2018-02-07 20:43:27 :) 2018-02-07 20:43:59 I may be dedicated to fixing upstreams but that was a bit much for my blood ;) 2018-02-07 20:44:37 what? that is disappointing XD 2018-02-07 20:47:14 Whoever runs the Matrix server, it seems to have the wrong timestamp. I'm sending this message at 14:47:00 2018-02-07 20:47:20 Matrix says I sent it at 14:46 2018-02-07 20:47:31 Unless it's Quaternion bug again... 2018-02-07 20:50:05 looks like quaternion bug, I see 14:47 here on nheko. 2018-02-07 20:51:50 Nice. 2018-02-07 20:56:38 This is an interesting one. 2018-02-07 20:56:47 So this package has the GPL 2.0 license in ./COPYING. It has an RPM spec file, which just says "GPL" for license. None of the source files have a header of any kind. 2018-02-07 20:57:35 Does that make it GPL-2.0-only, or is it GPL-1.0+? 2018-02-07 20:58:25 I'm looking specifically at GPL 2.0 §9, which states: 2018-02-07 20:58:30 If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation. 2018-02-07 20:58:46 The Program does not specify a version number of the license in any place. 2018-02-07 21:00:06 I'd say GPL-2.0-only, given that the full text of GPL-2.0 is given in COPYING but no other hints are given. 2018-02-07 21:00:09 people sometimes refer to whatever GPL version by GPL, and in files like RPM spec, Makefiles and what not there are rarely any license notices. what's in the source code's license notice should be determining factor here IMHO 2018-02-07 21:01:23 The source code has no license notice at all, not even that it is GPL. Unless you mean the COPYING file, in which case I'm still not 100% sure specifically because of GPL 2 §9, but I guess GPL-2.0-only is a "safe" choice? 2018-02-07 21:03:49 I'd say GPL-2.0-only for now, and file a ticket with upstream asking them to please annotate their source with their license intentions. 2018-02-07 21:03:50 LIke I said, the COPYING file specifically states "you may choose any version ever published" 2018-02-07 21:04:22 COPYING (GPL 2.0 license) file alone does not determine if it's -only or -later variant, sadly. if there is no license notice that clarifies authors intent, I believe that -later is what should be used (even though I'm not fan of that). 2018-02-07 21:05:03 s/-later/-or-later/ of course 2018-02-07 21:05:20 The author abandoned it in 2009 2018-02-07 21:06:37 so GPL 3 was already there and author did not explicitly reject optional upgrade 2018-02-07 21:10:29 ACTION sent a long message: AWilcox[m]_2018-02-07_21:10:28.txt  2018-02-07 21:10:30 I found this mailing list post from author in 2011 2018-02-07 21:10:31 It looks like it is GPL 2 only 2018-02-07 21:10:37 I really don't like this upgradeable feature of GPLv2, because it's messy, especially because not everyone puts license notices to make clear how they see this matter, and if they don't care, it's sadly another argument for going -or-later, because restrictions to v2 only are mostly added by people that care 2018-02-07 21:10:55 The person was asking if it could be used in a GPL3 project and author said no 2018-02-07 21:11:09 ok, that clarifies it 2018-02-07 21:11:16 as GPL-2.0-only 2018-02-07 21:11:31 i think that makes that clear then :) 2018-02-07 21:11:42 I will go ahead and put link to https://sourceforge.net/p/gtkspell/mailman/message/27291338/ in commit message 2018-02-07 21:13:46 but people should really add license notices, especially for GPL stuff. even if it isn't canonical one (which is a bit verbose), in one line you can state whether it's GPL v2 "only" or "or later". 2018-02-07 21:15:18 I totally agree. It's unfortunate we can't poke maintainers when they are writing code initially to do that :P 2018-02-07 21:16:51 "Guile is covered under the terms of the GNU Lesser General Public License, version 3 or later. See COPYING.LESSER and COPYING." 2018-02-07 21:16:57 Which is the GPL, not the LGPL 2018-02-07 21:17:12 They ship GNU readline, which is GPL-3, as part of Guile's REPL 2018-02-07 21:17:25 But all of Guile's source code is LGPL 2018-02-07 21:17:28 Oh, I do love it when this happens. 2018-02-07 21:17:34 I think this is "GPL-3.0+ AND LGPL-3.0+" 2018-02-07 21:18:38 You can't really pull readline out of the binary to make it LGPL only, at least not without a recompile, so we couldn't split it out and make the split package GPL 2018-02-07 21:19:53 I wouldn't use AND, because part of the code uses one license, and other part uses another one. that's why I suggested in my mail using (possibly ", " in practice) to not deal with it. 2018-02-07 21:22:52 I see AND and OR only as operators to state multi-licensing in statements like "This code is licensed under the terms of THIS and THAT" or "This code is licensed under the terms of THIS or THAT, whichever suits you better" put in license notices within source files 2018-02-07 21:24:55 having allow us to not think whether OR or AND is better in SPDX terms and if it will be clarified definitely by them ever, we'll be able to easily change such into whatever they want to be 100% conformant 2018-02-07 21:25:03 i suspect what we really need is to implement your proposal to bring copyright metadata file to alpine 2018-02-07 21:29:48 Maybe I should just not touch guile license field 2018-02-07 21:30:17 At least until the separator is agreed on, or we use the copyright metadata file 2018-02-07 21:30:55 use comma i think 2018-02-07 21:31:50 Okay 2018-02-07 21:33:37 temporarily tracking copyright can be done outside of aports, as I suggested, with scripts to integrate it into current license var. sorry I'm a bit behind with it, but I have some other problems to deal with. when aports will get better at handling properly structured data in future, because happy shell variables are not the best way forward, we will be able to reintegrate license info in better 2018-02-07 21:33:43 way, because we'll still be having it in uncluttered way, outside of APKBUILDs 2018-02-07 21:39:58 tbh I hoped there would be a bit more discussion on ML regarding fixing license mess effort, but it's can of worms, arduous task, and not really rewarding. I really believe that it requires many eyeballs and I meant it strongly when I wrote that at least 3 people should verify the license of package before it will seem ok-ish and therefore ready to be also used in APKBUILD replacing what's already 2018-02-07 21:40:04 there in license field. 2018-02-07 21:41:44 I'm not sure, though, if I wrote the mail in the right moment, because it may seem now as I don't want to move it forward because of lack of concrete and visible actions regarding it. 2018-02-07 21:43:09 przemoc: I'm trying to throughly review, but since there was no agreement on # license looked at by:, there's not much beyond git blame 2018-02-07 21:43:43 I'd be more than willing to help with a more focused/obvious review later 2018-02-07 21:43:51 ok, good to hear that 2018-02-07 21:45:10 (right now we are just trying to make sure that $license is basically correct for the adelie supported package set, because we're greedy ;)) 2018-02-07 21:45:48 Not so much greedy, just I'd have to fix everything /else/ in the other APKBUILDs too (spaces vs tabs, modernise, remove || return 1, replace dumb repeated patch logic with default_prepare, etc.) 2018-02-07 21:45:53 That'd leave me no time to actually bump and improve stuff :P 2018-02-07 21:47:46 if someone has time to review this: here's a PR to fix the git errors appearing when running abuild without git installed: https://github.com/alpinelinux/abuild/pull/32 2018-02-07 21:50:50 I can understand that too, kaniini. Adelie has its own agenda. my idea of doing this work outside of aports and APKBUILDs may not seem appealing to many, especially in AL community, I presume, as it may seem as not AL-oriented enough. but maybe when I'll have time do initial tasks of writing scripts and having some packages done, then maybe it will be easier to find more people supporting the 2018-02-07 21:50:56 idea and willing to help, even outside of AL, because I believe it may benefit all distributions out there 2018-02-07 21:52:15 well, it's more that they're focused on adelie right now due to wanting to ensure alpine community/ can be used with adelie safely. 2018-02-07 21:52:36 which is involving a lot of commit-shoveling. 2018-02-07 21:53:33 and if they're busy doing that they might as well tackle licensing on the packages they're working on. ;) 2018-02-07 21:54:36 It's not just for community/. It is so that we can regularly contribute more often. A lot of these changes have been since September or even before. I whipped through the system set faster than Alpine could handle PRs and we didn't have a good flow of how to send PRs in so these changes piled up quickly. And now when we (Adelie) try to pull from Alpine there are hundreds(!) of merge conflicts. 2018-02-07 21:54:48 This effort is designed to replace all of that crappy workflow with a nice one where as we make changes, we just send simple PR to Alpine, instead of carrying it for so long 2018-02-07 23:41:25 damn, looks like I'm screwed a bit. after `apk upgrade` I got: http://ix.io/Fsc first thought was that mkinitfs's trigger should have better design, i.e. overwrite existing files only after successfully creating them. second thought is worse, though: I'm possibly experiencing some memory errors (notice jernel for instance) - it's my best guess right now. earlier I was wondering why gcc failed 2018-02-07 23:41:31 with -march something that wasn't even present in command-line... 2018-02-07 23:42:27 memory errors may possibly explain another "good" (/var/log/) message I found: http://ix.io/Fsd 2018-02-07 23:47:13 cpio: lib/modules/4.9.33/kernel/dviverscsi/s#sim/`.ko: No such file or directory 2018-02-07 23:47:41 This should be lib/modules/4.9.33/kernel/drivers/scsi/sim 2018-02-07 23:47:42 Something's definitely wonky 2018-02-07 23:52:51 uptime is only 107 days, and not sure of total uptime of this hardware, but it's less than 2 years for sure; most parts were bought in December 2014, some later, everything was fully assembled around 2015Q4 and I finally replaced old server in April 2016 (or later), so it's still quite young, too young to be failing on me. 2018-02-07 23:53:11 damn it 2018-02-07 23:53:28 Looks like maybe disk stuff 2018-02-07 23:55:20 but then standard gcc -c wouldn't fail with Fatal error: invalid -march= option: `CV' where last part can differ: `C' `CV' `Ck"V' `C[xV' etc. 2018-02-07 23:58:37 I definitely need reboot for fsck at least, but should do it on other hardware, yet I'm not sure my initramfs is even usable at this point 2018-02-08 00:04:21 it's late, don't have time to deal with it now, and have other problems queued tomorrow to deal with too. why it had to hit my home server/router in particular... hopefully there won't be any power outage until I'll have time to deal with this mess. 2018-02-08 00:04:30 sorry for the rant, I got OT here 2018-02-08 02:48:59 what's everyone's stance on apkbuilds which force a package to build with clang? 2018-02-08 02:49:33 I've run into a piece of software that doesn't play nice with gcc's gomp, but works fine with clang's openmp implementation 2018-02-08 02:57:42 heh xchat doesn't have a desktop menu icon 2018-02-08 03:23:38 Disable OpenMP. 2018-02-08 03:23:40 It's been giving issues on s390x as well 2018-02-08 18:01:40 what ever happened to the mkinitfs fork that was trying to be sort of `ng` of it? Where one could build a complete ramfs that would have embedded packages and files and such? 2018-02-08 18:16:44 oh it was TemptorSent's mkimage stuff that was abonded :( 2018-02-08 18:17:05 *abandoned 2018-02-08 20:28:14 it would be nice if abuild could scan for missing licenses before signing the package. 2018-02-08 20:28:42 and more quality control checks like missing .desktop files for gui apps 2018-02-08 20:30:15 and more q/a check if games are marked as group permission 2018-02-08 20:33:18 and also scan source code for potential suspicious payloads or privacy invasion 2018-02-08 20:35:34 it would also be nice if abuild could also make me a sandwich and clean my house 2018-02-08 20:35:44 heh 2018-02-08 20:37:55 (what you are looking for is a linter, and yes, somebody should write one) 2018-02-08 20:38:18 (but linting shouldn't be the responsibility of abuild itself, abuild should stick to building packages) 2018-02-08 20:38:43 it does do some checks but too minimalist 2018-02-08 20:39:43 yes, this is probably because linting should be the responsibility of some other tool 2018-02-08 21:50:37 21:33:18 koldbrutality : and also scan source code for potential suspicious payloads or privacy invasion lol no 2018-02-08 21:51:19 i remember i was working with a word pressplugin and it had obfuscated payload... 2018-02-08 21:54:02 i was packaging another software called ramme instagram client and it had use google analytics to do usage check... some might consider that invasion of privacy 2018-02-08 21:55:23 for the obfuscated payload i think it was base64 encoded and was used for advertising 2018-02-08 21:57:55 i'm pretty sure apple does code auditing before they put the product on their software store 2018-02-08 21:59:55 or some way to detect if it is not malicious 2018-02-08 23:26:17 the alpine package repos are not the app store 2018-02-08 23:39:58 The Apple App Store has a 37 page agreement that you have to sign before you can put your apps on there; app developers publish their apps on it directly; and Apple have a legal team that has more funding than most countries' governments. 2018-02-08 23:40:12 I agree that there should be a linter, but it should not be a code linter. 2018-02-09 01:39:17 ncopa: isn't it too late for you to be online ? btw, a commit to disable fftw s390x was merged, but the build-edge-s390x is hanged atm. Would you mind logging in and break the hang process, please ? 2018-02-09 01:40:54 tmh1999: a couple days ago, he wasn't in GMT+1 :) 2018-02-09 01:41:01 ncopa: thanks \o/ 2018-02-09 01:41:33 tmh1999: seems like it still hangs in long-double tests of fftw 2018-02-09 01:42:03 maybe we should disable tests til its figured out? 2018-02-09 01:42:27 ncopa: yeah it hang. I remember about IBM long-double conversation sometimes ago. I will readdress that. I disabled fftw in a recent commit. 2018-02-09 01:43:14 i think it will break things like alsa 2018-02-09 01:43:15 which depend on it 2018-02-09 01:43:30 yeah alsa-utils 2018-02-09 01:43:31 but ok, we need the builder complete and upload the packages 2018-02-09 01:43:44 just alsa-utils 2018-02-09 01:43:52 ok 2018-02-09 01:44:24 is it about strtold()? 2018-02-09 01:44:49 dunno 2018-02-09 01:47:29 only main/alsa-utils and 2-3 packages in community/ depends on fftw. without circle reverse-dependencies. which is fine. 2018-02-09 01:48:27 or rather, *told() 2018-02-09 01:49:39 iirc there's a wcstold() and a strtold() 2018-02-09 01:50:30 cpan.org is down. wow. 2018-02-09 01:50:43 tmh1999: it's up for me 2018-02-09 01:50:53 *search.cpan.org 2018-02-09 01:51:12 weird indeed 2018-02-09 01:51:19 tmh1999: still works for me :P 2018-02-09 01:51:43 maybe the s390x builder is also in ny 2018-02-09 01:51:55 says it's down on downforeveryoneorjustme.org 2018-02-09 02:54:14 I thought the builder was configured to continue despite having an error. 2018-02-09 04:37:37 don't rely on search.cpan.org, use other mirrors. 2018-02-09 04:37:49 heyyyyy tmh1999 2018-02-09 04:37:58 you wanna take a crash course through s390x assembly 2018-02-09 04:38:07 the perl community has no control over search.cpan.org so it'll go down without warning. 2018-02-09 04:38:12 http://github.com/kaniini/libucontext you should make this work on s390x 2018-02-09 04:38:20 could probably write a paper on it 2018-02-09 04:38:21 get published 2018-02-09 04:38:26 i think its a good idea man 2018-02-09 04:38:31 mostly because i don't wanna 2018-02-09 04:39:34 kaniini: I'll see what I can do 2018-02-09 04:39:40 interesting 2018-02-09 04:39:57 kind of surprised when you mention publication lol 2018-02-09 04:40:32 i am just bullshitting you, i don't think you can write a paper on "implementing context switching for the musl C library" 2018-02-09 04:40:34 (but if you can, go for it) 2018-02-09 04:40:39 seems like everyone mistaken me with the researcher on IBM Watson, hum ... 2018-02-09 04:40:50 yeah I can smell that though .. 2018-02-09 04:41:01 it'd at least get you updoots on hacker news and reddit 2018-02-09 04:41:03 but we do need it for s390x 2018-02-09 04:41:10 it's the only thing blocking me putting it in alpine 2018-02-09 04:41:20 (mips support would also be cool, but i think i can manage that one myself) 2018-02-09 04:41:52 kaniini: yep. I'll see but I cant guarantee. Maybe you should also send an email to musl list. Bobby Bingham is the guy ported musl to s390x 2018-02-09 04:42:07 i dont want to announce it there yet :D 2018-02-09 04:42:16 dalias is going to be like 2018-02-09 04:42:17 wow 2018-02-09 04:42:20 this is really ghetto kaniini 2018-02-09 04:42:41 you totally did not care about some specific POSIX nuance 2018-02-09 04:44:28 kaniini: I bet Bobby would finish this task like a blink of an eye. save you, save me 2018-02-09 04:44:55 not that I don't want to, just that if I do it, it's gonna take *a lot* of time 2018-02-09 04:45:14 time is expensive for you, I guess, in this case 2018-02-09 04:47:19 wow seems like you have almost every arch. 2018-02-09 04:48:11 this is interesting 2018-02-09 04:53:25 it's so hard to debug this now. if I run abuild and it says error it should tell me the line number but it doesn't have this feature. 2018-02-09 05:31:55 <_ikke_> koldbrutality: abuild is just a shell script where the APKBUILD is sourced 2018-02-09 05:32:07 <_ikke_> koldbrutality: abuild does not parse APKBUILDs or anything 2018-02-09 06:30:40 the parser is the shell :P 2018-02-09 06:41:32 morning guys 2018-02-09 06:49:55 good morning 2018-02-09 07:26:07 Good morning. h2o still is at 2.2.0 in edge/community whereas there was 2.4 security patched version has been released. It seems like cherokee webserver has been abandoned because https://wiki.alpinelinux.org/wiki/Cherokee does not work anymore, nor there is any packages available. 2018-02-09 07:28:03 cherokee seems pretty darn dead, and hmm, I'll check h2o 2018-02-09 07:30:00 haven't heard h2o mentioned in a long long time 2018-02-09 07:30:31 zenny: 2.2.4 is the latest version according to https://github.com/h2o/h2o/releases 2018-02-09 07:31:37 and see https://pkgs.alpinelinux.org/packages?name=h2o&branch=edge 2018-02-09 07:40:24 @danieli: my bad oversight. I was referring to 2.2.4 which fixes two vulnerablity (Version 2.2.4 has been released with two vulnerability fixes #1543 and #1544 from https://h2o.examp1e.net/index.html (at the bottom) 2018-02-09 07:42:25 @danieli: lo and behold, now it has been updated! 2018-02-09 07:42:28 :D 2018-02-09 07:42:41 What about cherokee webserver? 2018-02-09 07:42:54 it doesn't seem to be maintained upstream 2018-02-09 07:43:10 also, protip, don't prefix usernames with "@" on IRC - it means channel operator here :) 2018-02-09 07:44:04 zenny: looks like h2o was updated in December 2018-02-09 07:44:16 built 19th Dec. 2017 2018-02-09 07:45:38 danieli: apk search was pointeing to h2o-2.2.3-r3 before I asked and now it gives the correct version. 2018-02-09 07:46:06 reverseproxy:~# apk search h2o 2018-02-09 07:46:06 h2o-dev-2.2.3-r3 2018-02-09 07:46:06 h2o-2.2.3-r3 2018-02-09 07:46:06 h2o-doc-2.2.3-r3 2018-02-09 07:46:07 you didn't happen to run `apk update' before you did `apk search'? 2018-02-09 07:46:59 I did apk update && apk upgrade and then apk search by enabling all repos main/edge/testing/community 2018-02-09 07:47:27 strange. I was thinking it was caching or giving old results for some other reason 2018-02-09 07:47:32 2.2.4 was built in december anyway 2018-02-09 07:47:57 yep, cache could be the reason. 2018-02-09 10:26:58 anywone have been able to make wine work with alpine x86_64? 2018-02-09 10:28:21 there is a wine package, not sure if it works or not though 2018-02-09 10:28:39 ncopa might 2018-02-09 10:28:47 I'm referring to that package 2018-02-09 10:29:14 ah okay. well, in that case, I'm no help. I usually stay away from wine and use VMs instead 2018-02-09 10:30:39 yeah..but for simple exe it's an overkill.. 2018-02-09 10:30:55 usually, yeah. old habits die hard I guess 2018-02-09 10:35:37 that's due to wine64 does not run 32bit executable 2018-02-09 10:36:00 yeah, no WOW64 2018-02-09 10:36:25 most of the executables are still compiled 32bit 2018-02-09 10:36:26 uff 2018-02-09 10:36:30 oof 2018-02-09 12:24:30 So appears to me that qt5 5.10 upgrade is blocked by libressl > openssl 1.1 switch 2018-02-09 12:24:47 qt5 5.10 introduces openssl 1.1 2018-02-09 12:25:15 and openssl 1.1 is not compatible with libressl /o\ 2018-02-09 12:44:39 no, Qt 5.10 is blocked by not being an LTS release. 2018-02-09 12:50:57 Aerdan[m], no 2018-02-09 12:51:08 I'm talking about edge 2018-02-09 12:51:18 and we have 5.9.x 2018-02-09 12:51:37 but before we had 5.8 2018-02-09 12:51:43 which was not lts 2018-02-09 12:51:59 edge is edgy 2018-02-09 12:52:16 qt5.10 is blocked by ssl, sadly 2018-02-09 12:52:38 before we did not have a downstream packaging KDE. 2018-02-09 12:53:19 where do we have kde ? 2018-02-09 12:53:42 If olliparanoid is fine, we can upgrade qt 5.10 2018-02-09 12:53:57 is only matter of let them know and an agreement 2018-02-09 12:54:01 but this is /not/ a blocker 2018-02-09 12:54:12 we don't have kde on alpine yet 2018-02-09 12:54:26 adelie is not fine with non-LTS Qt, pmOS is, they'd like it 2018-02-09 12:54:26 it's not just pmOS, though. we also have Adelie, which provides a KDE desktop. 2018-02-09 12:55:44 more than that, Adelie is busy reducing the deleta between them and Alpine wrt aports, so as to make it easier for contributrs to one to be able to contribute to the other. 2018-02-09 12:55:51 delta* 2018-02-09 12:55:56 Sure 2018-02-09 12:56:25 still we have a problem now with qt5 2018-02-09 12:57:38 wireshark and gns3 are not working 2018-02-09 17:31:14 tmh1999: the list of packages that failed to build on s390x: http://tpaste.us/5Yk0 2018-02-09 17:31:15 i think we need to fix the kernel build to be able to have a working wireguard 2018-02-09 18:21:46 ncopa : how do you mean the kernel build ? 2018-02-09 18:21:56 oh 2018-02-09 18:22:18 yeah, kernel build ? 2018-02-09 18:25:16 i may been wrong about that 2018-02-09 18:25:16 yeah, linux-vanilla-4.14.17 is built 2018-02-09 18:26:16 yeah, also, some of these packages in community/ in above list are already disabled, btw. 2018-02-09 18:29:29 I wish the threads I opened on alpine-devel ML got even half this much attention haha 2018-02-09 18:29:53 get a troll in your threads 2018-02-09 18:29:57 you'll get the attention 2018-02-09 18:30:04 but be careful what you wish for 2018-02-09 18:30:24 tmh1999: im gonna clean it up 2018-02-09 19:15:21 2018-01-09 11:15:01 @fabled Fusl, default stack size assumption is one of the most common things we need to fix when porting to musl 2018-02-09 19:15:33 anyone available for a quick explanation how this should be implemented? 2018-02-09 19:16:01 one of my software packages (testing/motion) throws this every now and then: 2018-02-09 19:16:04 [500434.749159] motion[11585]: segfault at 790fecf85bb0 ip 0000790fecd52b6c sp 00007acf0f5927c0 error 6 in ld-musl-x86_64.so.1[790fecd02000+89000] 2018-02-09 19:16:05 [500434.749172] grsec: From 10.240.241.0: Segmentation fault occurred at 0000790fecf85bb0 in /usr/bin/motion[motion:11585] uid/euid:101/101 gid/egid:27/27, parent /bin/busybox[init:1] uid/euid:0/0 gid/egid:0/0 2018-02-09 19:16:07 [500434.749230] grsec: From 10.240.241.0: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /usr/bin/motion[motion:11585] uid/euid:101/101 gid/egid:27/27, parent /bin/busybox[init:1] uid/euid:0/0 gid/egid:0/0 2018-02-09 19:16:15 which i believe is due to the "default stack size assumption" 2018-02-09 19:32:57 Fusl: http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_attr_setstacksize.html 2018-02-09 19:33:24 basically, look for every occurrence of pthread_create() in the code, and patch it so pthread_create is always invoked with an attr argument 2018-02-09 19:33:53 and before calling pthread_create(), call pthread_attr_setstacksize() on the attr, to explicitly set the stack size you want 2018-02-09 19:34:21 so when the thread is created, it will use the stack size you gave, instead of the default 2018-02-09 19:41:55 skarnet: thank you very much! ill take a look into it and hopefully get it fixed 2018-02-09 19:42:34 `np :) 2018-02-09 19:43:56 if pthread_create() wasn't invoked with an attribute argument before, you'll need to pthread_attr_init() first, and pthread_attr_destroy() after 2018-02-09 19:44:38 it goes more or less like this: 2018-02-09 19:48:09 pthread_attr_t attr ; int e = pthread_attr_init(&attr) ; if (e) error-out ; e = pthread_attr_setstacksize(&attr, yourstacksize) ; if (e) error-out ; e = pthread_create(yourthread, &attr, yourfunction, yourarg) ; if (e) error-out ; pthread_attr_destroy(&attr) ; 2018-02-09 19:56:06 dang dataloss :'( 2018-02-09 19:56:40 i blame firefox 58.x for locking up the computer 2018-02-09 19:57:46 i was working on this APKBUILD since yesterday and now it is blank 2018-02-09 20:00:41 koldbrutality: ouch! :-( 2018-02-09 20:00:41 koldbrutality: some editors write .save or .swap/.swp files to restore unsaved changes from 2018-02-09 20:01:04 hmm is travis really building now? "No packages found to be built." https://travis-ci.org/alpinelinux/aports/builds/339603344?utm_source=github_status&utm_medium=notification 2018-02-09 20:02:36 this PR https://github.com/alpinelinux/aports/pull/3248 2018-02-09 20:02:42 fcolista: we tested Qt 5.10 in adelie and it's not ready to go 2018-02-09 20:02:56 there's a lot of bugs verses 5.9 2018-02-09 20:03:10 fcolista: if you are having a problem with GNS3, let me know and i will fix it to work with qt 5.9 2018-02-09 20:03:42 kaniini: hmm do you have the APKBUILDs anywhere? it this with LibreSSL replaced by OpenSSL? 2018-02-09 20:04:26 PureTryOut: yes, we already did the openssl transition in adelie a while ago 2018-02-09 20:06:03 ah ok 2018-02-09 20:09:21 oh looks like time_t in libressl is fixed 2018-02-09 20:10:00 https://github.com/libressl-portable/openbsd/commit/362ffef32c0fcae703d57838e9f5704240a63213 2018-02-09 20:16:09 it's not 2018-02-09 20:16:16 that fix is wrong 2018-02-09 20:16:30 all it does is say "oh, the date is past year 2038 it must be ok!" 2018-02-09 20:17:33 should buy us enough time til its fixed in kernel 2018-02-09 20:18:01 and the regressions verses 1.0.1g? 2018-02-09 20:18:19 will need to look closer at those 2018-02-09 20:18:47 i dont think we should rush it in any case 2018-02-09 20:19:59 lets fix the kernel first 2018-02-09 20:20:25 i have no objection to fixing the kernel first, but i feel like we are actually better off with openssl 1.1 2018-02-09 20:20:32 for many reasons 2018-02-09 20:20:40 might be 2018-02-09 20:20:59 my biggest worry was the time_t issue 2018-02-09 20:21:03 and their reaction to it 2018-02-09 20:21:22 my second worry is "what happens when there is a math error in the assembler code, can they fix it" 2018-02-09 20:21:59 does theo de raadt know how to solve montgomery squares 2018-02-09 20:22:01 we had an issue already with nginx where libressl broke stuff 2018-02-09 20:22:17 so i do think that is a good point 2018-02-09 20:22:47 openssl have actual cryptographers working on it, libressl does not as far as i know 2018-02-09 20:23:27 it is not like one is really truly any better than the other, the security problems of openssl usually come from the fact that you're shooting yourself in the foot 2018-02-09 20:23:57 i understand that none are good really 2018-02-09 20:24:44 i also think its not good to switch every year, go back and forth 2018-02-09 20:25:04 openssl will likely save us for a lot work 2018-02-09 20:25:07 i agree with that 2018-02-09 20:26:00 i just don't think libressl is the way to go, especially with more archs being added to alpine (mips port for example) 2018-02-09 20:26:09 have openbsd even tested their changes on those archs 2018-02-09 20:26:15 (admittedly have openssl?) 2018-02-09 20:26:37 at least libressl works for now 2018-02-09 20:26:44 with time_t issue it wasnt even working.. 2018-02-09 20:26:47 last year, i would agree that libressl is way to go. but openssl situation has gotten a lot better since then. 2018-02-09 20:27:20 let us think about it 2018-02-09 20:27:37 I, for one, support the move back to openssl 2018-02-09 20:28:02 libressl has solely been the biggest pain in my ass out of all of the things in alpine 2018-02-09 20:28:18 i'd like fabled have a look at openssl state 2018-02-09 20:28:24 which is interesting considering we use a "non-standard" libc 2018-02-09 20:28:35 heh 2018-02-09 20:28:35 you'd think that'd be more likely to have issues :P 2018-02-09 20:28:39 lol 2018-02-09 20:28:54 thats pretty interesting 2018-02-09 20:29:37 anyways, I feel like musl is proof that you can make better things without breaking API compatibility 2018-02-09 20:29:45 I know the story for openssl is different 2018-02-09 20:29:51 because the API is part of the problem 2018-02-09 20:29:57 ncopa: i mean, lets be honest here too. the libressl transition was half done anyway 2018-02-09 20:30:12 mpeholic: *nod* 2018-02-09 20:30:16 the VPN software is still basically on openssl because of ENGINE 2018-02-09 20:31:05 i didnt think ENGINE was a big problem anymore 2018-02-09 20:31:08 but i may be wrong 2018-02-09 20:31:10 that's another huge bummer to me, is lack of ENGINE in libressl 2018-02-09 20:31:18 as I use alpine on lots of routers 2018-02-09 20:31:32 ncopa: it's a big problem if you are running a VPN concentrator 2018-02-09 20:31:47 doesnt libressl support AES-NI? 2018-02-09 20:32:00 it's "not a big problem" because the openssl package was dropped 2018-02-09 20:32:02 er wasn't 2018-02-09 20:32:03 intel 2018-02-09 20:32:04 ok 2018-02-09 20:33:09 yes, libressl support AES-NI 2018-02-09 20:33:13 but ENGINE is about the geode 2018-02-09 20:33:13 and crypto accelerator cards 2018-02-09 20:33:21 that too yes 2018-02-09 20:33:21 via padlock 2018-02-09 20:33:59 right 2018-02-09 20:34:05 and people like their pcengines boxes 2018-02-09 20:34:09 not so commone hw as i understand 2018-02-09 20:34:10 <- 2018-02-09 20:34:14 my point is, in practice there's a lot of installs with both openssl and libressl installed anyway 2018-02-09 20:34:29 nodejs is other problem 2018-02-09 20:34:33 ncopa: https://www.pcengines.ch/apu.htm 2018-02-09 20:34:33 not ported to libressl 2018-02-09 20:35:02 i chose to buy an apu2 2018-02-09 20:35:08 and spend more money than I needed to 2018-02-09 20:35:14 SPECIFICALLY because of libressl 2018-02-09 20:35:15 i use apu2 at home 2018-02-09 20:35:26 same 2018-02-09 20:36:04 "LibreSSL is API compatible with OpenSSL 1.0.1, but does not yet include all new APIs from OpenSSL 1.0.2 and later. LibreSSL also includes APIs not yet present in OpenSSL. The current common API subset is OpenSSL 1.0.1." 2018-02-09 20:36:05 This is direct from their README 2018-02-09 20:36:08 And it's a lie 2018-02-09 20:36:19 I still don't know why we want something that lies in our base distribution 2018-02-09 20:36:28 that lie is essentially why we don't use libressl in adelie 2018-02-09 20:36:28 Like, LibreSSL is required to use Alpine; apk-tools uses it 2018-02-09 20:36:50 ncopa: I find it sort of silly that libressl is 'preventing' me from using lower end systems 2018-02-09 20:37:17 for things they'd be perfectly suited for if the software supported the hardware 2018-02-09 20:37:29 understand 2018-02-09 20:37:29 awilfox: yes/no. we only need libcrypto for apk-tools really, and we could use cryptlib for that :) 2018-02-09 20:37:57 mepholic: well can you write to the list and express your view :) 2018-02-09 20:38:02 or even bearssl XD 2018-02-09 20:38:10 that was the whole point of the thread 2018-02-09 20:38:19 that means I have to sign up for the list! 2018-02-09 20:38:19 the "i can do it next week" is just because i literally have that capability: we have the patches right now 2018-02-09 20:38:26 my sieve filters are busted right now :( 2018-02-09 20:38:27 The other thing is LibreSSL will never use optimised routines on POWER architecture, because their ppccpuid.c - even in portable - checks an OpenBSD sysctl path for altivec support. It of course never succeeds on Linux. 2018-02-09 20:39:18 all in all, I think that libressl is having negative impacts on the portability and embeddability of alpine 2018-02-09 20:39:43 especially to some of the systems that would be most suited to use alpine on 2018-02-09 20:39:53 embeddability is not an argument 2018-02-09 20:40:10 if you wanna do embedded, you don't use LibreSSL, but you don't use OpenSSL either... ideally 2018-02-09 20:40:21 i agree with skarnet. if we're talking embedded, we're talking mbedTLS or bearssl or something 2018-02-09 20:40:22 well yeah sure 2018-02-09 20:40:43 mepholic: i get your point 2018-02-09 20:40:58 if you have a lowend hw or old hw, what distro do you want to run? 2018-02-09 20:41:02 but even still, it makes it difficult to use alpine for 'general purpose usage on alternative architectures' as in AWilcox[m]'s case 2018-02-09 20:41:04 Except you have to use LibreSSL because Alpine apk-tools depends on it. Unless you don't allow your embedded device to update itself, which I guess works fine for most IoT vendors. 2018-02-09 20:41:07 awilfox: well the other concern is that a lot of the asm routines have been rotting in libressl 2018-02-09 20:41:13 ncopa: alpine 2018-02-09 20:41:19 all day every day 2018-02-09 20:41:39 it's proven to be less thrashy and wasty with resources than pretty much any other 2018 distro 2018-02-09 20:41:45 :) 2018-02-09 20:41:46 so it makes sense alpine run on those devices 2018-02-09 20:42:19 AWilcox[m]: time to rewrite apk-tools with bearssl then :) I volunteer to do it some time this year. 2018-02-09 20:42:41 it should be noted that adelie was a huge proponent of libressl at the beginning too 2018-02-09 20:42:43 it got ripped out because we got tired of being burned 2018-02-09 20:42:44 Also to kaniini's question about MIPS: I don't know what testing OpenBSD does, but I know OpenSSL is used as the only SSL lib in OpenWRT and LEDE, which is running on a great number of MIPS boxes 2018-02-09 20:43:20 For all I know they do regression tests on MIPS. They seem to be good about that. But I don't know. I certainly would doubt they test on Linux/mips. 2018-02-09 20:43:47 i'm glad they finally "fixed" time_t, but when we discussed it with them, they told us to just not use libressl on those systems 2018-02-09 20:43:55 i mean, there's a *lot* of reasons we gave up on libressl 2018-02-09 20:44:11 I think the important thing is that we tried 2018-02-09 20:44:34 nobody is happy with the state of openssl 2018-02-09 20:44:40 but some shit you just gotta live with 2018-02-09 20:45:02 there comes a point when productivity is more important than idealism 2018-02-09 20:45:03 (this was a private discussion because obviously "libressl does not validate certificate chains with roots expiring >2038 on 32-bit time_t" is a major security problem) 2018-02-09 20:45:26 If you look at the list I showed in the first email I sent in this thread, you'll note the number of patches that we(Alpine) *would not* have to maintain any more if there was a switch back to OpenSSL as well 2018-02-09 20:45:57 i mean, i'm okay with patching to make it work 2018-02-09 20:46:00 *if* libressl is worth it 2018-02-09 20:46:00 That's another big problem I feel. Alpine should be focusing on innovating and porting to stuff like MIPS so it can be used there for routers and such. Not focusing on keeping a bunch of patches maintained 2018-02-09 20:46:22 ok. maybe we will switch back to openssl. but not today. 2018-02-09 20:46:31 i will re-read the emails from awilfox a bit closer 2018-02-09 20:46:32 but being told to simply not use libressl because we reported that time_t bug was really a turnoff 2018-02-09 20:46:56 kaniini: That's the best part, we didn't report it, they knew about it since portable 2.3 was released. 2018-02-09 20:47:17 kaniini: I don't know why they chose to fix it *now* in 2.6.4. Maybe there was big client that wanted it. 2018-02-09 20:47:17 and they fixed it silently 2018-02-09 20:47:31 i need to go 2018-02-09 20:51:48 see you 2018-02-09 20:51:58 lets continue libressl vs opensls on mailing list 2018-02-09 21:05:42 does anyone know if Mika Havela (https://bugs.alpinelinux.org/users/4) is active on irc? 2018-02-09 21:17:08 skarnet: thanks again for your help, here's the result, nothing spectacular: https://github.com/alpinelinux/aports/compare/master...Fusl:testing_motion_4.1.1_1 2018-02-09 21:17:39 i built a new pkg for myself, deployed it and let's see if it keeps running for longer than just a few days 2018-02-09 21:18:30 Fusl: 8 MB is the glibc default, but it's probably too big for most packages 2018-02-09 21:18:41 depending on what the software does, try with 1 MB 2018-02-09 21:19:12 skarnet: i'm sure 1 MB will suffice as well but i wanted to be sure that what i'm trying to track down here is really caused by the stacksize being too low 2018-02-09 21:19:20 good point 2018-02-09 21:19:23 sadly i have no way of triggering the segfault whenever i want 2018-02-09 21:19:35 anyway your patch looks good, except the original software doesn't test return codes 2018-02-09 21:19:57 I understand you wanted to mimic the style, but please at least test the return codes for the lines you're adding 2018-02-09 21:20:17 some checks are better than none at all ;) 2018-02-09 21:20:52 will add that to my list of cleanup steps once the actual issue is fixed 2018-02-09 21:21:00 sounds good. 2018-02-09 21:58:57 _ikke_ : May I enable armhf, aarch64 for testing/fzf ? Looks like they are supported : https://github.com/junegunn/fzf/blob/b49f22cdf9f2ca021382ddeb026c739a22120781/Makefile#L26 2018-02-09 22:01:04 <_ikke_> tmh1999: sure, feel free 2018-02-09 22:01:20 _ikke_ : Thanks. Just want to check it first since I don't have/know these archs. 2018-02-09 22:02:08 <_ikke_> me neither 2018-02-09 22:02:15 <_ikke_> That must have been added recent 2018-02-09 22:02:32 <_ikke_> because fzf has just been recently merged, and then it wasn't supported yet 2018-02-09 22:05:09 <_ikke_> are you sure they are supported? 2018-02-09 22:05:43 <_ikke_> kaniini: explicitly disabled them because they were not supported yet by the makefile, and I don't see anything has changed 2018-02-09 22:09:59 hey ncopa I just submitted https://github.com/alpinelinux/aports/pull/3252 that reenables Netronome nfp nic driver that was silently dropped, mind to take a look? 2018-02-09 22:11:08 _ikke_ I am not very sure about arm*, my guess is kaniini disabled them because at that time frame, go wasn't available on those arch. 2018-02-09 22:11:23 if any 2018-02-09 22:12:25 oh not true. zzz 2018-02-09 22:12:32 it's just Jan 2018 2018-02-09 22:12:40 mistaken with the other patch 2018-02-09 22:12:56 alright for safe, I won't enable arm*. just let arm people decide it 2018-02-10 00:55:43 What's the process for moving a package from testing/ to community/ 2018-02-10 00:56:16 I've used my kexec package quite extensively and have not identified any problems, so I think it would be appropriate to move it from testing/ to community/. 2018-02-10 00:56:36 (I have no idea if anyone else uses it. I hope they do.) 2018-02-10 00:56:58 Is there a reason that main/lame has textrel detection code in package()? I think abuild does this itself for a long time now 2018-02-10 01:54:17 clandmeter: what was that linux-4.9.7-rpi-XXXXXX.patch file we needed? 2018-02-10 01:54:27 s/4.9.7/4.9.y/ 2018-02-10 02:10:30 awilfox: no, it can be removed 2018-02-10 02:31:32 audit-dev install header libaudit.h in /include. jesus. 2018-02-10 02:31:36 is that right ? 2018-02-10 02:42:51 no 2018-02-10 02:42:54 definitely not 2018-02-10 02:46:54 kaniini: https://github.com/alpinelinux/aports/blob/master/main/audit/APKBUILD#L33 2018-02-10 02:47:01 it should be prefix=/usr, isn't it ? 2018-02-10 02:47:46 I am compiling testing/libsemanage and it complains about missing libaudit.h, turns out it is inclued in /include. 2018-02-10 02:48:10 I will create a pr 2018-02-10 03:05:31 this is funny lol : https://git.alpinelinux.org/cgit/aports/tree/testing/emscripten/APKBUILD#n4 2018-02-10 03:06:09 tmh1999: hahhaha, I've seen worse :P 2018-02-10 03:06:17 :D 2018-02-10 03:06:37 tmh1999: note that audit will then have libraries in /usr/lib instead of /lib so -static will need to be fixed 2018-02-10 03:07:21 AWilcox[m] : yes I also did that : https://github.com/alpinelinux/aports/pull/3256 2018-02-10 03:07:45 danieli : do you have aports write permission and a minute ? 2018-02-10 03:07:48 :D 2018-02-10 03:07:52 tmh1999: I don't have access, no 2018-02-10 03:07:59 okay 2018-02-10 03:08:06 I have access to uk.alpinelinux.org and a very small number of other hosts 2018-02-10 03:08:19 gotcha 2018-02-10 03:10:09 tmh1999: hi 2018-02-10 03:10:12 what do you need 2018-02-10 03:10:49 kaniini: hi, not really urgent, I just made some pr. some will come soon. 2018-02-10 09:17:56 danieli: that's the patch comping from rpi kernel. You need to generate it against the current vanilla. 2018-02-10 09:37:59 clandmeter: didn't we lose it 2018-02-10 09:37:59 ? 2018-02-10 09:42:31 Loose it? 2018-02-10 09:42:35 Idk 2018-02-10 09:44:06 i remember everyone scrambling to find it last year 2018-02-10 09:49:00 It's still an issue? 2018-02-10 09:49:08 I don't know, I'm asking, because I found it 2018-02-10 11:29:34 kaniini, thx for the gns3 thinghy. And yes, there's an issue on gns3 due to pyqt5 compiled against qt 5.9.3 2018-02-10 11:29:35 2ua4020qdl:/mnt/dati$ gns3 2018-02-10 11:29:35 Fail update installation: Error relocating /usr/lib/python3.6/site-packages/PyQt5/QtCore.so: _ZN23QOperatingSystemVersion11AndroidOreoE: symbol not found 2018-02-10 11:30:04 if/hwn you can take a look (and explain what you have done. hwo and why :) I'll be grateful 2018-02-10 11:30:05 thx 2018-02-10 11:30:12 *if/when 2018-02-10 14:59:20 fcolista: the problem is pyqt5 needs to be rebuilt 2018-02-10 15:13:17 ncopa: roundcube mail in alpine v3.7 does not work due to missing .js files in the packaging. 2018-02-10 15:14:03 the version in v3.6 works fine. This is due to a change introduced by upstream in >= 1.3 2018-02-10 15:17:35 I have opened a PR this fix it https://github.com/alpinelinux/aports/pull/3263 2018-02-10 15:17:55 s/this/to/ 2018-02-10 16:31:54 ncopa, jirutka : aw I sent a couple of patches regarding s390x last night ... 2018-02-10 16:32:07 now it conflicts with your recent pushes 2018-02-10 16:32:33 wished you 2018-02-10 17:06:18 never mind, I updated it, not a big deal though ... 2018-02-10 20:55:39 I feel like license="custom" doesn't properly cover main/unrar 2018-02-10 20:55:45 I feel like license="non-free" would be better 2018-02-11 10:26:32 kaniini, is not a pyqt5 issue 2018-02-11 10:26:49 This was not working with the previous version 2018-02-11 10:27:06 so I upgraded it to the newer pyqt5 2018-02-11 10:27:09 and got the same issue 2018-02-11 10:27:23 if i bump pkgrel for pyqt5 i'll get the same error 2018-02-11 10:48:40 maybe underlinking 2018-02-11 20:37:08 hello, I have a question about the linux-virt package. is there a reason why it depends on linux-firmware-*? 2018-02-11 20:39:21 sorry wrong channnel, I think 2018-02-11 23:28:46 hmm 2018-02-11 23:29:28 bjmg: AFAIK so does -virthardened 2018-02-11 23:30:05 Hi, can a package in edge/main depend on edge/testing? I've found the wiki/Aports_what_is_edge page, but it's quite sparse, so I still don't understand exactly how the testing repo works. Thanks! 2018-02-11 23:30:23 no, it can't 2018-02-11 23:30:38 So only packages in testing can, correct? 2018-02-11 23:30:38 edge/main must only depend on edge/main 2018-02-11 23:30:45 yes 2018-02-11 23:30:55 And main cannot depend on community 2018-02-11 23:31:00 yes 2018-02-11 23:31:05 Got it. Thanks! 2018-02-11 23:31:12 but community may depend on main 2018-02-11 23:31:16 and testing may depend on both main and community 2018-02-11 23:31:23 10-4 2018-02-11 23:32:17 So is testing a pathway to main? 2018-02-11 23:32:45 testing is work-in-progress packages that do not ship with the distribution (they only live in edge) 2018-02-11 23:33:01 So community packages also have to move through testing, in that case? 2018-02-11 23:33:18 yes 2018-02-11 23:33:28 What discerns whether a package ends up in main or community? 2018-02-11 23:34:07 Sorry for all the questions, lol 2018-02-11 23:34:13 most things should go into community, but not everything has been moved from main yet 2018-02-11 23:38:17 I ask because I created a PR with bundled mongodb support for main/syslog-ng and someone asked that I link to mongo-c-driver instead. I had testing enabled in my dev environment so I changed it, tested the build, and pushed without realizing mongo-c-driver was in testing. Now I'm thinking I should revert as the dependency may not even end up in main if it even makes it out of testing. Should I just close my PR and reopen with the 2018-02-11 23:38:17 older commit? 2018-02-11 23:40:29 no 2018-02-11 23:40:40 mongo-c-driver should move to main 2018-02-11 23:42:56 Ok ty 2018-02-12 09:17:26 Hi, I just create #8481 in case you need more info about it just ask. 2018-02-12 10:24:02 problem with qt5 and gns3 is due to icu-libs 2018-02-12 10:25:45 apk version icu-libs 2018-02-12 10:25:45 Installed: Available: 2018-02-12 10:25:45 icu-libs-58.2-r2 < 59.1-r1 2018-02-12 10:25:55 apk fix icu-libs 2018-02-12 10:25:56 (1/1) [APK unavailable, skipped] Reinstalling icu-libs (58.2-r2) 2018-02-12 10:25:56 OK: 5579 MiB in 1466 packages 2018-02-12 10:26:41 problem : libQt5Core is part of qt5-qtbase-dev 2018-02-12 10:27:03 this is the version that i have: 2018-02-12 10:27:04 apk version qt5-qtbase 2018-02-12 10:27:04 Installed: Available: 2018-02-12 10:27:04 qt5-qtbase-5.9.1-r0 < 5.9.3-r0 2018-02-12 10:27:27 and this is the error 2018-02-12 10:27:27 apk add qt5-qtbase-dev 2018-02-12 10:27:27 ERROR: unsatisfiable constraints: 2018-02-12 10:27:27 icu-libs-59.1-r1: 2018-02-12 10:27:27 conflicts: icu-libs-58.2-r2 2018-02-12 10:27:28 satisfies: world[icu-libs] qt5-qtbase-5.9.3-r0[so:libicui18n.so.59] qt5-qtbase-5.9.3-r0[so:libicuuc.so.59] 2018-02-12 10:27:31 icu-libs-58.2-r2: 2018-02-12 10:27:33 conflicts: icu-libs-59.1-r1 2018-02-12 10:27:35 satisfies: world[icu-libs] firefox-54.0.1-r1[ 2018-02-12 10:27:37 wondering if I'm the only having this issue 2018-02-12 10:27:53 my repository: 2018-02-12 10:27:53 cat /etc/apk/repositories 2018-02-12 10:27:53 http://dl-cdn.alpinelinux.org/alpine/edge/main 2018-02-12 10:27:53 http://dl-cdn.alpinelinux.org/alpine/edge/community 2018-02-12 10:27:53 http://dl-cdn.alpinelinux.org/alpine/edge/testing 2018-02-12 10:28:10 trying to build icu-libs and force install 2018-02-12 11:11:33 gns3 and wireshark are back to work 2018-02-12 11:13:46 ollieparanoid[m], AWilcox[m] : re qt5 2018-02-12 11:14:15 https://pkgs.alpinelinux.org/contents?file=libQt5Core.so&path=&name=&branch=edge 2018-02-12 11:14:23 I think that this should go to a subpkg 2018-02-12 11:14:40 like qt5-core 2018-02-12 11:32:50 https://dpaste.de/e562/raw 2018-02-12 11:33:03 AWilcox[m], ollieparanoid[m] ^^^ 2018-02-12 11:33:28 sorry, wrong patch/paste 2018-02-12 11:34:49 this: 2018-02-12 11:34:50 https://dpaste.de/6Gq1/raw 2018-02-12 12:29:52 or perhaps move these .so from -dev to main pkg 2018-02-12 13:55:24 fcolista: no 2018-02-12 13:55:37 fcolista: libQt5Core.so itself must stay in -dev package 2018-02-12 13:56:10 fcolista: real problem is that firefox-54 needs to be rebuild against icu-libs 59 2018-02-12 13:56:46 at any rate that explains why i cannot reproduce it 2018-02-12 13:56:53 and i believe firefox is at 57 now 2018-02-12 13:57:39 58 even 2018-02-12 14:57:42 kaniini: if you have a minute, would you mind checking those s390x pr I've made. red color in #alpine-commits is annoying. https://github.com/alpinelinux/aports/pulls/tmh1999 2018-02-12 15:01:46 something something a e s t h e t i c 2018-02-12 15:04:24 I'd love some eyeballs on https://github.com/alpinelinux/aports/pull/3252 that re-enables the netronome NFP nic driver that used to be built a few kernels ago. 2018-02-12 15:13:23 it doesn't, it just adds it to config 2018-02-12 15:13:28 kernel need to be rebuilt to do that (pkgrel and checksums need to be updated in config) 2018-02-12 15:13:31 er in APKBUILD 2018-02-12 17:34:52 AWilcox[m]: https://core.suckless.org/ - most stuff Cag mentioned is from suckless crew, from their core collection to be more specific 2018-02-12 17:37:54 anyone get this too https://pastebin.com/aWhrU1Dr This is for main/libuv. I need to patch it for electron. 2018-02-12 17:39:07 it doesn't show which test failed 2018-02-12 17:41:01 I can run the test alone (./test/.libs/run-tests and ./test/run-tests) but with the make check it fails 2018-02-12 17:44:13 this is with vanilla kernel also 2018-02-12 17:48:36 the error was above https://pastebin.com/Vy6jqqm5 2018-02-12 17:54:30 koldbrutality: what's your setup? on x86_64 in alpine edge I got no errors. 2018-02-12 17:55:04 i use the same x86_64 2018-02-12 17:56:16 and edge 2018-02-12 18:00:03 well, libuv 1.19.1 is already packaged and available, and doesn't have !check in options, so it has to build w/o problems. 2018-02-12 18:00:28 "I need to patch it for electron" - does it mean you already modified it sources locally? 2018-02-12 18:04:00 i recompiled it without the patch and it does the same thing. I need to add https://github.com/electron/node/commit/693b35014efe6416d52e3ae0c1bcfa173670e45b to libuv. 2018-02-12 18:04:47 or i could just build libvu with it's own internal libuv 2018-02-12 18:05:26 but the nodejs package compiles libuv as separate 2018-02-12 18:10:13 fcolista (@fcolista:alpinelinux.org): I don't see the point of splitting Qt5Core into its own packages, as that's what qt5-qtbase *is* (in fact, I've oft wondered why it isn't called qt5-qtcore) 2018-02-12 18:10:34 What does qt5-qtbase have if Qt5Core is removed from it? A bunch of .sos that *require* Qt5Core? I just don't see what that gets us 2018-02-12 18:10:45 Thanks przemoc 2018-02-12 18:13:08 koldbrutality: hard to tell why tests fail in your setup. are you fully on edge or having mixed env? cat /etc/alpine-release /etc/apk/repositories | ix 2018-02-12 18:13:46 I am on full edge 2018-02-12 18:15:55 i think... http://ix.io/GtV 2018-02-12 18:16:44 it could be a router problem. upstream suggested that. 2018-02-12 18:16:58 i am trying a patch that might fix it 2018-02-12 20:17:39 I just disabled some tests to get it to work, but won't make a pull request for the work around. it also bugs out when there is no connection. 2018-02-12 20:17:50 or if I disconnect from the network 2018-02-12 20:19:06 failed on linking electron: undefined reference to symbol 'drmIoctl' 2018-02-12 20:24:09 Underlinked to libdrm. 2018-02-12 21:07:09 algitbot: ^ 2018-02-12 21:08:22 algitbot: I patched tcsh with the simple patch from Lede/openWrt and it works without visible problem 2018-02-12 21:12:30 algitbot is possibly not smart enough yet to propagate this info back to the redmine ticket ;) 2018-02-12 21:13:14 przemoc: hehe, ok. I see :) 2018-02-12 21:14:29 przemoc: BTW, do I need to post patch to bug report 2018-02-12 21:16:25 if it's available out there, as you already wrote, provide info where it can be found. 2018-02-12 21:17:25 it would be even better if you'd send a patch adding this patch and fixing APKBUILD to use it to alpine-aports ML 2018-02-12 21:17:26 huh, I copied it from Lede git repository on local disk 2018-02-12 21:18:29 I don't have much experience with aports, yet 2018-02-12 21:20:47 ok, no pressure, providing info in the ticket will already greatly help to pick it up by someone with aports experience 2018-02-12 21:22:36 I would help by guiding you in creating such patch, but have some other stuff still piled up, so not today 2018-02-12 21:23:42 przemoc: It would be nice from you to help me to learn about abuild i aport, and I'm not in hurry, also 2018-02-12 21:27:03 przemoc: for now, can you tell me is it possible to answer issue at https://bugs.alpinelinux.org/issues/8483 2018-02-12 21:28:12 yes, you have to register account (if you haven't already) and login to be able to comment there 2018-02-12 21:28:57 https://bugs.alpinelinux.org/account/register 2018-02-12 21:29:49 Tnx, I see. 2018-02-12 21:33:05 przemoc: I'm waiting registration mail. tnx again 2018-02-12 21:33:54 you're welcome. sorry I cannot be of greater help today. 2018-02-12 21:34:08 I suspect https://github.com/openwrt/packages/blob/master/utils/tcsh/patches/001-sysmalloc.patch is the patch you were talking about 2018-02-13 10:37:22 git.alpinelinux.org seem down 2018-02-13 10:37:40 and dev.alpinelinux.org 2018-02-13 10:55:38 fcolista: the .so are only used for linking. what exact problem are you seeing? 2018-02-13 10:55:59 kaniini, should .so be in -dev? 2018-02-13 10:56:07 Or should be in the main pkg? 2018-02-13 10:57:26 the .so should be in -dev, it's a symlink that's only used at build time for the build-time linker 2018-02-13 10:57:36 the .so.x.y should be in the main package, it's the real shared lib 2018-02-13 10:57:44 and used at run time 2018-02-13 10:59:09 skarnet, thanks for the clarification. This explain. 2018-02-13 10:59:24 I thought that in -dev would be only the .h pkgs 2018-02-13 11:00:30 the .h, the .a, and the .so symlink 2018-02-13 15:31:02 kaniini: oh, I didn't have latest apk-tools checkouted, so didn't know that list is already pushed in (I think I saw some of your pastes with drafts in the past). I presume you'll be further extending the list applet. 2018-02-13 15:47:44 przemoc: yes, it is part of the "apk 3" redesign that we're doing 2018-02-13 15:54:16 is there any rough estimate about fulfilling most of apk 3 requirements? is there any kind of roadmap available? it's possibly not 3.8 material, rather 3.9 or later, right? AFAIR apk's db was meant to be changed to binary format. AL4 seems like a nice release for such bigger changes, and I guess this apk 3 could actually become apk 4 in the end to nicely match it. :) 2018-02-13 15:54:57 apk 3 will happen when legacy support is dropped 2018-02-13 15:55:06 i don't know if binary database will actually happen 2018-02-13 15:55:14 there are advantages/disadvantages, but it's also challenging 2018-02-13 16:40:17 #define legacy support? 2018-02-13 16:41:27 whatever we choose to deprecate 2018-02-13 16:44:38 why make your own database format in general? 2018-02-13 16:45:06 who said anything about that 2018-02-13 16:45:16 the filesystem is a perfectly good database :P 2018-02-13 16:45:58 (a key-value store, more precisely. It becomes less practical the more relations you want between records.) 2018-02-13 18:20:25 Is there any interest in an autoconf-git package, given that a release 2.70 still seems out of sight after 6 years? Some packages require configure support for --runstatedir to autoreconf, which isn't available in 2.69 2018-02-13 18:22:29 ag: i would prefer not 2018-02-13 18:22:43 maybe ask upstream how the 2.70 release is going? 2018-02-13 18:22:50 we could ask upstream to do a _pre release too 2018-02-13 18:25:34 @ncopa: have you seen https://github.com/alpinelinux/aports/pull/3263? upgrade from alpine v3.6 -> v3.7 does not work for roundcube 2018-02-13 18:27:03 due to the missing .js files 2018-02-13 18:27:47 <_ikke_> HRio: Is that because 3.7 has a newer version of roundcube? 2018-02-13 18:27:58 yes 2018-02-13 18:28:05 1.3.x does not ship js files 2018-02-13 18:28:54 <_ikke_> hmm, php7 ... *.sh? 2018-02-13 18:29:10 yes :-) 2018-02-13 18:29:14 <_ikke_> lol 2018-02-13 18:31:42 its a bit strange that our php7 packaging forces adding include_path to work for "php scripts" 2018-02-13 18:32:49 <_ikke_> why's that 2018-02-13 18:32:50 <_ikke_> ? 2018-02-13 18:32:51 I have to do the same in /etc/php7/php.ini for the web application to work 2018-02-13 18:33:34 possibly it looks for libs in /usr/share/php but we have the libs in /usr/share/php7 2018-02-13 18:34:39 <_ikke_> So not properly 'namespaced' 2018-02-13 18:35:08 perhaps, I guess jirutka would know for sure 2018-02-13 18:35:51 <_ikke_> It is set for /usr/lib/php7, still looking for /usr/share/php* 2018-02-13 18:36:40 <_ikke_> --datadir and --with-pear are set for /usr/share/$pkgname, so that should be right 2018-02-13 18:36:59 <_ikke_> which version do you have? 2018-02-13 18:37:02 <_ikke_> of the package 2018-02-13 18:38:51 in edge 7.1.14-r0 (where I prepared the PR) 2018-02-13 18:39:07 <_ikke_> right 2018-02-13 18:39:37 7.1.14-r0 in v3.7 as well it seems 2018-02-13 18:40:07 <_ikke_> php7 -i does show '--datadir=/usr/share/php7' 2018-02-13 18:42:16 yes '--datadir=/usr/share/php7' 2018-02-13 18:42:39 <_ikke_> I think this is your issue: "include_path => .: => .: 2018-02-13 18:42:50 <_ikke_> It only looks in the current dir by default 2018-02-13 18:49:02 Hi, am I allowed to ask a question about a package I miss (it is a backup software called burp - burp.grke.org)? I think I am able to package it myself. But I did not do this before (at least for alpine). 2018-02-13 18:49:33 <_ikke_> sure, feel free to ask questions 2018-02-13 18:51:15 Ok, question is quite simple I think: I am able to build for my own architecture (x86_64) already. But I would like to make the package ready for "all" architectures. 2018-02-13 18:51:26 <_ikke_> HRio: I'm not getting the feeling that /usr/share/php* is included by default 2018-02-13 18:52:14 <_ikke_> HRio: on archlinux, it's only /usr/share/pear 2018-02-13 18:52:34 Therefore I set the "--build=$CBUILD" parameter of configure but the output now is "Invalid configuration `x86_64-alpine-linux-musl': machine `x86_64-alpine-linux' not recognized". What can I do there? 2018-02-13 18:53:26 <_ikke_> BernhardG: each package is built on native hardware 2018-02-13 18:55:05 Ok, fine. So no cross compiling? But still even my build on x86_64 does not work if I set the build parameter. But that is not a problem as I don't need it for a direct architecture build. 2018-02-13 18:55:18 _ikke_: thank you for solving the knot in my head. 2018-02-13 18:55:28 <_ikke_> right, there is no cross-compiling 2018-02-13 18:56:24 _ikke_: OK, so its needed then, the way I do it at build time. 2018-02-13 18:57:42 _ikke_: is there an existing variable that just outputs "x86_64" instead of "x86_64-alpine-linux"? I think it would be good to have that specified. 2018-02-13 18:57:55 <_ikke_> HRio: does roundcube put stuff in /usr/share/php7? 2018-02-13 18:58:29 /usr/share/webapps/roundcube/ 2018-02-13 18:59:05 <_ikke_> why do you need to add /usr/share/php7 to the include_path? 2018-02-13 18:59:06 but the php script needs php-pear, and so does the webapp 2018-02-13 19:00:07 <_ikke_> BernhardG: CARCH possibly 2018-02-13 19:01:22 anyone available to help debug why `motion` crashes although i have a binary running that has the following patches applied? https://github.com/alpinelinux/aports/compare/master...Fusl:testing_motion_4.1.1_1 2018-02-13 19:01:42 _ikke_: thanks. that works. Unfortunately those variables were not explained in https://wiki.alpinelinux.org/wiki/APKBUILD_Reference 2018-02-13 19:02:15 <_ikke_> probably because you'd normally not use them 2018-02-13 19:02:16 the error messages i get are here: http://xor.meo.ws/wRqE4yvPGvsY69vxCgVA1S6VQUCBVO23.txt, mainly "grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /usr/bin/motion" 2018-02-13 19:02:43 whoops - found but not in the variables section. 2018-02-13 19:02:49 ikke: thanks. 2018-02-13 19:03:13 Why don't you use cross compilation that could make builds way faster. 2018-02-13 19:06:27 BernhardG: the number of packages that are known to cross-compile correctly is incredibly small. Cross-compilation is dangerous because most build systems do not get it right, and hidden errors can lurk in the binaries for a long time. 2018-02-13 19:06:47 Combine this with the fact that qemu will often run a binary that won't work on a real machine. 2018-02-13 19:07:12 so, in order to be able to deliver packages that really work, cross-compilation is not an option. 2018-02-13 19:08:13 Ok, that sounds true. I did not have much problems (compiling x86 and arm on x86_64) up to now. 2018-02-13 19:09:43 x86 will probably mostly work. arm is another story. ^^ 2018-02-13 19:22:07 @ncopa there is a discussion on the ML from 2016 and nobody seems to be able to make headway. Debian backported the patch for runstatedir. Could we consider this? 2018-02-13 19:22:16 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759647 2018-02-13 19:24:50 Ok, one more packaging question: I think I should package burp into multiple packages (burp, burp-server and burp-doc). Reason for this: server needs bash for its scripts. Is there a way to specify this (different dependencies) in one APKBUILD? 2018-02-13 19:25:41 <_ikke_> BernhardG: yes 2018-02-13 19:26:19 BernhardG: https://wiki.alpinelinux.org/wiki/APKBUILD_Reference#subpackages 2018-02-13 19:27:05 https://wiki.alpinelinux.org/wiki/APKBUILD_examples:Multiple_Subpackages 2018-02-13 19:27:46 <_ikke_> you can specify depends in the split function as well 2018-02-13 19:27:53 ^ 2018-02-13 19:28:18 ag: this is the subpackage feature I already know. So if I understand the example right I have to specify the depends variable inside the burp_server() function. 2018-02-13 19:28:28 just server() 2018-02-13 19:28:36 oh - yes 2018-02-13 19:28:57 it will split the subpackage name on the last hyphen and use the last part as the function name 2018-02-13 19:29:17 if you need to specify the function for some reason, you can use my-subpkg-name:the_function 2018-02-13 19:29:46 <_ikke_> usually you do just $pkgname- 2018-02-13 19:30:02 This is quite nice. And its all written in ash, right? 2018-02-13 19:30:21 <_ikke_> in posix shell 2018-02-13 19:30:35 The build system is much more flexible than I thought at first sight. 2018-02-13 19:31:30 BTW, you shouldn't need to specify a -doc function, as it has a default. If you need to specify extra commands after the default, call `default_doc` at the top of your doc() function 2018-02-13 19:32:37 ag: yeah - the splitting of main and doc already works. But I added some additional files to it. 2018-02-13 19:33:42 ag: default_doc is very helpful - that was missing up to now. 2018-02-13 19:33:47 <_ikke_> usually you can just copy files during package(), and the split function will do it's work (if you added files in default locations) 2018-02-13 19:34:51 _ikke_: yeah - it worked quite good out of the box. that was fascinating. 2018-02-13 19:35:32 BernhardG: you should read the source for abuild https://git.alpinelinux.org/cgit/abuild/tree/abuild.in 2018-02-13 19:36:29 ag. I just looked into it on my virtual maschine. There I found some infos about cross compiling and that was the reason why I tought I have to specify CBUILD and CHOST. 2018-02-13 19:36:34 Or at least use it for a reference, especially for the default_* functions 2018-02-13 19:36:53 But now I have a much better understanding. 2018-02-13 19:38:41 Thank you for your help on this point. Your community seems to be quite small but you help newcomers and this is special. 2018-02-13 19:40:24 I'm a newcomer too :) 2018-02-13 19:40:40 I now use Linux distributions since 1994 and have worked with a lot of systems and were in contact with a large amount of different developers. But your community is the niciest so far. 2018-02-13 19:41:29 I've been hacking on the Alpine build system and aports for just a few weeks now, but have found it really nice to work with and quick to grasp 2018-02-13 19:41:48 Seems like you're having a similar experience 2018-02-13 19:41:53 ag, yes that is true. I've started last friday. 2018-02-13 19:42:09 :) 2018-02-13 19:42:42 My goal is to create a VM template for opennebula that contains our tools and works as a preconfigured docker host os. 2018-02-13 19:43:20 Sounds like fun 2018-02-13 19:43:36 I'm working on something similar 2018-02-13 19:43:45 If this works good (it already works stable) I can imagine that I also switch our virtualization hosts (the opennebula hosts) to alpine (from CentOS 7) 2018-02-13 19:45:52 To get this done too I have to either use Ceph inside Docker or create Ceph packages for Alpine. There are some in testing but they seem unmaintained. 2018-02-13 19:46:35 Containerize all the things :) 2018-02-13 19:47:45 ag: then you should look into RancherOS. That is the system I've started with beginning of the last week. But I were not happy with it (and its community). 2018-02-13 19:48:34 I'm running Rancher also 2018-02-13 19:48:50 I also don't think that it is wise to containerize something (like Ceph) that is the base of our persitent data. 2018-02-13 19:49:33 If Ceph crashes somehow we could lose data. 2018-02-13 19:49:48 How so? 2018-02-13 19:51:13 Docker is IMHO really good for stateless things. But data is a state. I fear that some command could easily kill an ceph osd and therefore bring big problems. 2018-02-13 19:51:33 But you can just bind mount host directories into a container? 2018-02-13 19:51:34 <_ikke_> My opinion is to also keep data outside of docker 2018-02-13 19:52:04 The data is not within Docker 2018-02-13 19:52:30 <_ikke_> nod 2018-02-13 19:52:49 This is true. You can bind mount. But that does not work for Ceph that way. For the newer Ceph bluestore you need direct device access AFAIK. 2018-02-13 19:53:15 Then you just bind mount the /dev/{block-dev} special file into the container 2018-02-13 19:54:07 I'm just not seeing how what is essentially just a chroot jail makes any of this more fragile 2018-02-13 19:54:40 Anyway I am not sure how far I can go. Main problem is: I am shareholder of the company and I have some deep knowledge about many things. But I fear that our administrators are not able to follow my way if I am going too fast. 2018-02-13 19:54:51 Yeah, been there 2018-02-13 19:55:36 ag, you are right. It is not much different from a chroot. But debugging can be so much harder. 2018-02-13 19:57:05 One reason why I relly like alpine linux is that it does not have too much comfort functions. This way it it is much easier to understand - at least I hope so. 2018-02-13 19:59:14 Yeah, I love the simplicity of Alpine and that it comes with a grsec kernel (especially now that even test builds of the patches are non-public) 2018-02-13 19:59:33 In the last two years I've gone through the following technologies and changes: Ubuntu 14.04 with OpenStack, CentOS 7 with OpenStack, CentOS 7 with OpenNebula, CentOS 7 with Ceph and OpenNebula, auto provisioning, salt integration, zabbix auto discovery, zabbix auto registration, ... 2018-02-13 20:00:33 Wait, is Alpine now on linux-hardened instead of grsec? 2018-02-13 20:00:42 Now I finally had time to get Docker started in our Data center. This is too much for many administrators unfortunately. 2018-02-13 20:00:42 That's a lot 2018-02-13 20:00:44 <_ikke_> ag: it was renamed 2018-02-13 20:00:54 What was renamed? 2018-02-13 20:01:00 <_ikke_> ag: and fun fact, unless something changes, hardened will be phased out as well 2018-02-13 20:01:09 <_ikke_> grsec -> hardened 2018-02-13 20:01:25 The grsec project has merged with linux-hardened? 2018-02-13 20:01:31 <_ikke_> no 2018-02-13 20:01:48 it already seems it *is* phased out. 4.14.18 kernel is in edge and there is only virt and vanilla. 2018-02-13 20:01:56 <_ikke_> alpine renamed the package / flavour from grsec to hardened 2018-02-13 20:02:03 <_ikke_> BernhardG: right 2018-02-13 20:02:23 I can see that in testing? 2018-02-13 20:02:31 There is also a bug in virt as it depends on linux-firmware. I've already reported that bug. 2018-02-13 20:02:43 <_ikke_> They could not get the ktpi patches in the grsec kernels 2018-02-13 20:02:57 ag yes - you could upgrade your system to edge completely or doing a cherry pick. 2018-02-13 20:03:28 kpti you mean? 2018-02-13 20:03:47 http://lists.alpinelinux.org/alpine-devel/6022.html 2018-02-13 20:03:59 This is the mailing list link to that announcement 2018-02-13 20:04:03 <_ikke_> ag: sorry, yes 2018-02-13 20:05:13 I see, so we're just defaulting to vanilla as kpti is more important and those patches break hardened and grsec 2018-02-13 20:05:21 I think I now switch to my mobile. I am at work since 07:00 (Germany) and we now have 21:00. 2018-02-13 20:05:45 Many thanks for your help about packaging. 2018-02-13 20:05:47 Guten Abend :) 2018-02-13 20:06:07 ag, your're from germany too? 2018-02-13 20:06:16 <_ikke_> ag: yes, alpine was not comfortable distributing kernels that were vulnerable to meltdown and spectre 2018-02-13 20:06:20 Schweizer, but in the US 2018-02-13 20:06:44 _ikke_, makes sense thanks for the explanation 2018-02-13 20:09:03 so now on mobile 2018-02-13 20:09:19 <_ikke_> wb 2018-02-13 20:14:13 do you use some form of configuration Management with alpine? 2018-02-13 20:14:46 at the moment I use salt. but it is quite big 2018-02-13 20:15:23 <_ikke_> I haven't yet on alpine 2018-02-13 20:16:25 ansible and chef seem way too big 2018-02-13 20:17:31 <_ikke_> I don't think there is anyhting that is 'small' 2018-02-13 20:18:11 cfengine seems smaller and is written in C 2018-02-13 20:21:18 but I never tested it 2018-02-13 20:21:27 <_ikke_> me neither 2018-02-13 20:23:35 i have never used cfengine but I have met some of the developers 2018-02-13 20:24:06 i applied for work for them once 2018-02-13 20:25:21 it seems to me more like a programming language than salt. 2018-02-13 20:25:37 got reply 1+ year later :) 2018-02-13 20:25:47 the project has been around for a long time 2018-02-13 20:25:58 i have general good impression of it 2018-02-13 20:26:03 <_ikke_> salt user mostly yaml, most others use a dsl of some inds 2018-02-13 20:26:05 <_ikke_> kind 2018-02-13 20:26:12 i think the biggest problem with it is that it has high learning curve 2018-02-13 20:26:13 it seems difficult to get started 2018-02-13 20:27:22 one year to get a response? it must have been some really long mail. or super busy company. 2018-02-13 20:27:28 I only need it to transfer SSH keys as a first step. 2018-02-13 20:27:43 <_ikke_> przemoc: or it got lost in some pile and someone later found it again 2018-02-13 20:28:41 nah, i think they had some new project that included embedded or similar and looked over old applicants and find mine 2018-02-13 20:30:17 usually it is a good etiquette to at least reply "we're no longer looking for candidates" or something. 2018-02-13 20:33:30 they had an opening annouced which i applied to 2018-02-13 20:33:31 I applied and the I asked if it was ok that I went there to look how the offices looked like 2018-02-13 20:33:32 and went there and shaked hands with everyone 2018-02-13 20:33:32 i did that so the would remember me when they looked at the pile :) 2018-02-13 20:34:15 not bad 2018-02-13 20:34:26 <_ikke_> :D 2018-02-13 20:34:35 ncopa, you are now working for Docker, right? 2018-02-13 20:37:43 ok, then it didn't look that bad on their side. smart move BTW 2018-02-13 20:38:55 I read it before as they haven't communicated with you at all since you sent them your mail 2018-02-13 20:42:50 <_ikke_> Trying to compile something that fails on missing sigset_t, but I do see signal.h is being included. Any idea why it fails? 2018-02-13 20:45:33 do you have exact error message? make 2>&1 | tpaste 2018-02-13 20:46:36 maybe lack of _XOPEN_SOURCE 500 or similar def 2018-02-13 20:47:16 _GNU_SOURCE 2018-02-13 20:47:47 <_ikke_> http://tpaste.us/kW61 2018-02-13 20:48:02 I always avoid _GNU_SOURCE unless really necessary 2018-02-13 20:48:47 <_ikke_> _POSIX_SOURCE? 2018-02-13 20:49:47 runtime.h:173:8: error: unknown type name 'sigset_t' 2018-02-13 20:49:58 is #include in runtime.h, before line 173? 2018-02-13 20:50:34 <_ikke_> it's on line 21 2018-02-13 20:50:56 i dont think any *_SOURCE should be needed: http://pubs.opengroup.org/onlinepubs/7908799/xsh/signal.h.html 2018-02-13 20:51:09 also verify that the #include is not withing some #ifdef or simlar 2018-02-13 20:51:21 verify that #include is actually included 2018-02-13 20:51:34 <_ikke_> It's in an ifdef, but in the else part of something that checks for windows 2018-02-13 20:52:02 <_ikke_> #if defined(LISP_FEATURE_WIN32) && defined(LISP_FEATURE_SB_THREAD) 2018-02-13 20:53:02 you can add a temporary "#error foobar" over the #include 2018-02-13 20:53:05 and run make 2018-02-13 20:53:13 to verify that it fails with error: foobar 2018-02-13 20:53:32 ncopa: it's SUS2, what you showed, which means _XOPEN_SOURCE 500 (or greater) isn't out of question 2018-02-13 20:54:21 http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/signal.h.html 2018-02-13 20:54:26 "Some of the functionality described on this reference page extends the ISO C standard. Applications shall define the appropriate feature test macro (see XSH The Compilation Environment ) to enable the visibility of these symbols in this header" 2018-02-13 20:55:16 ok 2018-02-13 20:55:24 in practice it's rarely useful to go below _XOPEN_SOURCE 600 or 700 2018-02-13 20:56:56 <_ikke_> I do see #ifdef guards around the parts that include bits/alltypes.h, but is that because it might be defined elsewhere already? 2018-02-13 20:57:13 <_ikke_> (that's in /usr/include/signal.h) 2018-02-13 20:57:48 no, not everything is exposed by default, that's why you define what level of support you want or need in your code 2018-02-13 20:58:14 <_ikke_> ncopa: I do see the error 2018-02-13 21:07:15 I am very happy that our changes from Adelie are being merged in to Alpine now :) 2018-02-13 21:09:50 <_ikke_> Would I break a lot if I would do something like #define _POSIX_SOURCE\n#include \n#undefine _POSIX_SOURCE? 2018-02-13 21:11:43 That depends wildly on a number of factors 2018-02-13 21:11:46 You could 2018-02-13 21:12:03 <_ikke_> trying to find out why sigset_t is not defined 2018-02-13 21:12:38 IAMB3NW: it's wrong what you showed. if you define that way, you should define with 1 at least, not empty, and rather not undefine later. and 1 is rather not enough here I presume, because 1 reference to ancient version. 2018-02-13 21:12:46 i dont think you can #undefine it 2018-02-13 21:13:11 IAMB3NW: sorry, wrong tag ;) 2018-02-13 21:13:30 #undef 2018-02-13 21:14:23 <_ikke_> ncopa: I do see things like that for _BSD_SOURCE in the project 2018-02-13 21:14:29 the thing is undefining is conceptually wrong, as code is written for POSIX (or other standard) or it's not written for it, not half for POSIX and half not... 2018-02-13 21:14:34 _ikke_: try building with -D_XOPEN_SOURCE=700 2018-02-13 21:16:07 <_ikke_> They seem to use shell scripts (make.sh) 2018-02-13 21:53:43 Any idea what's up with "ERROR: mpfr3-3.1.5-r1: BAD archive" in https://travis-ci.org/alpinelinux/aports/jobs/341156958 2018-02-13 21:54:54 corrupted file perhaps? 2018-02-13 21:59:49 przemoc, but there's no data about is cdn used or something local to travis 2018-02-13 22:03:55 it is broken on NL mirror apk -X http://nl.alpinelinux.org/alpine/edge/main add mpfr3 2018-02-13 22:06:21 yeah, it is invalid apk indeed on nl.a.o. gzip spits: invalid compressed data--crc error, invalid compressed data--length error 2018-02-13 22:12:47 clandmeter ^^^ is there a problem with nl.* storage ? 2018-02-13 22:14:18 Afk atm 2018-02-13 22:14:55 cz has no issues? 2018-02-13 22:16:20 only 1 byte differs 2018-02-13 22:16:48 wtffffffff 2018-02-13 22:16:50 you should investigate storage status 2018-02-13 22:17:12 agreed 2018-02-13 22:20:28 I also recently had storage issue (and possibly still have one). possibly my usb flash drive is not well suited for continuous work. finding errors like corrupted net config with some subtle ip changes, letter case changes, etc. had to apk fix -r many packages, but it's hard to catch that kind of stuff if you haven't checksummed everything earlier 2018-02-13 22:22:32 I have proposition to extend apk to store checksums of files included in it, to make easy compare on-disk state with original package state (it's ok if config differs, of course, because they're often changes) 2018-02-13 22:22:58 s/changes/changed/ 2018-02-13 22:24:25 initially I suspected memory problems, as I've noticed other problems earlier, but then files that haven't been touched for a long time (like /etc/network/interfaces) wouldn't be corrupted. 2018-02-13 22:24:40 could also be used for something like tripwire gets used for normally 2018-02-13 22:36:47 przemoc: apk can already do that. `apk audit` :) 2018-02-13 22:37:47 how I could overlooked that?! 2018-02-13 22:40:44 what?! nice 2018-02-13 22:40:47 it lacks any info in --help how results should be interpreted, though 2018-02-13 22:43:35 at least I can detect more broken stuff on my storage 2018-02-13 22:43:40 thanks, kaniini! 2018-02-13 23:09:29 already fixed several stuff. U /lib/modules/*/modules.* seem kind of ok, I guess, as they're regenerated, but I'm wondering about X usr/share/fonts/encodings/encodings.dir as I already apk fix -r encodings, but encodings.dir is still not there. I verified with tar -tf that this dir is indeed present in .apk, so it's really strange 2018-02-13 23:13:30 bye 2018-02-13 23:23:45 one correction: encodings.dir is not a dir, it's a file 2018-02-13 23:34:37 it looks like mkfontscale trigger (or actually mkfontscale binary, that is run by the trigger) unlinks this file for some reason. 2018-02-13 23:35:02 so it's a non-issue and not a bug in apk (which I feared for a moment) 2018-02-13 23:41:42 my Travis build on a PR just failed with "ERROR: mpfr3-3.1.5-r1: BAD archive", what do? 2018-02-13 23:41:51 (during deps) 2018-02-13 23:42:43 known problem, someone will have to investigate nl.a.o storage, because that's where the bad package is 2018-02-13 23:42:59 d'oh 2018-02-13 23:43:59 how long has that been an issue? any idea? 2018-02-13 23:46:02 it was reported ~2h ago on this channel, and there are apparently no AL devs with access to it available atm 2018-02-13 23:46:17 oh ok, so not very long 2018-02-13 23:46:21 thanks for the info 2018-02-13 23:47:10 it may take some time, I guess, because it has to be investigated, why this corruption happened in the first place 2018-02-13 23:48:11 yeah, that's odd. I assume it's happening to more than one package? 2018-02-13 23:48:23 so far only one was reported 2018-02-13 23:48:48 maybe just a bit flip in RAM somewhere :P 2018-02-13 23:50:18 the file is corrupted in one byte exactly, so it looks like some corruption happened during writing the package on disk, or it happened later on-disk so all reads are now with this wrong byte 2018-02-13 23:51:56 if there were more reports of broken packages, it would mean disk there may be failing, but single accident doesn't necessarily mean that storage there is screwed, yet such errors shouldn't be ever taken lightly 2018-02-13 23:52:47 definitely not. could be controller starting to fail or who knows what 2018-02-14 00:00:40 just for the record, this one byte difference is actually one bit difference. forgot to mention it earlier 2018-02-14 00:01:58 $ cmp -bl mpfr* 2018-02-14 00:01:58 119524 214 M-^L 254 M-, 2018-02-14 00:04:24 looks like a bunch of PRs failed with the same mpfr3* BAD archive error...will those pull requests be automatically retried when the mpfr3* issue has been corrected? or will the PRs have to be submitted again? 2018-02-14 00:08:01 I'm not sure if travis allows to retrigger PR build. you can surely retrigger normal builds if you have write access to the repo, but no idea about PRs 2018-02-14 00:56:16 yeah, I kind of like this hyperkitty UX from what I see after clicking a bit there. it has some stuff that would need tuning (e.g. too few entries showed by default, requiring to click ellipsis, too bloated UI taking too much screen estate), but it seems usable and thought-out. 2018-02-14 00:56:46 wrong window, damn 2018-02-14 05:55:16 <_ikke_> przemoc: defining -D_XOPEN_SOURCE=700 at the right place seem to have solved that particular issue 2018-02-14 05:57:42 <_ikke_> przemoc: next issue is NSIG, and it appears that I *do* require _GNU_SOURCE there 2018-02-14 09:36:44 <_ikke_> przemoc: with _GNU_SOURCE it compiled. Is there a better alternative? 2018-02-14 09:37:20 _BSD_SOURCE should be good enough too 2018-02-14 09:37:50 <_ikke_> Alright. Is there a reason why _BSD_SOURCE is better than _GNU_SOURCE? 2018-02-14 09:41:54 it's about expressing the intent. I think using _GNU_SOURCE should be avoided unless it's really needed to expose GNU-only stuff. possibly not everyone will agree with me on that. 2018-02-14 09:42:15 <_ikke_> ok 2018-02-14 09:43:11 <_ikke_> but _BSD_SOURCE seems kind of arbitrary as well to me 2018-02-14 09:43:46 NSIG _is_ visible on BSDs. 2018-02-14 09:45:35 NSIG is exposed with _XOPEN_SOURCE too AFAIK 2018-02-14 09:45:39 give it a go :) 2018-02-14 09:45:43 <_ikke_> I did 2018-02-14 09:45:53 in glibc headers it's exposed regardless of feature macros present if I'm not mistaken. musl is simply much more strict, which is a good thing. 2018-02-14 09:46:08 <_ikke_> it failed to compile with -D_XOPEN_SOURCE+700 2018-02-14 09:46:11 <_ikke_> it failed to compile with -D_XOPEN_SOURCE=700 2018-02-14 09:46:11 kaniini: it's not a POSIX thing 2018-02-14 09:46:22 so _XOPEN_SOURCE is not good enough 2018-02-14 09:46:28 for NSIG 2018-02-14 09:49:27 hmm 2018-02-14 09:54:19 kaniini: I suspect you are possibly confused by musl default behavior (which is sane) that it defaults to -D_BSD_SOURCE=1 -D_XOPEN_SOURCE=700, but it only happens if no *_SOURCE is already defined 2018-02-14 10:04:15 it is possible =) 2018-02-14 10:06:52 _ikke_: application/library developer should be mindful about what featureset she/he wants/needs and express it by either defining proper _*_SOURCE at the very top of the source file (before including headers) or build all source files with appropriate D_*_SOURCE (but if applying same _*_SOURCE stuff to all files cannot give proper results, then it's generally better to go with defining them 2018-02-14 10:06:58 appropriately in-source at file level). lack of any of this is a issue that limits portability and can/should be reported upstream. 2018-02-14 10:07:58 lack or wrong use 2018-02-14 10:08:01 of course 2018-02-14 10:08:50 <_ikke_> przemoc: The source does it at some places, but in a #define..; do something #undef fashion 2018-02-14 10:11:01 <_ikke_> przemoc: the XOPEN_SOURCE=x derictive makes sense, I expect up until this level 2018-02-14 10:11:56 <_ikke_> but defining _BSD_SOURCE on a non BSD system (and same for _GNU_SOURCE on a non-GNU system) is kind of arbitrary 2018-02-14 10:12:46 <_ikke_> _GNU_SOURCE kinda does make sense if people expect to be in a GNU like environment though 2018-02-14 10:13:15 <_ikke_> But that's just from an outside perspective :-) 2018-02-14 10:14:57 it's not really arbitrary. if you use features originating on BSD systems (or some older unices), you should state that. by going with _GNU_SOURCE in that situations your code will be less portable, because other envs can implement BSD features and not-necessarily support any GNU compat stuff. 2018-02-14 10:17:47 in that regard GNU is like cancer, because many people using GNU solutions (be it libs, tools, whatever) expect that whole worlds uses it, which is not true. 2018-02-14 10:18:23 <_ikke_> Right, but in that case you have little choice as a packager, right? 2018-02-14 10:18:29 <_ikke_> Except not packaging it 2018-02-14 10:19:01 <_ikke_> But the the source of the features makes sense 2018-02-14 10:19:10 you can contact upstream and try to convince them to do better job 2018-02-14 10:19:58 and until they'll do it, yes, you have to patch it in the distro, if you want to have that package 2018-02-14 10:26:45 and #undefing _*_SOURCE really makes no sense, it's on the verge of being broken. you define _*_SOURCE for given compilation unit and these defines usually define bunch of other internal defines in system headers, that you're not necessarily aware of or should be. #undefing it between various headers leads you to some undefined state in regards to what features will be really exposed, most likely 2018-02-14 10:26:51 different from what man writing such #undef believed to achieve. 2018-02-14 10:31:10 BTW kaniini: congrats on achieving first milestone with libucontext 2018-02-14 10:31:59 przemoc: what is the preferred solution? Have one header file with _*_SOURCE defines, and let autoconf figure out which ones are needed in the current platform? 2018-02-14 10:43:52 I avoid autoconf, so cannot talk about it in particular. in great majority of cases you don't need varying feature set between source files, so building everything with same _*_SOURCE defines mindfully picked by developer according to her/his needs should be really good enough. such defines should be treated mostly the same on various platforms (unless they're broken). and if you're dealing with 2018-02-14 10:43:58 some broken platforms, then having separate file header dealing with it instead of -D... during compilation seems fine (header that is included by all your source files at the top, of course, unless that brings some conflicts too on your platform, then you have to go at file level) 2018-02-14 10:50:22 sometimes there can be additional defines needed by some platforms (like _DEFAULT_SOURCE for glibc to avoid warnings), but they should not cause any problems on other platforms (usually), so it's better to define all than trying to be overly smart (oh, we're on some BSD? then maybe I can omit _BSD_SOURCE, right, it's BSD after all, so no need to specify that...) 2018-02-14 12:59:20 Makes sense. Most problems are probably with platforms that the developers don't have access to, or rarely test on, so sometimes they assume 'feature X will always be there', and don't include the _xx_SOURCE 2018-02-14 15:48:41 setup-disk -m sys /mnt does not work on the f2fs filesystem. Is this bug or is there reason for this? 2018-02-14 16:24:55 If the mpfr3 package is fixed in nl could someone please restart the CI build for #3304? Thanks! 2018-02-14 16:25:06 (PR 3304) 2018-02-14 18:33:08 uff gns3 break again due to aiohttp upgrade 2018-02-14 19:22:58 kaniini, re: libucontext on x86: makecontext clobbers EBX which is supposed to be the PLT/GOT pointer. so when __start_context calls __setcontext via PLT it blows up 2018-02-14 19:23:50 kaniini, maybe reload GOT pointer to EBX in __start_context ? 2018-02-14 19:34:52 kaniini, http://tpaste.us/PLE7 seems to fix it for me 2018-02-14 19:39:47 oh, ebx needs to be loaded before jump to hosed, or also for the exit() call 2018-02-14 23:34:20 that pkg doesn't run checks although check() is defined: http://build.alpinelinux.org/buildlogs/build-edge-x86_64/testing/nim/nim-0.17.2-r1.log 2018-02-14 23:35:17 why? 2018-02-15 00:13:50 do you run armhf? 2018-02-15 04:26:33 aha 2018-02-15 12:56:39 koldbrutality: no, x86_64 2018-02-15 12:57:44 build-edge-x86_64 2018-02-15 12:58:44 Greetings, any chance a spectre safe kernel is getting to 3.7? Also wondering if its decided 100% to go with vanilla instead of hardened? The version from copperhead seems promising.. https://github.com/copperhead/linux-hardened 2018-02-15 13:04:12 Before I submit a pull request for a new aport (my first one) I've made. I would like to have some feedback. Could someone please help me? 2018-02-15 13:05:46 clandmeter or ncopa: kill #8488 2018-02-15 13:06:43 This is the aport I've created (burp is a network backup and restore program): https://github.com/BernhardGruen/aports/tree/burp/testing/burp 2018-02-15 13:08:38 danieli: i neutralized it 2018-02-15 13:08:55 kaniini: thank you sergeant 2018-02-15 13:08:57 good work 2018-02-15 13:10:50 but you don't want to download game killer apk ?! 2018-02-15 13:10:58 no thank you, i got frida <3 2018-02-15 13:11:43 bulld00zer: there is not really much difference between strcat's linux-hardened tree and vanilla 2018-02-15 13:12:03 (as in what we ship as vanilla) 2018-02-15 13:12:18 neither are comparable or equivalent to grsecurity, unfortunately 2018-02-15 13:15:03 kaniini: that's what I figured, too bad Brad and the gang did not get some more funding from the big corps "borrowing" their code. 2018-02-15 13:15:28 kaniini: Do you know if the new kernel will find it's way down to 3.7 or will it be in edge only until the next release? 2018-02-15 13:17:45 yes, we intend to have linux-vanilla 4.14 in 3.7 2018-02-15 13:18:08 we are still deciding what to do about the migration of linux-hardened packages though 2018-02-15 13:22:47 Wouldn't it be the best for everyone if there would at least be a new kernel available in 3.7? Even if the newer hardened version is not as good as it could be. It is still better from a security aspect than the one currently provided with 3.7 2018-02-15 13:23:51 yes 2018-02-15 13:23:53 i think we should start with upgrading the linux-vanilla kernel to 4.14 2018-02-15 13:23:57 From my personal view I would prefer having a transition package from linux-virthardened to linux-virt. 2018-02-15 13:24:16 may i ask why all the grsecurity mitigations are less important than two half-assed mitigations against two new bugs? this is a honest question, no fanboiing or anything... 2018-02-15 13:25:11 because grsecurity does not solve spectre and meltdown 2018-02-15 13:25:25 yes, but it solves a lot of other unsolved issues 2018-02-15 13:25:32 hs3dUBwdmCjy, I don't think they are less important. The ideal situation would be a kernel that contains all mitigations. 2018-02-15 13:25:40 and the fixes for those are so intrusive that we can no longer maintain the unofficial fork 2018-02-15 13:25:57 part of the problem is that grsecurity is not free 2018-02-15 13:26:18 But if I understand it right, the Alpine Linux team does not have enough power to provide that. And I can understand that fully. 2018-02-15 13:26:20 i'd love continue with it, but we cannot 2018-02-15 13:26:23 i understand the the fork/grsecurity issues 2018-02-15 13:26:41 what i don't understand is the measuring which of the mitigations are more important 2018-02-15 13:26:43 we can chose between stay on 4.9.72 kernel for ever or switch to vanilla kernel 2018-02-15 13:27:17 we have a bunch of mature mitigations in grsec, and we have 2 kinda halfassed mitigations for the intel bugs. 2018-02-15 13:27:43 jirutka: what is your opinion on https://code.foxkit.us/adelie/aports/commit/53c43166 2018-02-15 13:27:53 its not only about those 2 intel bugs 2018-02-15 13:28:00 its about all other bugs too 2018-02-15 13:28:10 Is there a team that currently maintains the forked grsecurity -> hardened patches? 2018-02-15 13:28:43 but 4.9 is still lts and gets bugfixes backported no? 2018-02-15 13:29:01 BernhardG: not anymore 2018-02-15 13:29:39 hs3dUBwdmCjy: yes, but we cannot backport them anymore 2018-02-15 13:29:50 that is the problem 2018-02-15 13:30:04 did we backport or did gk-h backport the bugfixes? 2018-02-15 13:30:17 i thought gk-h is the maintainer of lts? what do i misunderstand? 2018-02-15 13:30:21 gk-h 2018-02-15 13:30:35 but he only backports for vanilla kernel 2018-02-15 13:30:38 Yes, right, hs3dUBwdmCjy. I don't think it would be a problem to have 4.9 instead of 4.14 in Alpine 3.7. But it is not possible to merge it with grsecurity patches if I understand right. 2018-02-15 13:30:51 those backports no longer apply to the grsec kernel 2018-02-15 13:31:12 ah. i see. 2018-02-15 13:31:15 the fixes for intel issues are not comaptible with grsecurity 2018-02-15 13:31:16 If I read it right 4.9 uses KAISER but 4.14 uses KPTI 2018-02-15 13:31:25 that too 2018-02-15 13:31:34 ah, but the intel bugfixes for 4.9 suck donkeyballs anyway 2018-02-15 13:31:39 the fixes for 4.9 is broken from what i read 2018-02-15 13:31:43 exactly 2018-02-15 13:32:49 IMHO (and I don't know the Alpine community as I only use it since 6 days) the most robust solution will be to switch to 4.14 (vanilla) for now. 2018-02-15 13:33:11 that is the current plan 2018-02-15 13:33:36 If someone again maintains the hardened patches the could get integrated again (for 4.14). 2018-02-15 13:33:55 only spender and pipacs can do that 2018-02-15 13:34:17 and they dont release their work for public 2018-02-15 13:35:03 i asked spender for a (test) 4.14 patch, but got a clear no 2018-02-15 13:35:23 that was before intel bugs 2018-02-15 13:35:30 (i think) 2018-02-15 13:35:57 basically, if you want grsecurity you need to buy it and build it yourself 2018-02-15 13:36:28 Doesn't gentoo still provide grsecurity/hardened patches? 2018-02-15 13:36:38 If so - where are they from? 2018-02-15 13:36:48 the past 2018-02-15 13:37:51 no 2018-02-15 13:37:51 are there any recent patches for gentoo? 2018-02-15 13:38:17 also upstream kernel developers tries to port parts of grsecurity and gets it wrong 2018-02-15 13:38:47 we did the unofficial fork as long as it was possible 2018-02-15 13:38:58 and used minipli's fork after that 2018-02-15 13:39:11 grsec likes reminding everyone that people do bad work at porting / implementing their patches 2018-02-15 13:39:19 jirutka: we intend to actually use dash as /bin/sh, not bash. but it needs to be fixed. i may just isolate busybox's version of dash and use that instead. 2018-02-15 13:39:19 :'} 2018-02-15 13:40:07 jirutka: as for busybox doing more, it is true, but most of the implementations are not sufficiently robust. coreutils suite, by far, is the main thing consumers of busybox are using. 2018-02-15 13:41:51 just curious, have anyone in the alpine project reached out to Spender and asked? 2018-02-15 13:42:15 yes 2018-02-15 13:42:34 bulld00zer: i asked spender for a (test) 4.14 patch, but got a clear no 2018-02-15 13:42:51 I see, guess they are really mad which I understand 2018-02-15 13:43:06 Not ideal for linux though 2018-02-15 13:43:12 it's not mad, per se 2018-02-15 13:43:14 And I don't know why he (spender) should to an exception for Alpine. 2018-02-15 13:43:19 it's concentrating on supporting their customers 2018-02-15 13:43:26 yeah, its business 2018-02-15 13:43:41 if you give stuff away for free and it just gets you drama 2018-02-15 13:43:42 why bother 2018-02-15 13:44:14 Gentoo seems to have stopped grsec too. https://www.gentoo.org/support/news-items/2017-08-19-hardened-sources-removal.html 2018-02-15 13:44:29 What I meant was pissed of because no big entities gave money back... Like Cisco is not doing with openssh 2018-02-15 13:45:33 thats also business 2018-02-15 13:45:35 rip someone off til they get enough, then find someone else to rip off 2018-02-15 13:45:57 yep 2018-02-15 13:45:57 anyway 2018-02-15 13:46:11 capitalism in a nutshell (cough -offtopic cough) 2018-02-15 13:46:12 apk alternatives is on my todo list some time after 3.8 2018-02-15 13:46:12 How many people (including me) are using Alpine for their business for free? 2018-02-15 13:46:20 adelie linux 2 will be 3.10/4.0/whatever 2018-02-15 13:46:52 well 2018-02-15 13:46:53 that's fine 2018-02-15 13:46:59 you don't expect an SLA 2018-02-15 13:47:11 its perfectly fine to use it for free 2018-02-15 13:47:14 the people who were using the 'free' grsecurity patches honestly 2018-02-15 13:47:23 some of them were pretty nasty people 2018-02-15 13:47:35 and demanded a lot of shit from spender 2018-02-15 13:47:42 so between that and the KSPP 2018-02-15 13:47:49 yes 2018-02-15 13:47:50 i can understand why he decided to call it quit 2018-02-15 13:48:02 they wanted SLAs and other nonsense on the testing patch 2018-02-15 13:48:12 funny with people that dont pay AND come with demands :P 2018-02-15 13:48:14 I don't think anybody disputed that spender was perfectly justified in doing what he did 2018-02-15 13:48:21 if you saw on twitter, people ripped on them for problems in the testing patches, really nasty stuff 2018-02-15 13:48:35 what most people (me included) disagree with is the attitude he had, and still has :P 2018-02-15 13:49:12 i think a lot of that has to do with the vocal minority who surrounded grsec 2018-02-15 13:49:25 I think the Mr bad-behavior does not just sit on one side of the table. ;) 2018-02-15 13:49:25 we dealt with a lot of those guys when grsec went private 2018-02-15 13:49:29 they came here demanding we fork it 2018-02-15 13:50:07 i'm not saying spender hasn't made an ass of himself on multiple occasions 2018-02-15 13:50:10 but i can understand his frustrations 2018-02-15 13:50:16 totally 2018-02-15 13:50:26 if you're getting hit with crap on one side (toxic community) and then also another side (KSPP) 2018-02-15 13:50:33 you're probably going to be pretty grouchy 2018-02-15 13:50:58 definitely, but then there's the public image aspect 2018-02-15 13:51:11 I also fully understand his frustration. But I fear he also has annoyed some possible customers with his words. 2018-02-15 13:51:12 if you're enough of an ass in public, that certainly doesn't help your situation :P 2018-02-15 13:51:17 spender does not strike me as somebody who cares about that (: 2018-02-15 13:52:09 BernhardG: yes, i suspect that may be part of why KSPP is a thing to begin with 2018-02-15 13:52:13 but this horse has been beaten so many times here 2018-02-15 13:52:17 so lets move onto something else 2018-02-15 13:52:27 i dont think they want or need many customers 2018-02-15 13:52:35 Another thing I asked me already some years ago: why there is noone else that programs similar patches if there is so much demand. 2018-02-15 13:53:07 s/me/myself 2018-02-15 13:53:13 because it's hard 2018-02-15 13:53:14 because its hard 2018-02-15 13:53:21 because it's hard 2018-02-15 13:53:38 (nobody else?) 2018-02-15 13:53:43 meanwhile at adelie 2018-02-15 13:53:47 coreutils-8.29-r1 installed size: 1105920 2018-02-15 13:53:52 maybe i should upstream this 2018-02-15 13:54:04 because on alpine 2018-02-15 13:54:15 coreutils-8.29-r0 installed size: 5394432 2018-02-15 13:54:19 wat 2018-02-15 13:54:26 whats the diff? 2018-02-15 13:54:35 --enable-single-binary=symlinks 2018-02-15 13:54:44 ew 2018-02-15 13:55:11 Ok, but who knows if spender is really able to write those patches? 2018-02-15 13:55:22 in other words, coreutils is like busybox now ;) 2018-02-15 13:55:31 BernhardG: just submit your PR, it makes no sense to review it twice. 2018-02-15 13:55:44 clandmeter, fine. Thank you 2018-02-15 13:55:45 yeah, well, I can understand how it's justified for busybox 2018-02-15 13:55:54 but for GNU stuff, wtf 2018-02-15 13:56:15 skarnet: well, basically, it means coreutils becomes essentially a static PIE that is still linked against libc 2018-02-15 13:56:27 so that is how you cut 4MiB off ;) 2018-02-15 13:56:34 it's disk 2018-02-15 13:56:44 only people like ncopa care about disk :P 2018-02-15 13:56:53 i care about disk 2018-02-15 13:56:54 and docker apparently 2018-02-15 13:57:15 I care about disk when there's no tradeoff with ram and cpu 2018-02-15 13:57:16 not for adelie desktop, but for adelie core we care about disk 2018-02-15 13:57:26 and single-binary does have those tradeoffs 2018-02-15 13:58:04 adelie-core should use sbase then, not coreutils ;) 2018-02-15 13:58:23 we have not audited sbase yet 2018-02-15 13:58:34 I should do it sometime 2018-02-15 13:58:44 and in general, i doubt there is philosophical alignment with us and suckless.org 2018-02-15 13:58:55 what are the disagreements? 2018-02-15 13:59:16 for example, we like long options, and from what i have seen of suckless.org tools, they don't 2018-02-15 13:59:28 indeed 2018-02-15 14:00:48 skarnet: also, overall, the single-binary overhead is minimal, since there's only one copy of it in RAM at any time 2018-02-15 14:00:53 (in this case) 2018-02-15 14:01:24 that's actually the worst case 2018-02-15 14:01:35 when you have several copies, the text and rodata are shared 2018-02-15 14:04:28 anyway 2018-02-15 14:04:30 ncopa: http://tpaste.us/m5gE 2018-02-15 14:04:34 ncopa: your thoughts? 2018-02-15 14:07:40 skarnet: well, that is basically the same scenario as building your software as static PIE ;) 2018-02-15 14:08:19 yeah, I don't like static pie, it's not really static :/ 2018-02-15 14:11:58 most likely the future is to write new busybox type thing from ground up using modern, secure C programming practices 2018-02-15 14:12:05 but that's not where we are today 2018-02-15 14:12:28 so shaving 4MiB off coreutils is not too shabby 2018-02-15 14:20:08 sbase is not really viable from my experience 2018-02-15 14:20:33 skarnet: how is it not static? 2018-02-15 14:20:56 try ldd'ing a static pie binary 2018-02-15 14:21:50 it's actually a shared ELF like a .so 2018-02-15 14:22:12 correct 2018-02-15 14:22:44 Shiz: can you elaborate on that experience a bit? 2018-02-15 14:23:19 it's missing a LOOOOT 2018-02-15 14:23:24 skarnet: that is true, but it's still static 2018-02-15 14:24:04 that's more a quirk of the ELF format than anything else 2018-02-15 14:24:08 it has no real implications otherwise 2018-02-15 14:24:18 well I don't like when objdump lies to me 2018-02-15 14:27:20 skarnet: why you bother about semantics in this case? as long as static pie bin serves its purpose, why it is a problem that it's actually shared ELF under the hood? 2018-02-15 14:28:32 because I like to verify I've correctly built my static binaries, and when ldd/objdump don't give me what I instinctively expect, it stresses me out 2018-02-15 14:28:46 and I waste time verifying further 2018-02-15 14:29:51 :D 2018-02-15 14:30:11 you need new tool: s6-is-bin-static-pie! 2018-02-15 14:30:38 you jest, but you don't know how much hair I've torn out fighting with libtool 2018-02-15 14:31:20 well this coreutils change seems to be working pretty decent 2018-02-15 14:31:22 and GNU projects that need separate flags in configure and in make so that libtool links statically and binaries that don't use libtool also link statically 2018-02-15 14:32:05 skarnet: should use file(1) :P 2018-02-15 14:32:12 kaniini: as long as we don'tm ake coreutils default 2018-02-15 14:32:49 shiz: coreutils is default in adelie already 2018-02-15 14:32:59 i have no interest in making it default in alpine 2018-02-15 14:33:08 kaniini: we have a few tools in separate packages 2018-02-15 14:33:19 like sfdisk 2018-02-15 14:33:36 yes, but coreutils does not have any splits 2018-02-15 14:33:48 oh, its maybe util-linux 2018-02-15 14:33:51 (other than the manpages) 2018-02-15 14:34:12 then it should work 2018-02-15 14:34:52 could it be treated that way without too much effort tho? preferably with a meta package to pull all of them if one's so inclined 2018-02-15 14:36:16 kaniini: im ok to push it to edge 2018-02-15 14:46:00 done 2018-02-15 14:46:33 we have cross-compile patch, but i suspect it is obsolete with this single-binary work 2018-02-15 14:46:40 i should look into that :) 2018-02-15 14:58:46 what is the current status of enforcing licensing format? 2018-02-15 14:59:31 the current status is no 2018-02-15 14:59:52 keep as is? 2018-02-15 15:00:16 need to revisit in 3.9 2018-02-15 15:00:23 we have found many licenses that SPDX did not have awareness of 2018-02-15 15:00:34 i mean for new apkbuilds it would make sense to follow something? 2018-02-15 15:01:00 for new apkbuilds, please follow SPDX 3 with the quirk that "GPL-2.0-or-later" can be "GPL-2.0+" 2018-02-15 15:01:09 but enforcing it with code is presently no 2018-02-15 15:01:30 right, no i mean mostly for reviewing. 2018-02-15 15:01:53 maybe with 3.9 we can enforce in code, but it won't make the 3.8 release cycle for sure 2018-02-15 15:39:25 kaniini: I had access to ppc64 (not le, though) very briefly last year, so no longer remember stuff, but aren't older ppc arch defines exposed by gcc on them too perhaps? IOW aren't you perhaps forcing BE on ppc64le in case of lcms pkg? 2018-02-15 15:47:13 ... 2018-02-15 15:47:17 i'm not doing anything 2018-02-15 15:47:29 the problem is lcms build system is fucking stupid ;) 2018-02-15 15:49:04 their build system goes 2018-02-15 15:49:09 LOL POWERPC MUST BE BIG ENDIAN YEP 2018-02-15 15:49:19 i just didn't kill all of the nonsense 2018-02-15 15:49:26 and it's all nonsense too 2018-02-15 15:49:39 because autoconf determines it on it's own 2018-02-15 15:50:09 ok, I was referring to ppc64le.patch that you added 2018-02-15 15:50:26 yes 2018-02-15 15:50:31 kaniini: can't we just convert everything with a nonconforming license to something like misc: and revisit later? 2018-02-15 15:50:34 in that case 2018-02-15 15:50:36 my patch is removing that nonsense 2018-02-15 15:50:36 not adding it 2018-02-15 15:50:39 so we at least have the other bulk converted 2018-02-15 15:50:54 Shiz: yes, that is not what i am talking about though 2018-02-15 15:50:55 I already suggested notation for non-SPDX licenses 2018-02-15 15:51:10 so it could be used with other SPDX licenses 2018-02-15 15:51:11 Shiz: what i am talking about is "enforcing it in abuild" 2018-02-15 15:51:17 ah rgr 2018-02-15 15:51:54 we have completed a license audit and SPDX conversion on the entire adelie supported package set btw 2018-02-15 15:52:09 that has been trickling into alpine over past week or so 2018-02-15 15:56:54 przemoc: ok i defanged it this time 2018-02-15 15:57:38 przemoc: so many __powerpc__ #ifdefs ;/ 2018-02-15 16:00:58 seems at some point there was an ABI change on armhf, and boost was not rebuild 2018-02-15 16:01:26 indeed (regarding ppc) 2018-02-15 16:22:20 is isinff defined in musl? 2018-02-15 16:22:56 i see isinf 2018-02-15 16:27:38 i think I give up on electron. i will pass it on to someone else who wants to finish it. i got it to run the --help but it just segfaults. 2018-02-15 16:29:13 its a nightmare because it uses chromium and node as internal dependencies... takes too long to compile 2018-02-15 16:30:05 cannot port atom editor or vscode without electron 2018-02-15 16:34:47 a huge amount of things are based on electron and CEF 2018-02-15 16:39:33 I upload it to https://github.com/orsonteodoro/electronapkbuild 2018-02-15 16:39:41 you guys can finish it 2018-02-15 16:49:03 i working on creating lmms package now. music creation software 2018-02-15 21:40:35 jirutka: I have seen this weird makedepends error before. What caused it on Adelie builders was outdated musl package conflicting with newer musl-dev package. So it seems that a package installed on all builders is older version and ruby-rugged is pulling in -dev package that conflicts. 2018-02-15 21:40:54 That could be libgit2, ruby, rake 2018-02-15 21:41:17 The solution is to apk upgrade the builders 2018-02-15 21:42:27 It is probably the libgit2 though. 2018-02-15 22:53:44 got lmms to show gui with paxmark... going to recompile with qt5 2018-02-15 23:50:26 anyone know anything about packaging creative commons? 2018-02-15 23:50:53 there are some audio plugins released under creative commons but didn't specified the version number 2018-02-15 23:51:21 how should that be handled? they were released as cc-by or cc-by-nc 2018-02-15 23:51:41 i mean demos 2018-02-16 00:02:18 i think i will just release it without cc demos 2018-02-16 07:24:14 hum... i could get stepmania working on software rendering but not on my ati / hw accelerated opengl 2018-02-16 10:55:25 koldbrutality: not sure what audio plugins you meant (or demos?), but you could try contacting upstream and ask them to clarify which version of CC BY or CC BY-NC they meant if they didn't specify that explicitly within released tarballs. if you were actually talking about demos being some audio files (mp3, etc.), then I don't think that kind od static assets should be in AL repos, but others may 2018-02-16 10:55:31 disagree perhaps. 2018-02-16 13:27:25 how to request rebuild some package in testing (in this case https://bugs.alpinelinux.org/issues/8483) 2018-02-16 14:00:52 mps: ok now? 2018-02-16 14:11:43 clandmeter: don't understand what you mean by "ok now?" 2018-02-16 14:15:17 mps: i problably didnt get the point. sorry. 2018-02-16 14:17:10 clandmeter: no problem. there is patch on bug report for tcsh which fixes crash 2018-02-16 14:18:03 clandmeter: so, I asked could be somehow tcsh rebuilt 2018-02-16 14:19:12 there is a PR for that issue 2018-02-16 14:19:21 and it has an issue to build, which i just fixed. 2018-02-16 14:19:50 just need somebody to look at that patch. 2018-02-16 14:21:02 I'm patched tcsh about two months ago with patch and now it works on armhf, aarch64 and x86 without problem 2018-02-16 14:21:22 I didn't tried other arch's 2018-02-16 14:29:25 ncopa: ping 2018-02-16 14:29:29 https://git.alpinelinux.org/cgit/aports/commit/main/procps/APKBUILD?id=d37343ea71ef531a6c40389307fd1cda6e5ea3fa 2018-02-16 14:29:36 why did you make this change? why can't procps live in /usr? 2018-02-16 14:29:46 as it stands it will cause busybox symlinks to take prio over procps tools 2018-02-16 14:33:33 2013 2018-02-16 14:34:00 ok if i make it live in /usr then? 2018-02-16 14:36:01 i think the idea back then was that it sould be possible to have /usr on separate partition 2018-02-16 14:36:02 i dunno why anybody would want that today though 2018-02-16 14:36:54 Shiz: i dont mind you move it back to /usr, but please verify the busybox location for the tools 2018-02-16 14:36:55 and make them correspond 2018-02-16 14:37:39 of course 2018-02-16 14:37:47 that's the intention of my patch :) 2018-02-16 14:38:12 i dunno how much we care about supporting /usr on separate partition 2018-02-16 14:38:24 At the moment they do not correspond btw. 2018-02-16 14:38:45 yeah so it should be fixed 2018-02-16 14:39:52 in my opinion separate partition /usr is deprecated by mkinitfs 2018-02-16 14:40:08 initramfs's should proivide all the tools needed for booting a system 2018-02-16 14:40:20 ... 2018-02-16 14:40:56 sure, why have a reliable, small, easily buildable rootfs when you can instead have an initramfs that's much harder to make and edit 2018-02-16 14:41:01 it's so much more fun 2018-02-16 14:41:11 it's not though 2018-02-16 14:41:31 are you seriously arguing that an initramfs is as transparent as a rootfs 2018-02-16 14:42:24 back in the day we didn't have this initramfs funny business 2018-02-16 14:42:34 exactly 2018-02-16 14:43:24 initramfs is only useful in specific circumstances (your rootfs is on a funky device you don't want to have the module for baked in your generic kernel) 2018-02-16 14:46:08 basically every rootfs is on a funky device nowdays 2018-02-16 14:47:12 ssd device, scsi, sata, nvme 2018-02-16 14:47:22 we dont want all those baked in the kernel 2018-02-16 14:48:09 then yes, use an initramfs, but between that and putting a whole environment in the initramfs, there's a gap 2018-02-16 14:48:09 we dont even want the filesystem driver baked in the kernel, some want zfs, some want ext4 some want xfs etc 2018-02-16 14:49:12 my main point is that it's easy to see what's on a rootfs and modify it, whereas visualizing and editing an initramfs is impractical 2018-02-16 14:49:36 initramfs feels like magic to the user, and magic is bad 2018-02-16 14:50:42 i dont argue against that 2018-02-16 14:50:46 but you will almost always still need initramfs 2018-02-16 14:50:56 has anyone tested to have /usr on separate partition? 2018-02-16 14:51:05 it may work 2018-02-16 14:51:23 it should 2018-02-16 14:51:36 if it doesn't, it must be fixed 2018-02-16 14:55:01 What reasons could one have to separate out /usr? At least for virtual environments I can't imagine a useful scenario. And on physical hardware I personally would use LVM to have the possibility to grow with the (disk space) needs. 2018-02-16 14:56:30 an initramfs is just a tarchive 2018-02-16 14:56:33 don't see how it's especially more magic 2018-02-16 14:57:05 however you wanna split out boot-specific parts, /usr is not the solution imo 2018-02-16 14:58:54 (Shiz, well you can't just "ls" the contents of a tar archive. So it at least needs some extra commands.) 2018-02-16 14:59:10 tar -tf 2018-02-16 15:00:11 its cpio archive, not tar 2018-02-16 15:01:12 there are some interesting setups where separate /usr may make sense 2018-02-16 15:01:38 lets say if you have a bunch of machines in a LAN where you mount /usr on nfs 2018-02-16 15:02:01 you install the app one place and everyone has access to it 2018-02-16 15:02:46 I've installed apline 3.7 XEN on flashcard as Dom0, after going thru https://wiki.alpinelinux.org/wiki/Create_Alpine_Linux_PV_DomU, xl create breaks with libxl: error: libxl_mem.c:202:libxl_set_memory_target: unable to retrieve domain configuration: No such file or directory ! :( 2018-02-16 15:03:21 Ok, ncopa that surely makes sense. But this does not fully work because the appindex / world is not updated for all machines. 2018-02-16 15:04:23 i dont think anybody use such setup or would use setup 2018-02-16 15:04:26 but its still "interesting" :) 2018-02-16 15:04:38 grharry: try an strace to see what it tries to open 2018-02-16 15:04:52 and check if you're really running in a xen kernel 2018-02-16 15:04:55 does xl list work 2018-02-16 15:05:12 or xl dmesg even 2018-02-16 15:05:21 yes xl works 2018-02-16 15:05:23 Domain-0 0 15990 12 r----- 25.5 2018-02-16 15:05:24 ok 2018-02-16 15:05:38 then it must be some thing like the domubuilder that's missing 2018-02-16 15:05:48 there could be some log entry in /var/log/xen/... 2018-02-16 15:06:19 /var/log/xen is empty 2018-02-16 15:06:40 ok then i go back to saying something about strace :))) 2018-02-16 15:07:07 hm ... 2018-02-16 15:08:21 open("/etc/ld-musl-x86_64.path", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 2018-02-16 15:08:25 is this normal ? 2018-02-16 15:11:28 i think so 2018-02-16 15:11:51 historically /usr on NFS is exactly how big installations worked 2018-02-16 15:11:59 there are still places where it works like that 2018-02-16 15:13:31 i doubt alpine users are interested in that sort of setup 2018-02-16 15:13:59 sure, but my point is, having a minimal working system in / is a good idea 2018-02-16 15:14:30 skarnet: do you think those installations could use Alpine Linux? I once had a PXE type setup and the client had the requirement to use an "enterprise linux" system (instead of my suggestion to use centos (5)). 2018-02-16 15:14:52 but yeah, that would be a valid reason to support /usr on separate partion 2018-02-16 15:15:21 his point is that it is a generally good idea to minimal working system in / 2018-02-16 15:15:22 Hey ncopa !!! 2018-02-16 15:15:30 maybe? honestly if people are woke enough to use Alpine I expect them to be woke enough to ditch NFS 2018-02-16 15:15:31 how you 've been ! 2018-02-16 15:15:42 long time ! 2018-02-16 15:15:51 https://pastebin.com/yG8F1WjU 2018-02-16 15:16:02 care to have a glance ? 2018-02-16 15:16:11 but either way, I think Shiz' idea was to have busybox and procps working together. 2018-02-16 15:16:13 hi grharry! 2018-02-16 15:16:22 and it's perfectly possible 2018-02-16 15:16:24 grharry: good thanks! how are you? 2018-02-16 15:16:35 just let busybox have its files in /bin and procps in /usr/bin 2018-02-16 15:16:49 bbbbbbbusy !! 2018-02-16 15:17:16 ncopa: I don't see why that couldn't be something not-/usr then 2018-02-16 15:17:20 but ah well 2018-02-16 15:17:24 skarnet: yeah - sure. but then you can't comfortably call things like top (the procps version) without calling /bin/top 2018-02-16 15:17:38 you mean /usr/bin/top ? 2018-02-16 15:17:42 skarnet: the point of busybox syms is that we don't make them if alternative tools are already there 2018-02-16 15:17:50 indeed 2018-02-16 15:17:53 wat 2018-02-16 15:17:55 skarnet, no busybox is in /usr/bin/top - procps is in /bin/top 2018-02-16 15:18:00 ... 2018-02-16 15:18:03 WHY 2018-02-16 15:18:13 because that's where busybox decided to place top 2018-02-16 15:18:20 always have the minimal tool in /bin and the complete one in /usr/bin 2018-02-16 15:18:22 ask denys 2018-02-16 15:18:40 is Denys responsible for how bb is packaged in Alpine? 2018-02-16 15:18:44 last time I checked he wasn't 2018-02-16 15:18:59 when you build bb there's an option "don't use /usr" 2018-02-16 15:19:04 -> that's what you want to tick 2018-02-16 15:19:31 since PATH has /usr/bin before /bin, if there's a complete version of foobar, "foobar" will call the complete version in /usr/bin/foobar 2018-02-16 15:19:46 and if /usr/bin/foobar doesn't exist, it will exec /bin/foobar, the minimal (bb) version 2018-02-16 15:20:01 relocating all of busybox now would likely be a very bad idea 2018-02-16 15:20:25 ¯\_(ツ)_/¯ never too late to do the right thing 2018-02-16 15:20:31 or is it? 2018-02-16 15:20:46 well i can trivially imagine it breaking user scripts 2018-02-16 15:20:50 skarnet: your solution to have busybox symlinks in /bin and the other tools ones in /usr/bin sounds like a good solution to me. but I fear that this relocation could destroy several installations. 2018-02-16 15:20:53 that hardcode the location to bb to get the 'correct' 2018-02-16 15:20:57 tool 2018-02-16 15:21:18 open("/var/lib/xen/userdata-d.0.00000000-0000-0000-0000-000000000000.libxl-json", O_RDONLY) = -1 ENOENT (No such file or directory) 2018-02-16 15:21:21 ? 2018-02-16 15:21:22 that's the very POINT of FHS, if there ever was one 2018-02-16 15:22:11 is it a "NON started" service ? 2018-02-16 15:26:16 I think there is a possible workaround against a possible breakage... make even more symlinks (from /usr/bin to the new location in /bin) 2018-02-16 15:27:55 no matter what workaround you concoct, replacing an implementation of a tool with another _will_ break some user scripts 2018-02-16 15:28:13 the only way to perform a change is to announce it well in advance 2018-02-16 15:28:35 give people a year or so to change their scripts 2018-02-16 15:28:44 skarnet: it is still the same tool (busybox). I don't speak for systems that already use the procps package. 2018-02-16 15:30:19 oh, you mean for changing /usr/bin/top to /bin/top? same thing, announce it in advance. Then yes, you can make a /usr/bin/foobar -> ../../bin/foobar symlink. And some time later, when you release a major version, you remove the symlink. If stuff breaks, people have been warned. 2018-02-16 15:34:16 ncopa: I think we should have retpoline in our gcc, if only for the kernel, no? 2018-02-16 15:38:27 ncopa: i run /usr on a seperate partition. 2018-02-16 15:42:12 hs3dUBwdmCjy: what are your main reasons for having /usr split from /, if I am allowed to ask? 2018-02-16 15:49:14 mostly historical reasons. but the compartmentalization is still is nice if any of the partitions fill up, that does have less impact than if it would be shared. 2018-02-16 16:01:31 to be fair, people who need to avoid partitions filling up already have monitoring in place 2018-02-16 16:04:22 ornot 2018-02-16 16:06:23 /shrug 2018-02-16 16:33:21 danieli: have you all made any progress with the mips64 port? i would like to bring up a mips64 machine so i can add support to libucontext :D 2018-02-16 16:33:40 Lochnair ^ 2018-02-16 16:33:52 i have not had time, sorry 2018-02-16 16:34:20 i haven't had enough time to make much progress at all, it hardly went out of the planning phase on my side, and people didn't seem very interested in alpine on mips 2018-02-16 16:34:43 i was going to contact an english company who are known to help out with cross-compilation toolchains and providing build hardware to open source projects 2018-02-16 16:34:55 i'm interested and there is a working port (Lochnair did it) 2018-02-16 16:34:57 so dunno 2018-02-16 16:35:08 maybe we can get it done for 3.9 2018-02-16 16:35:12 i have a decent mips64 build machine sitting idle 2018-02-16 16:35:25 1.2ghz octeon 2018-02-16 16:35:52 not the greatest but it should be able to keep up decently 2018-02-16 16:36:01 you do you, locnair is probably interested in joining you in working on that 2018-02-16 16:50:05 there is no qtwebengine package? 2018-02-16 16:50:23 trying to create the qutebrowser package 2018-02-16 17:02:50 koldbrutality: ping jomat re qutebrowser 2018-02-16 17:02:56 kaniini: do we have a 7.3 gcc port? 2018-02-16 17:22:17 shiz: not yet 2018-02-16 17:22:22 we need to solve gcc6/gcc7/gcc8 being installed in parallel 2018-02-16 17:22:27 why? 2018-02-16 17:22:29 because we need gcc6 for java 2018-02-16 17:22:59 gcc6 is the last gcc version to include GCJ 2018-02-16 17:23:07 and there's --program-suffix= is there not 2018-02-16 17:23:21 if only portola was easier to keep up with 2018-02-16 17:23:28 we need gcc6's gcc-java to build opendjk7 so we can build openjdk8 2018-02-16 17:23:38 what a mess 2018-02-16 17:23:38 Shiz: yes, there is 2018-02-16 17:23:53 Shiz: someone just needs to do the work (someone who cares about gcc7) 2018-02-16 17:24:04 i do not care to compile my kernel with even more patches that will slow it down =) 2018-02-16 17:24:10 i wonder if we can skip gcc7 and just jump to gcc8 2018-02-16 17:24:17 that's a boldly ignorant statement 2018-02-16 17:24:19 danger 2018-02-16 17:24:24 gcc8 has a lot of bugs 2018-02-16 17:24:27 we looked at that for adelie 2018-02-16 17:24:36 I'm compiling a 7.3 port right now 2018-02-16 17:24:51 taking forever because 2 cores though 2018-02-16 17:25:29 ncopa: I don't think it wise to continue to rely on deprecated gcj 2018-02-16 17:25:57 i think we could cp -r main/gcc main/gcc6 and change pkgname to gcc6 2018-02-16 17:26:18 Shiz: we don't rely on gcj 2018-02-16 17:26:27 Shiz: we just need gcj to bootstrap java 2018-02-16 17:26:34 so we do rely on gcj 2018-02-16 17:26:46 Shiz: when something else than gcj comes along we will be sure to switch :P 2018-02-16 17:27:16 this sounds strange - why is there a dependency between gcj and openjdk? 2018-02-16 17:27:22 you see all these programming languages depend on themselves to bootstrap 2018-02-16 17:27:24 it is really great 2018-02-16 17:27:51 But you could just download a compiled version of openjdk to build openjdk on alpine. 2018-02-16 17:28:19 It seems openjdk9 is integrated like that into the alpine docker container 2018-02-16 17:28:24 yes, we rely on gcj to bootstrap java 2018-02-16 17:28:56 nope 2018-02-16 17:28:57 that is a policy violation 2018-02-16 17:29:00 see also: reflections on trusting trust 2018-02-16 17:29:06 the precompiled openjdk does not just run on alpine 2018-02-16 17:29:09 openjdk9 is a different creature 2018-02-16 17:29:16 in openjdk9 case, we use openjdk8, which uses openjdk7 2018-02-16 17:29:21 look java is a nightmare 2018-02-16 17:29:49 more news at 11 2018-02-16 17:29:50 go complain to these java people about bootstrapping :D 2018-02-16 17:29:51 we have similar problem with rust 2018-02-16 17:29:54 in meantime we will have to deal with what we have to deal with 2018-02-16 17:30:57 anyway gcc8 is not stable yet 2018-02-16 17:30:58 making a language easy to boostrap is so 1980 2018-02-16 17:32:22 so i strongly suggest to use gcc 7.3 instead 2018-02-16 17:32:52 but i prefer to keep gcc6 as system compiler still, because even gcc 7 has regressions 2018-02-16 17:42:13 I don't 2018-02-16 17:42:30 unless we backport the retpoline patches 2018-02-16 17:44:26 you can compile your kernel with gcc7 2018-02-16 17:44:48 (actually i would like to see performance hit of retpoline before we just go whole hog on this stuff) 2018-02-16 17:44:59 (because KPTI was pretty brutal) 2018-02-16 17:45:15 notably, if the performance hit is bad, i would like to be able to turn retpoline off at runtime 2018-02-16 17:45:25 because not all workloads require KPTI or retpoline mitigations 2018-02-16 17:45:35 it's not just my kernel, but alpine's 2018-02-16 17:45:50 retpoline's impact is fairly minimal iirc 2018-02-16 17:45:58 not nearly as bad as initial kpti 2018-02-16 17:46:07 well, show us the numbers 2018-02-16 17:46:09 they also do some funky stuff with stack depth tracing to minimize impact further 2018-02-16 17:46:09 because KPTI is brutal 2018-02-16 17:46:20 well, performance is not my argument to make 2018-02-16 17:46:26 I'd even take KPTI if it was needed 2018-02-16 17:46:31 security > moar corez 2018-02-16 17:47:23 *you* would, but some of us actually owuld like git to not take 3x as long to do things in the aports.git tree 2018-02-16 17:47:35 :) 2018-02-16 17:47:46 at least with PTI you can turn it off 2018-02-16 17:49:01 well, that seems like a clear misalignment of project goals then :) 2018-02-16 17:49:15 lets also remember that the 4.9 "KPTI" was a rushed KAISER-derived hack job 2018-02-16 17:49:24 so i mean, realistically, i think we need to do a lot of load testing on these patches 2018-02-16 17:49:27 before we just push them out 2018-02-16 17:49:41 well nobody ever said 4.9 kpti was sufficient or capable 2018-02-16 17:49:44 the focus was always on 4.14 and 4.15 2018-02-16 17:49:50 a mitigation that makes a system completely unreliable is worse than having no mitigation 2018-02-16 17:49:56 4.9 is a half-done hackjob 2018-02-16 17:50:01 even torvalds said so 2018-02-16 17:51:09 I just try to compile opendjk7 (on archlinux) with gcc 7.2.1. But it seems to use "itself" (openjdk) to compile. 2018-02-16 17:51:15 does this mean that your goal is to push patches that make systems unreliable ? 2018-02-16 17:51:33 i mean, you agree that reliability is as important as security right 2018-02-16 17:51:59 I'm not sure what would possibly would get you to make that inference but I suggest you stop ding it 2018-02-16 17:52:15 no need to make unbased accusations 2018-02-16 17:52:17 are you guys all right? you're bickering like an old married couple 2018-02-16 17:52:42 ideally we want both 2018-02-16 17:52:48 and i think we should prove that these very intrusive changes do not have reliability impact 2018-02-16 17:52:53 because the reliability impact is why we are backporting 4.14 to old releases 2018-02-16 17:52:59 we're lucky "spectre" and "meltdown" haven't been weaponized (a lot) yet 2018-02-16 17:53:01 we had more than a month to do it 2018-02-16 17:53:04 BernhardG: yes, and if "itself" is not available yet, you have to use gcj 2018-02-16 17:53:05 where are the numbers? 2018-02-16 17:53:09 and since alpine bootstraps itself from scratch for every release 2018-02-16 17:53:13 this means there is a point in the release where gcj is not yet available 2018-02-16 17:53:44 kaniini: but this is not solvable in the future (as gcj is almost dead) 2018-02-16 17:53:47 kaniini: btw I t hink we should backport 4.15 rather than 4.14 2018-02-16 17:53:55 it has a more complete mitigation 2018-02-16 17:54:26 either way the 4.9 backport (what you refer to as KPTI) is not really at all related to 4.14 and 4.15 2018-02-16 17:54:29 4.14 is LTS, 4.15 is not. does that make a difference for Alpine? 2018-02-16 17:54:49 it was a hackjob done out of necessity for some vendors, doesn't carry at all the same codebase as the 4.14/4.15 mitigation 2018-02-16 17:54:54 Shiz: 4.15 hasn't gone 'stable' yet has it 2018-02-16 17:54:57 we want the tree that is most likely to gain LTS 2018-02-16 17:54:59 yes it has 2018-02-16 17:55:11 4.15.3 is stable on kernel.org 2018-02-16 17:55:14 4.15.3 is current stable 2018-02-16 17:55:21 latest lts is 4.14.19 2018-02-16 17:55:23 but yeah 4.15 won't be LTS, 4.14 will be 2018-02-16 17:55:26 or is, rather 2018-02-16 17:55:31 yes, it makes a difference 2018-02-16 17:55:32 next LTS is like 4.19 or thereabouts 2018-02-16 17:56:06 the [people who maintain alpine kernels] prefer to use LTS tree 2018-02-16 17:56:17 but 4.14 has gone LTS 2018-02-16 17:56:24 afaik only 4.15 has the retpoline mitigtation which helps perf greatly 2018-02-16 17:56:28 yeah i understand 2018-02-16 17:56:57 anyway, i am fine with retpoline but i want to load test it before we even consider backporting it 2018-02-16 17:57:08 the 4.9 "KPTI" left a bad taste 2018-02-16 17:57:21 i mean, i think we both agree that a secure kernel that is unstable under load is not very useful 2018-02-16 17:57:33 i would hope so anyway 2018-02-16 17:58:13 but this raises the question of 4.14 vs 4.15 2018-02-16 17:58:28 yes 2018-02-16 17:58:53 will 4.15 be around a year from now ? 2018-02-16 17:59:04 # gcc --version 2018-02-16 17:59:05 gcc (Alpine 7.3.0) 7.3.0 2018-02-16 17:59:07 :) 2018-02-16 17:59:08 are we sure about that 2018-02-16 17:59:13 kaniini: I can prepare you a retpolined kernel for load testing 2018-02-16 17:59:15 if you desire 2018-02-16 17:59:36 Shiz: there's another reason why we want to keep gcc6 as main compiler 2018-02-16 17:59:56 gcc7 in our testing (in adelie) used 2x the ram 2018-02-16 18:00:00 like the ram increase is brutal 2018-02-16 18:00:06 i'm not sure what they did but it is using a lot more ram now 2018-02-16 18:00:42 so that makes me really nervous about armhf for example 2018-02-16 18:00:46 where we have like 4GB ram max 2018-02-16 18:00:58 mhm 2018-02-16 18:01:01 is that actual ram or virt 2018-02-16 18:01:35 i realise it doesn't make a diff for a 32-bit addr space 2018-02-16 18:01:37 but just curiosity 2018-02-16 18:03:00 need to check again 2018-02-16 18:03:02 maybe next week 2018-02-16 18:03:36 compiling a retpolined 4.15.3 with copperhead -hardened patches right now 2018-02-16 18:07:02 note we still need to sort gcc6 for java 2018-02-16 18:07:23 gcc 7.3 is probably ok to go to for system compiler if we really must 2018-02-16 18:07:37 jumping to gcc 8 is something i am definitely not in favor of right now 2018-02-16 18:07:50 note adelie will have upstream-freeze soon, so would prefer to sort gcc prior to that 2018-02-16 18:09:01 Shiz, actual RAM 2018-02-16 18:09:23 ARM will never have KDE if gcc7 is used for system compiler. gcc6 needs 3.3 GB to compile required geometry_parser module 2018-02-16 18:09:36 Neither will x86 or any other 32-bit platform 2018-02-16 18:10:31 I agree with not going for gcc8 2018-02-16 18:10:33 yes, will literally run out of address space 2018-02-16 18:10:54 ...swap? 2018-02-16 18:11:03 https://bts.adelielinux.org/show_bug.cgi?id=47 2018-02-16 18:11:04 oh yeah, address space 2018-02-16 18:11:13 Shiz, swap doesn't get around the limits of 32-bit address space 2018-02-16 18:11:13 the problem isn't physical ram, it's running out of address space 2018-02-16 18:11:14 that concerns us 2018-02-16 18:11:41 fwiw bts.adelie is not loading 2018-02-16 18:11:45 Shiz, I'm already having to do terrible hacks just to get llvm to build on x86 because of the address space limitation. gcc7 would be the end of it 2018-02-16 18:12:29 well you can't be stuck on 6 forever either way :/ 2018-02-16 18:12:58 kaniini, is there a reason bts. and wiki. are only accessible in US? Haha 2018-02-16 18:13:15 in adelie, we plan to keep gcc6 regardless just for KDE 2018-02-16 18:13:21 ah bts loaded 2018-02-16 18:13:27 it just took... a long time 2018-02-16 18:13:45 and use gcc7 for everything else 2018-02-16 18:13:51 but 2018-02-16 18:15:02 https://phabricator.kde.org/D10118 2018-02-16 18:15:13 kaniini, and llvm? and boost? and... 2018-02-16 18:15:31 yes, it's a mess 2018-02-16 18:15:36 No, our plan is to keep 6 until GCC fixes this bug of using so much RAM (apparently on glibc systems it uses > 16 GB! We're lucky we use musl and it is only 4.) or until clang is suitable as system compiler 2018-02-16 18:16:07 yes i agree 2018-02-16 18:16:07 Since 8 has so many bugs I haven't really profiled it to see if it fixes this RAM stuff 2018-02-16 18:16:10 # # the default maximum template expansion depth (256) is not enough 2018-02-16 18:16:11 i would prefer to see clang as default cmpiler 2018-02-16 18:16:12 # set_property(SOURCE preview/geometry_parser.cpp APPEND_STRING PROPERTY COMPILE_FLAGS " -ftemplate-depth=512") 2018-02-16 18:16:14 \kde/ 2018-02-16 18:16:20 Hopefully they fix more of the bugs 2018-02-16 18:16:30 compiler* 2018-02-16 18:17:03 Shiz, it's Boost::Qi 2018-02-16 18:17:07 That's how Boost::Qi works 2018-02-16 18:17:34 anyway we are stuck with gcc6 on adelie for now. i guess clang will come later, and maybe gcc7 for kernel only. 2018-02-16 18:17:50 (what the fuck is 'keyboard geometry' anyway) 2018-02-16 18:17:59 https://cgit.kde.org/plasma-desktop.git/tree/kcms/keyboard/preview/geometry_parser.cpp#n52 2018-02-16 18:18:28 kaniini, as you change keyboard layouts in the KDE Keyboard control panel, it shows you what every key on a keyboard will do 2018-02-16 18:19:34 i.e. switching between $ and Euro symbol for shift+4 2018-02-16 18:19:35 It's virtual key caps 2018-02-16 18:20:41 ... why does this need Boost::Qi 2018-02-16 18:21:04 https://i.imgur.com/xvjCCwe.png 2018-02-16 18:21:37 It doesn't, they're rewriting it without Boost::Qi for some future version. 2018-02-16 18:22:00 :D 2018-02-16 18:23:09 time t o reboot for anew kernel 2018-02-16 18:25:05 I always read about adelie - what it that? 2018-02-16 18:27:18 BernhardG: a fork of Alpine focused on desktop usage and POSIX conformance 2018-02-16 18:28:30 sounds quite nice. But it also sounds hard to get some applications ported to musl. 2018-02-16 18:31:44 back on 4.15.3 :) 2018-02-16 18:32:36 Before Adélie I was a FreeBSD developer, and before that I was a Fedora "documentation engineer" (fancy term for technical writer), and before that I was doing my own kernel 2018-02-16 18:32:37 This is nothing to me haha 2018-02-16 18:33:01 Also, because of all the work I did in the past, I'm familiar with the fact that different communities have different needs for contributions, so I'm able to get stuff upstreamed easier because that's just what I've always done 2018-02-16 18:33:51 https://up.shiz.me/NTNkNDll.png 2018-02-16 18:34:04 The hardest part was KDE, and that was only 8 or 9 patches for the entire framework set and desktop packages. 2018-02-16 18:34:33 AWilcox[m]: so you are the man if one needs to package a (complex) package for alpine? It might happen that I need ceph. My plan was to use it as docker container but I fear I still need the client libraries. 2018-02-16 18:37:25 would probably be a better idea to make a b.a.o issue for it 2018-02-16 18:38:46 danieli: the package exists already in testing - for an old version. I already have started with a new version but I am not a C developer and therefore I might not be able to finish this. 2018-02-16 18:42:03 I'm actually not a man 2018-02-16 18:42:20 And I don't really have time right now to deal with that, there's a Plasma version bump which means there's about 130 packages for meto update... 2018-02-16 18:42:45 For me to update* 2018-02-16 18:46:05 AWilcox[m]: for sure. have a lot of fun. 2018-02-16 19:05:48 looks like 4.14.14 may do retpoline 2018-02-16 19:43:39 kaniini: little late to the party, but yeah it's close. iirc we're only missing the libffi patch and linux-vanilla for octeon before it's bootstrappable 2018-02-16 19:44:55 kernel configs aren't exactly my forté, so I never got around to making a linux-vanilla config for octeon 2018-02-16 19:45:54 I've simply copied the config from xypron's repo and used that in my builds 2018-02-16 19:59:31 late response, I think ncopa's suggestion cp -r main/gcc main/gcc6 is a good idea. 2018-02-16 20:12:04 until there's another way to bootstrap openjdk, we still need gcc6 in the corner. 2018-02-16 20:13:19 well we just keep gcc6 there, just for the sake of bootstrapping openjdk, nothing else. other work are for gcc7+. 2018-02-16 20:21:24 what is up with: ERROR: libpthread-stubs-0.3-r5: package mentioned in index not found (try 'apk update') ? 2018-02-16 20:29:40 can someone tell me what the `A-Improve` label in aports means? 2018-02-16 20:30:38 <_ikke_> mmlb: it means that something in the PR needs to be improved 2018-02-16 20:47:56 my chroot program seems broken 2018-02-16 20:48:25 the symlink that is 2018-02-16 20:48:51 i have to manually type /usr/bin/coreutils --coreutils-prog=chroot to get it to work 2018-02-16 20:49:35 Did you try something like this (inside chroot): "export PATH=/usr/bin:$PATH" 2018-02-16 20:56:15 thanks _ikke_ I don't have any further feedback though 2018-02-16 20:56:26 https://github.com/alpinelinux/aports/pull/3252 is the pr 2018-02-16 20:57:20 re-enabling NFP driver that was probably mistakenly dropped from config 2018-02-16 21:00:50 mmlb: I only know travis from own projects. But for this case (starvation, cancellation, ...) my developers always push 1 byte changes to work around the problem. 2018-02-16 21:01:25 I don't seems like all the kernel builds are timing out though 2018-02-16 21:01:52 I've pushed a commit since first bumping the rev to r1 and same deal... :( 2018-02-16 21:05:15 i fixed my libpthread-stubs problem but the chroot thing still bugs me 2018-02-16 21:05:27 it was slow mirror server. 2018-02-16 21:06:49 i did the export thing and it doesn't work 2018-02-16 21:08:24 let me check that for you. So you run a alpine host and have an alpine chroot (http://dl-cdn.alpinelinux.org/alpine/v3.7/releases/x86_64/alpine-minirootfs-3.7.0-x86_64.tar.gz) in it? 2018-02-16 21:12:44 @koldbrutality: on my system the symlink to chroot is wrong (dangling) in /usr/sbin/chroot -> ../usr/bin/coreutils (but it must be ../bin/coreutils) 2018-02-16 21:13:01 i have alpine host but gentoo chroot but the alpine host has the broken chroot cmd 2018-02-16 21:13:10 <_ikke_> BernhardG: You know you can just amend the last commit to push again, right? 2018-02-16 21:13:31 koldbrutality: seems to be a bug in coreutils then 2018-02-16 21:14:25 _ikke_: but that does not change a actual file. 2018-02-16 21:15:05 <_ikke_> BernhardG: but travis is triggered again 2018-02-16 21:15:12 ls /usr/sbin/chroot -al reported: /usr/sbin/chroot -> ../usr/bin/coreutils 2018-02-16 21:15:40 yeah - that wrong - it must be ../bin/coreutils 2018-02-16 21:15:48 I will generate a bug report for it. 2018-02-16 21:16:10 amend is what I just did, waiting on build now 2018-02-16 21:18:39 koldbrutality: #8495 is the issue about that 2018-02-16 21:19:53 has anyone discussed a different ci system in addition to / replacement of travis? I might be able to get work to supply a baremetal_0 and maybe a 2a too @ packet.net 2018-02-16 21:21:30 i fixed it 2018-02-16 21:22:18 sorry about that :) 2018-02-16 21:23:08 mmlb: it will be incorporated into next kernel 2018-02-16 21:23:30 <_ikke_> nmeum: would you be able to provide feedback on https://github.com/alpinelinux/aports/pull/3252 why you added the improve label? 2018-02-16 21:24:10 kaniini? 2018-02-16 21:25:31 mmlb: the netronome config change will be incorporated into next kernel package release 2018-02-16 21:25:52 do you mean upcoming 4.15? 2018-02-16 21:26:01 oh but then why hasn't the PR been merged? 2018-02-16 21:28:40 it will be when next kernel package is done 2018-02-16 21:29:27 koldbrutality: you can btw. fix that chroot thing by yourself with "ln -sf ../bin/coreutils /usr/sbin/chroot" 2018-02-16 21:29:37 kaniini also is there an ETA on that? I've got other things that depend on it and it'd be nice if I can just make use of the package and not have to build / store myself. 2018-02-16 21:31:13 it works thx 2018-02-16 21:31:49 or 2018-02-16 21:31:52 you could just upgrade 2018-02-16 21:31:53 to coreutils 8.29-r2 2018-02-16 21:32:12 kaniini: it is not yet present on (at least mine) mirror. 2018-02-16 21:32:32 dl-cdn has it 2018-02-16 21:32:33 =) 2018-02-16 21:32:43 kaniini: many thanks for your really fast fix. 2018-02-17 00:05:59 _ikke_: didn't look at it yet as I am currently on my phone but it might be the case that I added the label by accident as I mostly add labels in bulk 2018-02-17 00:07:41 so if the label is wrong just go ahead and change it ;) 2018-02-17 01:34:17 screenfetch seems like it doesn't work 2018-02-17 01:35:10 nm 2018-02-17 01:35:36 it does wierd stuff. 2018-02-17 01:36:49 as in spam pgrep: unrecognized option: U 2018-02-17 01:54:17 koldbrutality: apk add procps 2018-02-17 01:54:27 BusyBox pgrep doesn't support -U, procps pgrep does 2018-02-17 07:58:46 <_ikke_> nmeum: I don't have the rights to do that 2018-02-17 16:39:14 _ikke_: which label would you want to use? A-fix? 2018-02-17 16:52:25 <_ikke_> nmeum: You added it because of the failing travis build? 2018-02-17 17:07:26 is there a way to find all packages that depend on another package even those not installed? 2018-02-17 17:08:03 _ikke_: huh? no, I added the A-improve label to indicate that this GitHub PR improves the main/linux-vanilla aport 2018-02-17 17:08:24 koldbrutality: look on pkgs.a.o? pretty sure it's listed there 2018-02-17 17:09:07 where is that? 2018-02-17 17:12:10 e.g. https://pkgs.alpinelinux.org/package/edge/main/x86_64/flac 2018-02-17 17:12:19 dependents listed under 'required by' 2018-02-17 17:14:08 ahh thx 2018-02-17 17:14:34 np 2018-02-17 17:52:45 clandmeter: ncopa: kill that issue ^ 2018-02-17 17:54:20 done thx. 2018-02-17 20:37:14 <_ikke_> nmeum: I had the idea that label meant soemthing else 2018-02-17 21:30:58 oh yeah... got qt5-webengine working and qutebrowser working 2018-02-17 21:32:26 i will make a pull request but still need to sort out the py3-qt5 subpackage problem because it will pull qt5-webkit and qt5-webengine. last two should be optional dependencies. 2018-02-18 01:14:41 anyone here using older ATI? 2018-02-18 01:19:33 Lochnair: I've been to those pages millions of time and never looked on the right at "Required by" and such. Thanks! 2018-02-18 01:57:12 I don't understand why CI test failed. Can someone see the log? https://github.com/alpinelinux/aports/pull/3338 2018-02-18 02:04:15 first thing i see is a broken repo 2018-02-18 02:04:22 but they're just warnings 2018-02-18 02:04:39 oh uh, it might depend on a package that isn't yet in aports? 2018-02-18 02:05:57 looks like the version of qt5-qtwebchannel-dev in edge is 5.9.3-r0 2018-02-18 02:07:22 i wish apk was more verbose in terms of broken dependencies in virtual packages 2018-02-18 02:13:50 ahh 2018-02-18 02:16:32 right... i was updating that 2018-02-18 02:56:32 Define "older ATI" 2018-02-18 02:56:58 I have a Radeon 9600XT in a PowerBook G4, and a 5750HD in a dual-core workstation. 2018-02-18 03:07:22 pre amdgpu driver 2018-02-18 03:08:18 or the one that uses xf86-video-ati 2018-02-18 03:08:43 Both of those match that. 2018-02-18 03:58:23 i'm getting a segfault: cool-retro-term[28479]: segfault at 7ff9c64577f8 ip 00007ff9c9d25b48 sp 00007ff9c64577f0 error 7 in r600_dri.so[7ff9c9a9d000+a48000] 2018-02-18 03:58:46 i should just release this with software rendering enabled by default 2018-02-18 18:53:41 where can i find the source code for default_doc and default_dev ? 2018-02-18 18:54:15 <_ikke_> 1https://git.alpinelinux.org/cgit/abuild/tree/abuild.in#n1547 2018-02-18 18:54:22 <_ikke_> https://git.alpinelinux.org/cgit/abuild/tree/abuild.in#n1633 2018-02-19 01:29:37 there is no recursive install option? 2018-02-19 01:29:55 for the install cmd? 2018-02-19 05:32:08 <_ikke_> koldbrutality: you mean busybox install? 2018-02-19 05:32:19 yeah 2018-02-19 05:33:18 <_ikke_> What recursive option? 2018-02-19 05:34:10 yeah 2018-02-19 05:34:33 <_ikke_> ? 2018-02-19 05:34:50 instead of: mv html dest 2018-02-19 05:35:53 html is a directory tree 2018-02-19 05:36:00 with subfolders 2018-02-19 05:37:28 <_ikke_> No, I don't think so 2018-02-19 05:37:36 <_ikke_> install works on files, not complete directories 2018-02-19 05:42:40 i tried to use find but it moved everything into only one folder 2018-02-19 05:43:05 <_ikke_> why not cp -r? 2018-02-19 05:43:29 i just want to use install command only... nm 2018-02-19 05:43:55 <_ikke_> then you have to be very explicit 2018-02-19 05:44:06 <_ikke_> create each dir, install files into that dr 2018-02-19 05:44:08 <_ikke_> dir 2018-02-19 10:02:14 why does subpackage="$pkgname-dev" need to be explicitly called? 2018-02-19 10:03:33 would break packages that are headers-only i guess 2018-02-19 12:54:59 Natanael Copa: what do you think about adding netboot to official repos? 2018-02-19 13:04:28 sounds like something we should have done ages ago 2018-02-19 13:07:45 story of our lives :) 2018-02-19 13:08:22 :) 2018-02-19 13:08:58 i wonder how we should add them 2018-02-19 13:09:11 should we only include the latest release? 2018-02-19 15:50:11 is there a specific reason we are still using gzip compression on initramfs? 2018-02-19 15:51:16 fabled: ^ 2018-02-19 16:20:59 clandmeter, dunno. i think it's just how it was setup and no one has seen reasons to change it 2018-02-19 16:21:10 i know xz etc are slower/more ram consuming 2018-02-19 16:21:20 i remember we did have some discussion about it earlier 2018-02-19 16:21:45 yes, but for network boot xz could be interesting. 2018-02-19 16:22:40 so i think adding this option to mkinitfs could be interesting. 2018-02-19 16:22:43 i think we have several options enabled so other compression methods could be used 2018-02-19 16:22:53 yeah, 1st step would be to add an option to change it 2018-02-19 19:05:29 I think the /boot/boot symlink created by mkinitfs needs to point at ".", not "/". Otherwise it is incorrect in the case of no separate boot partition. 2018-02-19 19:06:21 teiresias: i think i saw a patch on the mailing list yesterday 2018-02-19 19:06:26 for exactly that issue 2018-02-19 19:06:55 Yeah that was me, to alpine-aports. 2018-02-19 19:07:23 I apparently flubbed the committer info; wonder if I shouldn't resend that. 2018-02-19 20:28:41 can anyone check/accept that https://github.com/alpinelinux/aports/pull/3359 2018-02-19 20:58:46 andypost: looks gode, merged 2018-02-19 20:58:47 thanks! 2018-02-19 21:23:13 hi, I use the alpine-make-vm-image script from https://github.com/alpinelinux/aports/pull/3322 and I think I have found a bug. the script itself supports ext4, xfs and btrfs. In my own tests I've found out that an xfs image does not boot. 2018-02-19 21:24:45 I've now changed the script in a way that it creates a partition table and one large partition. after that change xfs boots. do you think this is indeed needed and should I file a bug? 2018-02-19 21:25:01 correct link https://github.com/alpinelinux/alpine-make-vm-image 2018-02-19 21:25:47 <_ikke_> You can always file a bug if it does not work 2018-02-19 21:28:03 I will file a bug for it. 2018-02-19 21:33:42 done. it took a while to understand that xfs can't boot if there is no partition table. 2018-02-19 22:54:58 have to explicitly call $pkgname-doc to package documents :'( 2018-02-19 22:57:18 koldbrutality: if you have several hundred instances of the same alpine image running, you will be happy about the fact that you can install stuff without manpages on alpine ^ 2018-02-19 22:57:57 the other package manager does stuff automatically 2018-02-19 22:58:14 i'm trying to learn this one but has different personality 2018-02-19 22:59:50 when you say default to me it implies automatically done but it doesn't do it in this system 2018-02-19 23:37:33 last night I talked about booting to f2fs root partition, which didn't worked making initramfs 2018-02-19 23:38:26 solved by adding fscryto module in /etc/mkinitfs/features.d/f2fs.modules 2018-02-19 23:39:10 i.e. adding line 'kernel/fs/crypto/fscrypto' in that file 2018-02-19 23:40:12 looking into /etc/mkinitfs/features.d/ext4.modules I see there are crc32 modules 2018-02-19 23:41:28 question is: should these crc32 modules be added also to the /etc/mkinitfs/features.d/f2fs.modules 2018-02-19 23:43:14 another question: shouldn't /etc/mkinitfs/features.d/f2fs.modules be fixed because this looks like a bug, for me at least 2018-02-19 23:45:47 File a bug if it won't boot without your addition. I did the same for crc32 in ext4 which was fixed 2018-02-19 23:45:53 or file a PR that makes the change directly 2018-02-19 23:47:39 dehoptu[m]: I'm not sure how to file a bug (yet) in Alpine and I don't have github account 2018-02-19 23:49:25 dehoptu[m]: but, maybe I can look tomorow to bugs.a.o to see how to fil a bug 2018-02-20 00:36:32 hmm 2018-02-20 00:36:34 on v3.7: 2018-02-20 00:36:36 immunity:~# clang++ 2018-02-20 00:36:38 Error relocating /usr/bin/clang++: _ZSt11__once_call: symbol not found 2018-02-20 00:36:40 Error relocating /usr/bin/clang++: _ZSt15__once_callable: symbol not found 2018-02-20 00:36:42 this seems wrong 2018-02-20 02:06:06 anyone know about running tests in emacs? 2018-02-20 02:08:40 nm the package has a Makefile rule 2018-02-20 02:25:13 this is lame... too many check dependencies 2018-02-20 02:25:41 i want to work on creating new packages not testing them 2018-02-20 13:49:47 Currently we call the bootloader before install necessary packages : https://git.alpinelinux.org/cgit/alpine-conf/tree/setup-disk.in#n459 and #n485. But for s390x, I need to install the kernel in the target device before running the bootloader, as it requires that way. Is it strange or wrong to do so ? 2018-02-20 13:50:02 apparently it works without a problem, but I just want to make sure. 2018-02-20 14:36:09 tmh1999: i think the idea of running setup_syslinux before installing packagages is that we set up the update-syslinux.conf before we install the packages 2018-02-20 14:36:41 that way the trigger script for syslinux will create the boot config properly 2018-02-20 14:36:57 im not sure we have a trigger script for grub 2018-02-20 14:37:24 ncopa: agreed. setup_syslinux only install the config files. but for the case of s390x, the bootloader requires the kernel to be present on /mnt/boot (aka target device'a /boot) 2018-02-20 14:37:43 do you need re-run the bootloader every time kernel is updated? 2018-02-20 14:37:44 I am thinking about shipping vmlinuz and initramfs inside the iso 2018-02-20 14:38:05 I have not checked that. 2018-02-20 14:38:10 can s390x boot from iso images? 2018-02-20 14:38:23 tmh1999: just for clarification, i though the kernel is always installed first and then triggers the extlinux install? 2018-02-20 14:38:24 other distro can 2018-02-20 14:38:31 *thought 2018-02-20 14:39:05 liwakura: that is correct 2018-02-20 14:39:12 ncopa : some setup just uses the kenrel + initramfs . some use the iso( which also contains the kernel + initramfs) 2018-02-20 14:39:51 tmh1999: i think we need to run bootloader install from triggerscript 2018-02-20 14:40:21 what triggerscript ? 2018-02-20 14:40:25 ncopa: ^ 2018-02-20 14:40:25 lets say we have 2 different kernels, linux-hardened and linux-vanilla, that both works on s390x 2018-02-20 14:40:32 and a user want replace linux-vanilla with linux-hardened 2018-02-20 14:40:53 then we need to re-run the bootloader install, right? 2018-02-20 14:41:11 probably yes, I haven't checked. 2018-02-20 14:41:18 oh right 2018-02-20 14:41:21 the update-extlinux script is run when any package modifies /boot/* 2018-02-20 14:41:37 trigger in the kernel's after-install / after upgrade script ? 2018-02-20 14:41:44 okay 2018-02-20 14:41:57 I think I understand 2018-02-20 14:42:03 https://git.alpinelinux.org/cgit/aports/tree/main/syslinux/syslinux.trigger 2018-02-20 14:42:08 yes 2018-02-20 14:42:36 ncopa: where is that called from? hardcoded into apk? 2018-02-20 14:42:46 okay cool thanks ncopa. I have been litterally waiting for 3 months for politics to settle down how I can get a test server ... 2018-02-20 14:42:47 and this: https://git.alpinelinux.org/cgit/aports/tree/main/syslinux/APKBUILD#n12 2018-02-20 14:42:59 ah i see 2018-02-20 14:43:18 ouch... 2018-02-20 14:44:02 i wish i had access to an IBM zSeries 2018-02-20 14:44:17 tmh1999: i wonder if you could report the fftw issue upstream 2018-02-20 14:44:21 there are more packages that fails now due to lacking fftw 2018-02-20 14:44:32 ncopa: also re: main/liboil, I reported upstream, but they are kind of inactive. main/audit and main/fftw : sometimes I build good, sometimes it fails, either container or KVM. So I guess we !check for these 2. I didn't know fftw so I disabled it all they way ... 2018-02-20 14:45:09 ncopa: it's all unstable between containers env... this is what we've been having for a while. I should've just !check 2018-02-20 14:45:16 liwakura: https://developer.ibm.com/linuxone/resources/faq/ 2018-02-20 14:45:38 liwakura : if you need Linux env, checkout LinuxONE Community Cloud. they're giving for free. 2018-02-20 14:46:14 liwakura: If you need lower than Linux, it's expensive. kaniini once wanted to buy one but they quoted him too much. \o/ 2018-02-20 14:46:16 i think its free for 120 days or so 2018-02-20 14:46:23 ncopa: !check works for you ? 2018-02-20 14:46:25 interesting 2018-02-20 14:47:00 tmh1999: i assume !check works for me, but i think those may be real bugs 2018-02-20 14:47:34 i'd like to investigate if it is real bug or not 2018-02-20 14:47:35 i had a look at audit 2018-02-20 14:47:47 ncopa : I totally agree. but testing in real env is better than dangling in container, right ? I am so behind the schedule of not having a server since November... 2018-02-20 14:47:57 and it looks to me like there is a real bug there if /tmp filesystem does not support fallocate(2) 2018-02-20 14:48:07 okay 2018-02-20 14:48:47 i suspect that glibc workarounds fallocate(2) and simlates it 2018-02-20 14:49:27 tmh1999: let me see if i can give you a lxc here 2018-02-20 14:49:45 ncopa : that's even better. my dev env is way different from yours. 2018-02-20 15:02:38 tmh1999: this is your ssh keys? https://github.com/tmh1999.keys 2018-02-20 15:03:33 ncopa: just the first one, ignore the 2nd 2018-02-20 15:04:27 tmh1999: i sent you a PM 2018-02-20 15:04:40 not sure if matrix will allow me to PM you unless you have a registered nick 2018-02-20 15:04:59 ncopa : aw I don't have matrix account. 2018-02-20 15:05:20 nope I can't talk to you nor receiving any pm 2018-02-20 15:05:39 how about drop me an email ? 2018-02-20 15:06:00 I thought matrix.alpinelinux.org are for core/main dev 2018-02-20 15:07:00 ncopa : gotcha 2018-02-20 15:09:13 thats what i told you in PM :) 2018-02-20 15:09:19 i have sent an email to you 2018-02-20 15:09:29 tmh1999: i think it would be good for you to register your nick 2018-02-20 15:09:38 https://freenode.net/kb/answer/registration 2018-02-20 15:09:43 we have a bridge to IRC 2018-02-20 15:10:15 i am resgisterd on freenode/irc, but not matrix 2018-02-20 15:22:14 ah ok 2018-02-20 15:23:00 if a package uses multiple implementations of ruby or python, do we need to run test for check() on each implementation? if a test suite only works on a particular version of python but the library can be used in multiple implementations, do we need to make a note of it not tested on other implemementations? 2018-02-20 15:23:40 define implementation 2018-02-20 15:24:34 i am talking about different syntax 2018-02-20 15:25:04 python2 is slightly different than python3 2018-02-20 15:27:14 or the function signatures/API calls differ on each version of those releases 2018-02-20 15:29:34 koldbrutality: i am ok if you only check on python3, but dont mind if you also test python2 2018-02-20 15:29:49 the other devs may have different opinion 2018-02-20 15:30:23 bah, lots of CVEs to handle 2018-02-20 15:30:29 we really need that security WG up 2018-02-20 15:31:26 its not more than its always been. we are just more visible about it with the redmine->irc 2018-02-20 15:31:33 but yeah... 2018-02-20 15:31:34 <_ikke_> 2 CVE's against several releases 2018-02-20 15:32:55 yes 2018-02-20 15:33:08 we need to fix it in every relevant git branch 2018-02-20 15:33:37 and we should not forget any branch 2018-02-20 15:35:28 a killer feature for a bugtracker: make it possible to mark which git branches the issue/bug affects 2018-02-20 15:35:55 when you git push a commit with "fixes #" in commit message, it should mark that the issue is fixed for that specific git branch 2018-02-20 15:35:58 when all git branches are fixed, the issue is closed 2018-02-20 15:39:38 it really isn't more, but it's still something that has to be done 2018-02-20 15:39:49 ncopa: shouldn't be too hard 2018-02-20 15:40:08 <_ikke_> ncopa: redmine allows custom fields 2018-02-20 15:40:49 <_ikke_> The latter part is more difficult though (requires support from the scm plugin) 2018-02-20 15:46:53 hello from matrix 2018-02-20 15:47:28 sorry for the noise 2018-02-20 17:12:00 lol spelling mistake: ERROR: py-ycmd: Missding repository url in APKBUILD! 2018-02-20 17:12:15 what is this missding? lol 2018-02-20 18:01:31 it's a typo 2018-02-20 18:01:35 s and d are next to each other on most keyboards 2018-02-20 18:02:59 pushed fix 2018-02-20 18:03:07 thanks 2018-02-20 18:23:52 jirutka: i just switched pkgconf travis to using alpine :) 2018-02-20 18:27:02 congrats! 2018-02-20 18:44:50 hey alpine dev team, I am just starting to learn how to package software and was wondering if I wanted to include multiple files to my source variable in APKBUILD i.e. source="path/to/source/*" would that be sufficient? 2018-02-20 18:46:14 marketzero: no i dont think that will work 2018-02-20 18:47:15 if I point `source` to a directory would it build everything in the directory? 2018-02-20 18:47:33 it won't 2018-02-20 18:47:56 no 2018-02-20 18:49:58 how do you add multiple files to the source variable then? 2018-02-20 18:51:16 Typically source= is a link to a URL to download a tarball. If you have multiple patches you have to declare each one. 2018-02-20 18:53:21 I was under the assumption that APKBUILD is a set of directives to build a tarball that will become the package I am creating 2018-02-20 18:54:54 <_ikke_> yes, so the source typically contains the reference to the tarball 2018-02-20 18:55:22 <_ikke_> and eventual other relevant files (like patches and init scripts) that aren't part of the tarbal 2018-02-20 18:58:02 I guess builddir is meant for the binaries I will provide, and source is a reference to the output of the packager `abuild` 2018-02-20 18:59:21 <_ikke_> builddir is where the source is placed so that you can build 2018-02-20 18:59:27 I am new to packaging, so thank you for guiding me 2018-02-20 18:59:44 <_ikke_> pkgdir is where you place the build binaries and other files that will be part of the package 2018-02-20 19:32:33 I wonder if we should rebuild armhf for armv7? and drop armv6 support? 2018-02-20 19:32:45 it means we lose support for RPI 1 2018-02-20 19:33:34 probably more armv6 devices then that 2018-02-20 20:17:55 (we'll also lose some phones on the postmarketOS side) 2018-02-20 20:17:55 that said, we would like to have a dedicated armv7 branch... 2018-02-20 20:18:59 ncopa: Since I've seen some mistakes in kernel module packages (e.g. missing flavors), I'd like to streamline all of them and am about to do so. Is this format ok to you? https://gist.github.com/xentec/8165ef1f018717a5c77bca7b58b915e4 2018-02-20 21:02:08 ncopa: as PureTryOut writes, having armv7 side by side with armv6 would be ideal (from pmOS perspective) 2018-02-20 21:06:48 mepholic: didn't you do some work with ARMv7? Maybe talk about it now 2018-02-20 21:07:41 For me personally, I only have ARMv6 in 32-bit ARM devices. I would no longer be able to test or contribute to Alpine/ARM if ARMv6 is gone. 2018-02-20 21:08:17 on arm specifically, could we also deal with stuff like the builders having neon and that means certain libraries/executables crash as they do compile time detection of what to build 2018-02-20 21:08:21 That's not really a big loss for me as I really do not like dealing with maintaining ARM build architecture, haha 2018-02-20 21:09:02 arm in general is... annoying 2018-02-20 21:09:02 Should be able to disable NEON and such using CFLAGS 2018-02-20 21:09:10 Not a lot you can do about assembler I guess 2018-02-20 21:09:23 I don't know if as(1) has flags that can disable stuff 2018-02-20 21:09:48 yeah but the builders have it and a lot of encryption libraries do work better with neon if available 2018-02-20 21:10:02 just another fun arm wrinkle 2018-02-20 21:11:35 It should use runtime detection to be quite fiar 2018-02-20 21:11:36 Fair* 2018-02-20 21:14:32 nettle as an example doesn't do that https://www.lysator.liu.se/~nisse/nettle/ 2018-02-20 21:45:44 anyone knows where are all the .trigger scripts are stored ? mkinitfs.trigger, busybox.trigger, etc. 2018-02-20 21:46:14 they are taken care by apk-tools, aren't they ? 2018-02-20 21:46:23 I wonder if apk-tools rename them or something. 2018-02-20 21:52:03 tmh1999: /lib/apk/db/scripts.tar 2018-02-20 21:52:16 tmh1999: /lib/apk/db/triggers 2018-02-20 21:53:26 przemoc : okay cool. wow I thought they are in text. interesting. thank you ! 2018-02-20 21:54:20 they are in text, but tarred in one file. ;) 2018-02-20 21:55:19 agreed. 2018-02-20 21:56:19 I didn't expect they are in any other form thatn /path/busybox/my.trigger /path/mkinitfs/my.trigger, so couldn't find out before 2018-02-20 21:56:25 *than 2018-02-20 22:05:38 actually I never researched what was the rationale behind keeping these scripts in tar instead of simply in directory. I may have some ideas, but would prefer to know the original ones. 2018-02-20 22:06:30 fabled is not here, so maybe ncopa or kaniini can shed some light on this matter 2018-02-20 23:06:46 przemoc: resource efficiency on tmpfs 2018-02-20 23:06:49 making them separate = more inodes used 2018-02-20 23:06:54 that's why apk stuffs things in tarballs 2018-02-20 23:08:36 honestly if # of inodes used on a tmpfs becomes a limiting factor it's time to look at the bigger picture :P 2018-02-20 23:09:55 when you are running an entire OS from RAM on a system that has maybe 64-128MiB of RAM, it matters 2018-02-20 23:10:17 on modern hardware, it probably doesn't matter much, but on your 486 it does 2018-02-20 23:10:46 (if you're running from RAM anyway) 2018-02-20 23:11:33 I've run entire systems from RAM on a 486 with 32 MB of RAM, but granted, it wasn't Alpine :P 2018-02-20 23:15:53 It's silly to say that's not an issue on modern hardware. Plenty of phones only have 256 MB RAM, and some of the SoCs and IoT crap have much less. 2018-02-20 23:16:23 Resource constraints are always going to be a thing, and if you always have them in mind, it's just that much better performing on modern hardware as well (thinking primarily of the POWER9 that has an L2 cache the size of 1990s hard disks...) 2018-02-20 23:16:29 again, the limiting factor is the RAM, *not* the number of inodes 2018-02-20 23:17:05 I am *not* disputing the need to save resources 2018-02-20 23:18:03 Well, inodes on a tmpfs = RAM usage 2018-02-20 23:18:28 I believe the minimum dirent size is 4K 2018-02-20 23:18:56 200 package scripts = half a megabyte wasted 2018-02-20 23:19:31 That doesn't even count bookkeeping of the inode trees themselves 2018-02-20 23:20:52 is it decided to drop -hardened next release? I'm cleaning up kernel module packages and wonder if I should continue with *-hardened variants 2018-02-20 23:24:30 kaniini: thanks for explanation. I think it would start matter noticeably rather at bigger scale only, i.e. if there were thousands (or more) of trigger scripts (like each package having its own trigger kind of world). I doubt there is a need to have more than dozens triggers at most in any sane scenario, so I'm wondering if this additional complexity is that well justified. it's already 2018-02-20 23:24:36 available, so it's kind of non-issue perhaps, but it's always nice to keep systems/solutions as simple as possible. 2018-02-20 23:25:12 @ AWilcox[m] PureTryOut[m] 2018-02-20 23:25:17 xentec: -hardened is dead 2018-02-20 23:25:26 I have an armv7a "branch" 2018-02-20 23:25:31 most things seem to build without issue 2018-02-20 23:25:47 I'm running into an issue with lack of ram to build larger packages natively 2018-02-20 23:25:58 like gcc and llvm5 2018-02-20 23:26:10 i think boost is another 2018-02-20 23:26:18 been building on a beaglebone black 2018-02-20 23:26:22 I have a booting image 2018-02-20 23:26:25 kaniini: ok. btw is someone working on simplifying kernel module packages? 2018-02-20 23:27:30 @ mitchty ^ as well 2018-02-20 23:31:19 ncopa: i prefer to have separate armv7 sub-arch for armv7 2018-02-20 23:32:03 there is value in keeping armv6 hardware in the field working 2018-02-20 23:32:36 xentec: no 2018-02-20 23:51:42 mepholic: armv7a being armhf+neon essentially? with armhf being armv7 without neon? 2018-02-20 23:52:04 mitchty: yes, with neon 2018-02-20 23:52:36 i used optimization flags specific to the armv7a in the beaglebone black 2018-02-20 23:52:45 it's been a few months since I've worked on that project 2018-02-20 23:52:51 gotcha, i'd be all for it, as well as an armv6 but that's just me :) 2018-02-20 23:53:25 but need to get back to my cross compile stuff again, i keep hitting fun bugs getting to ghc built 2018-02-20 23:54:41 i only noticed as i ran a binary i built on a neon box and had a arm soc that had no neon support, led me down to discover feature detection isn't very common in the arm space 2018-02-20 23:55:23 i'm used to stuff like openmpi detection of cpu features etc... 2018-02-21 00:07:13 if anyone from dev team has time, please review: https://github.com/alpinelinux/aports/pull/3365 2018-02-21 04:13:48 i have a circular dependency for check() py-wsgiproxy2 is a test dependency for py-webtest. py-webtest depends on py-wsgiproxy2 for testing. 2018-02-21 04:17:03 Well, I've managed to document the changes we're still discussing on our side. https://wiki.adelielinux.org/wiki/Project:Harmony/Current_merge_list 2018-02-21 04:19:05 koldbrutality: the only way to really work around that is options="!check" for one of them. 2018-02-21 04:22:45 nm py-webtest test scripts are pulling the dependencies 2018-02-21 04:23:48 Yeah, Tox should be instructed to not do that 2018-02-21 04:24:18 That's against Alpine packaging rules, and a PR will be rejected if it does that; see jirutka's comments on some testing/ packages 2018-02-21 04:24:56 how am i going to fix this circular dependency then? 2018-02-21 04:25:04 have a seperate package? 2018-02-21 04:27:19 There is no workaround. One of the upstreams will need to change their testing to break the circular dependency. 2018-02-21 08:23:56 <_ikke_> ^ deleted 2018-02-21 10:42:19 _ikke_: did you also delete the user? 2018-02-21 10:43:55 <_ikke_> ncopa: ah, no, I didn't 2018-02-21 10:45:13 <_ikke_> gamesapps and noroothack, latest users created with the same e-mail address 2018-02-21 11:10:13 _ikke_: that exact same thing has been spammed before 2018-02-21 11:10:18 i'm tempted to reverse engineer their app and fuck them over 2018-02-21 11:15:31 hah 2018-02-21 11:15:36 >APK 2018-02-21 11:16:06 i see why they come to AL 2018-02-21 11:16:50 not android package 2018-02-21 11:16:52 :@ 2018-02-21 11:17:45 hum 2018-02-21 11:17:59 seems like 4.14.20 killed my workstation 2018-02-21 11:18:16 either the driver for samsung evo ssd is broke 2018-02-21 11:18:16 what happened? 2018-02-21 11:18:24 i see, completely dead 2018-02-21 11:18:33 rebooted 2018-02-21 11:18:38 i logged in to x11 2018-02-21 11:18:40 and it hang 2018-02-21 11:18:44 so i opened a console 2018-02-21 11:19:07 i ran dmesg and it hang before it printed anything 2018-02-21 11:19:25 the HDD led light was full on 2018-02-21 11:19:32 eg no blink, full shine 2018-02-21 11:19:33 hmm wtf 2018-02-21 11:19:49 i opened a file with vim 2018-02-21 11:19:55 and it hanged on :q 2018-02-21 11:20:04 i think its my /home partition that is broke 2018-02-21 11:20:10 I haven't kept up to date with linux development lately so I'm not entirely sure what changed 2018-02-21 11:20:16 i powreed it off hard 2018-02-21 11:20:27 and started up to boot the old, hardened kernel 2018-02-21 11:20:59 i forgot to plug the usb cable and bios does not support bluetooth 2018-02-21 11:21:13 so it booted the vanilla 4.14.20 again 2018-02-21 11:21:27 and this time it found bad things with fsck 2018-02-21 11:21:30 and it hang there 2018-02-21 11:21:31 recovering journal or similar 2018-02-21 11:21:32 and hang there 2018-02-21 11:21:46 i powered off again, hard 2018-02-21 11:22:02 manged to boot the old 4.9.y-hardened kernel 2018-02-21 11:22:04 and it booted up 2018-02-21 11:22:13 was it orphaned inodes or something in fsck? 2018-02-21 11:22:30 had lots of warninges o fsck and asked me to run it manually 2018-02-21 11:22:35 hmm 2018-02-21 11:23:06 Free blocks count wrong for group #251 (32768, counted=0). 2018-02-21 11:23:14 Fix? 2018-02-21 11:23:34 same for group 252 2018-02-21 11:23:35 253 2018-02-21 11:23:35 254 2018-02-21 11:23:36 255 2018-02-21 11:23:37 256 2018-02-21 11:23:38 etc 2018-02-21 11:23:39 everything 2018-02-21 11:24:06 what exactly was your version bump? 2018-02-21 11:24:20 so this is on LVM 2018-02-21 11:24:30 i.e. what was your previous kernel? 2018-02-21 11:24:31 4.14.19 to 4.14.20 2018-02-21 11:24:36 i see 2018-02-21 11:24:41 4.14.19 2018-02-21 11:24:47 i will look at the kernel changes in a bit 2018-02-21 11:24:59 so the setup here is 2018-02-21 11:25:15 to save you some clicks https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.14.20 2018-02-21 11:25:15 3x samsung evo SSD 2018-02-21 11:25:45 in mdadm raid10 2018-02-21 11:25:48 that md device is a pv for lvm 2018-02-21 11:25:52 added to a volume group named vg1 2018-02-21 11:26:23 and there i have a lv called /dev/mapper/vg1-lv_home 2018-02-21 11:26:29 with ext4 2018-02-21 11:28:03 looks like i lost all data 2018-02-21 11:28:03 _ikke_: you might want to go through the issues cos that 'games apps' account has posted a bunch of spam comments on e.g. #8499 2018-02-21 11:28:04 oh well 2018-02-21 11:28:23 it's some shitty bot lol 2018-02-21 11:28:36 <_ikke_> Aerdan[m]: right 2018-02-21 11:28:41 and this algitbot security spam is really annoying, only a few people (selected randomly?) have access 2018-02-21 11:29:49 huh. looks like it only got 8499 and 8493. 2018-02-21 11:32:21 <_ikke_> Aerdan[m]: removed the spam, thanks 2018-02-21 11:32:40 you're welcome. 2018-02-21 11:38:25 ikke if you remove the content of a comment it will be deleted 2018-02-21 11:38:41 <_ikke_> clandmeter: ah, didn't know that 2018-02-21 11:39:06 its stupid 2018-02-21 11:39:09 i know... 2018-02-21 11:39:12 new release should have a delelete button 2018-02-21 11:39:20 <_ikke_> ok 2018-02-21 11:39:57 +1 for delelete button 2018-02-21 11:40:19 clalalalandmeter 2018-02-21 11:40:56 shututututuup 2018-02-21 11:41:15 :p 2018-02-21 11:47:00 ok, i commented out /home in fstab 2018-02-21 11:47:02 it now boots 2018-02-21 11:47:03 without /home ofc 2018-02-21 11:47:04 the mdadm seems to be ok 2018-02-21 11:47:08 http://tpaste.us/PLQ7 2018-02-21 11:47:29 <_ikke_> ncopa: do you have other partitions? 2018-02-21 11:47:44 yes 2018-02-21 11:47:52 i have / on nvme 2018-02-21 11:47:52 <_ikke_> also ext4? 2018-02-21 11:47:56 <_ikke_> ok 2018-02-21 11:48:08 yes 2018-02-21 11:48:51 <_ikke_> but only /home is on the raid array? 2018-02-21 11:48:59 yes 2018-02-21 11:49:26 and ssd disks are only used for this 2018-02-21 11:52:19 i wonder if i should reboot to windows and run some firmware update for the disks 2018-02-21 12:05:03 heh 2018-02-21 12:05:48 <_ikke_> ? 2018-02-21 12:12:38 ok there is a "samsung magician" windows tool that can do it too 2018-02-21 12:12:40 the latest firmware is installed 2018-02-21 12:12:59 firmware update on ssd is not guaranteed to be safe, at least on most consumer/prosumer devices, so you can actually lost your data during the process and you cannot complain about it later. usually it is painless, but if you're already dealing with some problems, I would be extremely cautious and proceed with such upgrade only if changelog suggests that new version fixes some serious stuff that 2018-02-21 12:13:05 may be hitting you. 2018-02-21 12:14:11 i just did a fw upgrade for the nvme, samsung 960 2018-02-21 12:14:41 lets see what happens... 2018-02-21 12:16:54 windows booted 2018-02-21 12:33:26 koldbrutality: AWilcox[m]: if adding checkdepends would cause circular dependency, then you have to unfortunately disable check, there’s currently not any workaround :( we should address it in abuild to handle circular deps in checkdepends 2018-02-21 12:35:36 koldbrutality: AWilcox[m]: disabling check is against policy if it’s not reasoned; this is unfortunately quite common that contributor disables check without bothering to look if the project has some tests and/or adding comment why the heck (s)he disable it 2018-02-21 12:53:40 i was able to complete the fsck 2018-02-21 12:53:42 and was able to mount /home 2018-02-21 12:53:44 after reboot and login, same thing happened again 2018-02-21 12:53:45 something is seriously wrong with 4.14.20 2018-02-21 12:54:26 <_ikke_> :( 2018-02-21 12:55:29 i have a dmesg: look at the end. http://tpaste.us/Rjo4 2018-02-21 12:55:44 why am i missing openssl cms? 2018-02-21 13:00:56 cms? 2018-02-21 13:02:23 https://linux.die.net/man/1/cms 2018-02-21 13:03:59 i have no clue what to do with the kernel issue :-( 2018-02-21 13:06:45 ncopa: have you narrowed it down? 2018-02-21 13:06:55 kaniini: is cms part of libressl? 2018-02-21 13:07:09 ncopa: it's strange, because I think I've seen "exception Emask 0x10 SAct 0x10000 SErr 0x400101 action 0x6 frozen" kind of errors with bad sata cables, and it's apparently not your case, because if you're in older kernel you don't see it, right? 2018-02-21 13:07:54 correct 2018-02-21 13:07:55 clandmeter: well, there's https://github.com/libressl/libressl/tree/master/src/crypto/cms 2018-02-21 13:07:59 it didnt happen with 4.14.19 2018-02-21 13:08:27 ncopa: haven't narrowed it down any further, have you? 2018-02-21 13:08:55 nope 2018-02-21 13:09:09 only that it seems to be a kernel oops with RCU something 2018-02-21 13:09:41 there are relevant results in the changelog 2018-02-21 13:10:02 changelog, line 83 2018-02-21 13:10:48 you mean this? https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?h=v4.14.20&id=ce6faf10fd6544febcf5c3efe453193def873c60 2018-02-21 13:10:57 i dont think so, it just exports the symbols 2018-02-21 13:11:09 danieli: what you linked is old. 2018-02-21 13:11:16 that's the only change I see that's relevant to rcu 2018-02-21 13:11:24 clandmeter: haven't really kept up with it, lemme look once more 2018-02-21 13:11:56 https://github.com/libressl-portable/portable 2018-02-21 13:12:09 yeah 2018-02-21 13:12:22 could be this one: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?h=v4.14.20&id=c561093ed6843684690436dea034af53b462cfe5 2018-02-21 13:12:23 yeah, no, there's no CMS 2018-02-21 13:12:30 it was explicitly removed 2018-02-21 13:12:43 Removed unused Cryptographic Message Support (CMS) 2018-02-21 13:12:53 clandmeter: yep 2018-02-21 13:13:49 ncopa: yeah, looks a bit plausible. 2018-02-21 13:13:54 ^ 2018-02-21 13:18:52 ncopa: could you tpaste dmesg with 4.14.19? maybe more differences could be spotted during boot and leading more clues? 2018-02-21 13:19:01 ACTION has to vanish for some time, though 2018-02-21 13:21:19 i dont have 4.14.19 handy available :-/ 2018-02-21 14:07:58 ok, 4.14.19 seems to work flawlessly 2018-02-21 14:44:29 yup 2018-02-21 14:44:51 reverting this make things work again: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?h=linux-4.14.y&id=c561093ed6843684690436dea034af53b462cfe5 2018-02-21 14:53:57 <_ikke_> wow, you found it 2018-02-21 14:55:27 i think there is needed to be errors to be able to trigg the bug 2018-02-21 14:55:34 i have this: http://tpaste.us/9KXP 2018-02-21 14:55:35 at the end 2018-02-21 14:55:49 and i have always seen those for as long i can remember 2018-02-21 14:57:02 oh, so you lied to me earlier. :) you did have ata errors in 4.14.19 too 2018-02-21 14:57:31 you sure you have good sata cables? 2018-02-21 14:57:50 relatively sure 2018-02-21 14:58:42 im gonna test disable ncq whatever that is 2018-02-21 14:58:44 in any case 2018-02-21 14:59:02 kernel should not go boom in case of ata errors 2018-02-21 14:59:13 agreed 2018-02-21 14:59:59 ncq - native command queueing - improves performance 2018-02-21 15:03:02 https://bbs.archlinux.org/viewtopic.php?id=208087 2018-02-21 15:04:23 it is probably actually advanced link power management 2018-02-21 15:04:27 that is the problem 2018-02-21 15:04:35 not NCQ 2018-02-21 15:05:06 ok? 2018-02-21 15:05:27 ALPM was added in 4.14 2018-02-21 15:05:31 there is a big thread on fedora-devel about people's drives messing up under it 2018-02-21 15:05:40 link? 2018-02-21 15:06:59 https://www.spinics.net/linux/fedora/fedora-users/msg481102.html 2018-02-21 15:07:32 i think dmesg reported those errors in 4.9 kernel too 2018-02-21 15:08:09 libata.force=noncq didnt make any diff 2018-02-21 15:11:59 the solution is to set max_performance on some sysfs node to disable it 2018-02-21 15:11:59 i guess also it could be disabled in kernel 2018-02-21 15:17:23 # find /sys/devices -name link_power_management_policy | xargs cat | tpaste 2018-02-21 15:17:24 http://tpaste.us/nqNV 2018-02-21 15:17:29 i dont think that was my issue 2018-02-21 15:22:30 hmm, dunno then 2018-02-21 15:44:19 reported here: https://bugzilla.kernel.org/show_bug.cgi?id=198861 2018-02-21 18:25:08 When we boot from the ISO (aka live cd), then run alpine-conf scripts to install on a disk, what filesystem we are using ? initramfs's filesystem ? 2018-02-21 18:25:48 there must be one providing a filesystem layout 2018-02-21 18:27:45 we install new image into the target 2018-02-21 18:27:50 and then use apk audit to copy things 2018-02-21 18:27:53 iirc 2018-02-21 18:33:07 kaniini: what I am asking is before that, before "install new image". we need a filesystem to be running on to install new image 2018-02-21 18:35:34 afaik thats not the initramfs, but an newly created tmpfs 2018-02-21 18:36:11 (initramfs shows up as "rootfs" in mount table) 2018-02-21 18:37:04 liwakura : I also suspect it's not initramfs's. still trying to figure it out how. 2018-02-21 18:38:01 the initial initramfs creates an tmpfs, setups some apkovl + base system there and then switch_root's there 2018-02-21 18:39:41 you can read that behavior from /usr/share/mkinitfs/initramfs-init 2018-02-21 18:41:39 liwakura : that's it ! 2018-02-21 18:42:05 thanks 2018-02-21 19:43:59 I hope that I am not overstepping by reviewing some PRs on GitHub. I know I am just contributor, not developer yet. 2018-02-21 19:47:23 if someone wrote more than a few APKBUILDs, can pinpoint some mistakes and gives helpful tips to others regarding packaging, I have no idea how their reviews could be seen as harmful. 2018-02-21 19:48:14 awilfox: technically maintainers can sponsor things into testing 2018-02-21 19:48:43 and community 2018-02-21 20:01:38 I have a technical question about the Alpine build servers. How many space do they have? I currently package lizardfs (for internal usage at the moment) but I intend to publish it at some time and if and only if everything runs on my site. The test suite itself needs at least 60GB for all tests. 2018-02-21 20:02:35 <_ikke_> THat seems a bit excessive 2018-02-21 20:04:50 The libwebp test downloads 45 GB of video from YouTube for its test suite... that is the main reason I marked it !check :P 2018-02-21 20:05:17 I also found that it is already (for an old version) in aports/testing. 2018-02-21 20:05:44 But I did not find that package when I searched for it on pkgs.alpinelinux.org 2018-02-21 20:05:52 Also I opened https://github.com/alpinelinux/aports/pull/3372 to try and fix #7737 2018-02-21 20:05:54 <_ikke_> BernhardG: But this is ephemeral data? 2018-02-21 20:06:52 _ikke_: lizardfs is a filesystem and this space is needed to test its functionality. It is created on the fly - so it is not needed after the build. 2018-02-21 20:07:28 does anybody here have a glibc system handy available for ppc64le? 2018-02-21 20:07:30 with gcc 2018-02-21 20:07:58 i just need compile a simple test 2018-02-21 20:09:09 does it need to be ppc64le explicitly ? 2018-02-21 20:09:22 would ppc64be work 2018-02-21 20:12:46 ncopa: what are you trying to test :) 2018-02-21 20:39:01 Hey dev team, if I do the command `abuild checksum` and it returns error symbolic link loop what am I doing wrong? 2018-02-21 20:39:10 Natanael Copa: dup.pw does not resolve? 2018-02-21 20:40:22 I have two already compiled binaries inside my `src/` folder 2018-02-21 20:41:56 <_ikke_> marketzero: how does your APKBUILD look like? 2018-02-21 20:42:55 source="src/app_render src/app_control" 2018-02-21 20:43:31 <_ikke_> marketzero: You should not point to src 2018-02-21 20:43:42 package(){ cd "$srcdir" \ make DESTDIR="pkgdir" install } 2018-02-21 20:43:50 <_ikke_> the source files should be in the root of the package dir 2018-02-21 20:44:04 then what is src/ folder for? 2018-02-21 20:44:06 <_ikke_> DESTDIR="$pkgdir" 2018-02-21 20:44:19 <_ikke_> marketzero: abuild symlinks / extracts the files in there 2018-02-21 20:44:21 marketzero: for downloaded sources 2018-02-21 20:44:46 <_ikke_> marketzero: note that offical apkbuilds should not contain any binary files 2018-02-21 20:45:40 since I have no downloaded sources, then `src/` should be empty? 2018-02-21 20:46:11 <_ikke_> yes 2018-02-21 20:46:11 marketzero: not exist in the repo 2018-02-21 20:46:29 _ikke_: thanks 2018-02-21 20:49:01 what should package() look like? All the guides and other APKBUILD files have you cd into a builddir, since I am not building then what should it look like? 2018-02-21 20:50:10 <_ikke_> marketzero: what *are* you packaging? 2018-02-21 20:50:32 and application for internal development 2018-02-21 20:50:50 does the application have a buildsystem? 2018-02-21 20:51:08 yes, fully integrated, uses a CI 2018-02-21 20:51:41 I am pulling down binaries and wrapping them up in a package for deployment to other machines we are creating 2018-02-21 20:52:02 well, then, you should be doing sources="sometarball.tar.gz" and invoking the buildsystem instead of packaging binaries directly. 2018-02-21 20:53:32 I can't access a tarball of the app, only the binaries. Do I wrap them in a tarball? 2018-02-21 20:53:43 lol 2018-02-21 20:53:59 that still won't be accepted to the official repos 2018-02-21 20:54:12 it's not going in the official repos 2018-02-21 20:54:23 then it doesn't particularly matter 2018-02-21 20:54:26 mepholic: internal use, so they presumably don't give a shit. 2018-02-21 20:55:52 however it'd probably be a better idea in the long term to build your packages from an apkbuild 2018-02-21 20:56:12 Presumably sources should be null, and package() should cd to what directory? 2018-02-21 20:56:19 marketzero: put the binaries themselves in $sources 2018-02-21 20:57:00 marketzero: yeah, if you use the binaries themselves as sources, and then literally just copy them into $pkgdir in the package() step 2018-02-21 20:57:03 it should work fine 2018-02-21 20:57:16 $pkgdir is laid out like the filesystem 2018-02-21 20:57:39 kaniini: is apk search the only way to get a pkg version number? 2018-02-21 20:57:45 so if you want a bin to be in /usr/bin after you install the package, put the bin in $pkgdir/usr/bin in the package() step 2018-02-21 21:02:50 clandmeter: apk info can do it, but the output format of apk info is really not so great 2018-02-21 21:02:54 right 2018-02-21 21:03:05 apk info --version perhaps? 2018-02-21 21:03:10 clandmeter: i am designing a replacement (apk show) which is meant to be both human and computer friendly 2018-02-21 21:03:15 much as i did with apk list 2018-02-21 21:03:48 no, just apk info 2018-02-21 21:04:12 yes i know, i mean as suggestion. 2018-02-21 21:04:36 --version show the latest version in repository 2018-02-21 21:05:01 you can do that with apk-tools 2.10: apk list --latest [packages] 2018-02-21 21:05:24 ok 2018-02-21 21:05:25 i intend to set up a repo with apk-tools nightlies soon 2018-02-21 21:05:54 so you can just upgrade your apk tools that way 2018-02-21 21:06:56 apk list should be able to do anything apk search can do at this point, but it does operate on the "names database" instead of specific repositories 2018-02-21 21:07:07 and there's a couple of items on my todo list still for it 2018-02-21 21:07:10 like listing @tags 2018-02-21 21:08:48 apk show and apk query will be a cleaned up form of apk info that has more usable output 2018-02-21 21:09:27 apk info does a bunch of unrelated stuff right now 2018-02-21 21:11:21 <_ikke_> github says this license is BSD-2-Clause, but the file starts with ISC: https://github.com/jedisct1/piknik/blob/master/LICENSE 2018-02-21 21:13:30 <_ikke_> Any idea what license I should pick? 2018-02-21 21:13:31 _ikke_: the text is BSD-2-Clause, but for unknown reasons someone put "ISC LICENSE." on top of the file 2018-02-21 21:14:41 (haven't checked what's in the source files, commenting only on what I'm seeing in the LICENSE file you linked.) 2018-02-21 21:14:53 <_ikke_> right 2018-02-21 21:15:11 <_ikke_> source files don't contain a license header 2018-02-21 21:18:50 kaniini: i want to get the version of the current linux-vanilla from v3.7 2018-02-21 21:18:59 so im doing: apk --verbose --no-cache --repositories-file /dev/null --repository http://dl-4.alpinelinux.org/alpine/v3.7/main search -x linux-vanilla 2018-02-21 21:19:55 but that includes the fetch info... 2018-02-21 21:20:30 adding --quiet removes it but also the version :| 2018-02-21 21:22:42 i think apk info will show information about all versions in the repo its not preferable. 2018-02-21 21:29:07 <_ikke_> Should the check function be added to the default template for new packages (newapkbuild)? 2018-02-21 21:34:08 _ikke_ I, as a beginner in packaging, would prefer that. Also the checkdepends variable would be useful (I did not know about it before a comment from clandmeter) 2018-02-21 21:34:30 <_ikke_> right 2018-02-21 21:36:08 It'd be nice. CMake has CTest, which needs a different invocation than autotools, which always uses `make check` whereas most custom build systems use `make test`. 2018-02-21 21:36:19 And all Perl packages use the same test invocation. 2018-02-21 21:36:22 So perhaps it should be in the build system parts, like build() is. 2018-02-21 21:36:57 checkdepends needs to be added to wiki 2018-02-21 21:36:57 its not iirc 2018-02-21 21:37:19 we need to notify the documentation team (: 2018-02-21 21:37:23 <_ikke_> It does not need to have an implementation, just like package is empty by default 2018-02-21 21:38:26 https://github.com/alpinelinux/abuild/pull/33/commits/78a0333cf38cc9020658caa687613bb282c8429f 2018-02-21 21:38:29 I'm on it clandmeter! 2018-02-21 21:38:29 btw. clandmeter, thank you for your bug report to the GitHub of burp. 2018-02-21 21:39:41 <_ikke_> anyone familiar with the go build / dependency system? 2018-02-21 21:39:48 A. Wilcox: :) 2018-02-21 21:40:18 a little 2018-02-21 21:40:56 <_ikke_> trying to run a test script (shell), which runs go build 2018-02-21 21:41:05 <_ikke_> it complains about dependencies 2018-02-21 21:41:23 <_ikke_> which as far as I can tell are present in the vendor dir 2018-02-21 21:42:42 <_ikke_> piknik.go:13:2: cannot find package "github.com/BurntSushi/toml" in any of: 2018-02-21 21:45:39 did you set the GOPATH environment variable correctly? 2018-02-21 21:46:11 <_ikke_> export GOPATH=$PWD 2018-02-21 21:47:14 <_ikke_> (where PWD is the source dir) 2018-02-21 21:47:31 <_ikke_> $builddir 2018-02-21 21:48:11 <_ikke_> does go get github.com/jedisct1/piknik actual build the project? 2018-02-21 21:50:13 it should fetch and build. 2018-02-21 21:50:48 iirc, its been a while since i touched go... 2018-02-21 21:50:49 <_ikke_> That seems to work 2018-02-21 21:51:02 <_ikke_> but the test.sh then does a go build, which then fails 2018-02-21 21:51:04 i have slept much better since. 2018-02-21 21:51:29 <_ikke_> haha 2018-02-21 21:56:28 _ikke_: is that a pr or are you trying to pkg it yourself? 2018-02-21 21:56:51 <_ikke_> clandmeter: Will be a PR eventually 2018-02-21 21:58:17 i think gitea is one of the pkgs i did. 2018-02-21 21:58:46 <_ikke_> I did do a fix for docker for a similar issue 2018-02-21 21:58:59 <_ikke_> but there I basically just did mv vendor src 2018-02-21 22:01:54 vendor dir should be automatically picked up if you set the gopath correctly iirc. 2018-02-21 22:02:22 <_ikke_> aparently it isn't4 2018-02-21 22:02:45 <_ikke_> It looks /home/build/aports/testing/piknik/src/piknik-0.9.1/gohome/src/github.com/minio/blake2b-simd 2018-02-21 22:03:05 <_ikke_> (gohome is just an experiment) 2018-02-21 22:22:43 _ikke_: this works http://tpaste.us/ykBl 2018-02-21 22:26:54 <_ikke_> You disabled the check part :D 2018-02-21 22:27:20 <_ikke_> but this will help, thanks 2018-02-21 22:29:48 yes i wanted to clear the clutter. i have some local changes to abuild that are rather verbose. 2018-02-22 00:14:06 almost there guys, I can't for the life of me understand why a simple cp command fails. Inside package() I have followed mepholic's advice and coping two binaries into $pkgdir and I am entering fakeroot and then cp: can't create `...app_control`: no such file or directory 2018-02-22 00:22:36 marketzero: you might want to specifically do something like 2018-02-22 00:23:02 cp $srcdir/filename... $pkgdir/usr/bin/filename... 2018-02-22 00:23:16 make sure you mkdir -p $pkgdir/usr/bin first 2018-02-22 00:23:22 okay I'll try that 2018-02-22 00:23:25 in the package() section 2018-02-22 00:40:19 mepholic: Thank you sir, that did it 2018-02-22 00:55:21 no problem 2018-02-22 13:16:16 <_ikke_> Oh, fun one 2018-02-22 13:20:44 really love how compilers are used as code downloaders, build systems, test frameworks, package managers etc. these days 2018-02-22 13:21:06 soon compilers will do pretty much everything except the compilation part 2018-02-22 13:28:39 <_ikke_> I think the next logical feature will be a mail client 2018-02-22 13:31:55 idk 2018-02-22 13:32:00 a web browser would make more sense 2018-02-22 13:32:11 need that to browse the docs and to access the bug tracker 2018-02-22 13:32:59 i should point out using `go get` in APKBUILD is a policy violation 2018-02-22 13:33:05 use glide instead 2018-02-22 13:33:37 why glide and not wget 2018-02-22 13:34:00 why does go need a package manager written in go_ 2018-02-22 13:34:05 what's wrong with apk 2018-02-22 13:34:06 go get doesn't just download packages, it handles dependency resolution 2018-02-22 13:34:07 glide does as well, but ahead of time 2018-02-22 13:34:37 different go packages require different artifacts 2018-02-22 13:34:47 why is a package manager using another package manager to download shit? 2018-02-22 13:34:47 so you wind up packaging every version of every artifact 2018-02-22 13:34:56 abuild isn't a package manager 2018-02-22 13:35:07 it builds packages for apk 2018-02-22 13:35:22 <_ikke_> Tsutsukakushi: you end up having to package many versions per package 2018-02-22 13:35:31 it's too early to log into irc to ban you, so please just shut up 2018-02-22 13:35:43 why? 2018-02-22 13:35:50 why would you need many versions of the packages 2018-02-22 13:35:57 ok doing it anyway 2018-02-22 13:36:02 lol 2018-02-22 13:36:13 >i ban you because i disagree with you 2018-02-22 13:36:17 how mature kaniini 2018-02-22 13:36:56 your questions are legitimate, but you should go ask the people who write programs in go why this is 2018-02-22 13:37:17 lol 2018-02-22 13:37:48 they have no interest in making alpine good 2018-02-22 13:37:55 either way, if we did it as you propose it would result in us having to package, individually, every version of every go library 2018-02-22 13:38:08 debian does it this way and it's a mess 2018-02-22 13:38:09 as it should be 2018-02-22 13:38:12 and since go programs are staticly linked 2018-02-22 13:38:15 we just say fuck it 2018-02-22 13:38:17 not worth it 2018-02-22 13:38:19 you don't need all go libaries 2018-02-22 13:38:22 and use glide inside the APKBUILD 2018-02-22 13:38:24 you only need specific ones 2018-02-22 13:38:26 ok 2018-02-22 13:38:31 not all libraries are worth packaging 2018-02-22 13:38:36 yeah 2018-02-22 13:38:37 most software is either useless or garbage 2018-02-22 13:38:37 ok 2018-02-22 13:38:58 again 2018-02-22 13:39:06 for the go software we already package 2018-02-22 13:39:25 if we did not use glide 2018-02-22 13:39:30 there would literally be 1000+ apks already 2018-02-22 13:39:46 you don't understand 2018-02-22 13:40:30 it's basically as bad of a mess as the node.js ecosystem 2018-02-22 13:40:34 people have go packages which are like 6 lines of code 2018-02-22 13:40:42 yeah 2018-02-22 13:40:45 don't include those 2018-02-22 13:40:47 just leave them out 2018-02-22 13:40:48 so, since it's staticly linked anyway 2018-02-22 13:40:50 its better to just let glide handle it 2018-02-22 13:40:50 they have no value anyways 2018-02-22 13:41:14 <_ikke_> Tsutsukakushi: They don't? 2018-02-22 13:41:19 not all libraries deserve to be packaged for operating systems 2018-02-22 13:41:36 <_ikke_> Sure, but if programs rely on them 2018-02-22 13:41:40 <_ikke_> usefull programs 2018-02-22 13:41:44 those programs should be fixed 2018-02-22 13:41:51 ? 2018-02-22 13:42:08 if a program depends on a 6 line library that should be enough reason to disqualify it 2018-02-22 13:42:09 How would you fix a program that rely on a library that is not packaged? 2018-02-22 13:42:22 now, you are just trolling 2018-02-22 13:42:26 Tsutsukakushi, what is your point here? 2018-02-22 13:42:27 <_ikke_> Tsutsukakushi: should each program reinvent the wheel everytime? 2018-02-22 13:42:30 please go troll somewhere else 2018-02-22 13:42:35 +1 2018-02-22 13:42:42 _ikke_: it's barely a function 2018-02-22 13:42:57 _ikke_: it's far from reinventing a wheel 2018-02-22 13:43:09 while that may be true, this isn't the appropriate venue to complain about (lack of) Go software engineering practices 2018-02-22 13:43:15 it's less lines than you'd have to type for error handline for a 3 line program 2018-02-22 13:43:29 i suggest to talk to Go developers about their sins 2018-02-22 13:43:45 it's an appropriate venue to complain about the bad requirements for apk packaging 2018-02-22 13:43:47 <_ikke_> Tsutsukakushi: So you want big libraries that would only make the binary larger? 2018-02-22 13:43:55 to which they will probably tell you they don't want their software packaged anyway 2018-02-22 13:43:59 since go itself has a package manager (go get) ;) 2018-02-22 13:44:01 <_ikke_> and then complain about bloated software 2018-02-22 13:44:10 _ikke_: i want useful libraries 2018-02-22 13:44:22 _ikke_: 6 line library does nothing that couldn't be just thrown in the source as is 2018-02-22 13:45:14 the requirement for APK packaging is a maintainer who wants to package the software 2018-02-22 13:45:15 it's trivial, it's not even enough to be copyrightable 2018-02-22 13:45:22 ok 2018-02-22 13:45:49 Tsutsukakushi, if you are willing to maintain software by fixing libs, you're very welcome 2018-02-22 13:46:06 then you'll end up in understanding that is not doable. 2018-02-22 13:46:48 this conversation has moved past it's usefulness 2018-02-22 13:46:54 Going in $Software and trying to "fix it" with the "6 line of codes that can be implemented in the source code rather than in an external library" 2018-02-22 13:46:56 lets talk about something else now 2018-02-22 13:47:05 kaniini_: yeah, better pull out the banhammer, right? 2018-02-22 13:47:53 ACTION shrugs 2018-02-22 13:48:07 i'm asking nicely that we discuss something else now 2018-02-22 13:48:42 There's something I want to discuss actually 2018-02-22 13:48:52 which happens from time to time 2018-02-22 13:49:12 when a $package relies on a python library of a specific version 2018-02-22 13:49:21 in edge we have almost the latest one 2018-02-22 13:49:31 yes, that's a mess too 2018-02-22 13:49:37 but with python, you have specific range of accepted versions 2018-02-22 13:49:43 my case? GNS3 2018-02-22 13:49:55 aiohttp is upgraded once a week.. 2018-02-22 13:50:04 and GNS3 breaks each time 2018-02-22 13:50:07 for two reason: 2018-02-22 13:50:13 1. different version (of course) 2018-02-22 13:50:23 aiohttp is one of the larger offenders imo 2018-02-22 13:50:26 because they keep changing APIs 2018-02-22 13:50:31 in minor releases 2018-02-22 13:50:45 2. abump $newpackage-$version is not enough, since might have new dependencies 2018-02-22 13:50:48 kaniini, yes 2018-02-22 13:50:51 absolutely true 2018-02-22 13:50:51 so 2018-02-22 13:50:59 how to handle these cases? 2018-02-22 13:51:28 what i have in mind is a new apk applet called `apk import` 2018-02-22 13:51:30 I don't see a solution actually...just I can have a stable version 2018-02-22 13:51:31 then you just use pip instead 2018-02-22 13:51:49 a wrapper for pip? 2018-02-22 13:52:04 (apk import registers a list of files with apk and associates them with a virtual package) 2018-02-22 13:52:19 umh 2018-02-22 13:52:22 interesting 2018-02-22 13:52:34 But still you need to install build-base, python$ver-dev etc 2018-02-22 13:52:47 yes 2018-02-22 13:53:45 how would you handle the virtual package name? 2018-02-22 13:53:49 Might be overlapping 2018-02-22 13:53:54 py:..whatever 2018-02-22 13:54:01 note the use of a namespace 2018-02-22 13:54:21 ok 2018-02-22 13:54:47 interesting 2018-02-22 13:55:02 but it doesn't really solve the problem 2018-02-22 13:55:07 on it's own 2018-02-22 13:55:29 which is why there is stuff like snaps and appimages 2018-02-22 13:55:55 what i really envision happening is adding the ability to apk to manage subroots 2018-02-22 13:56:47 if we have that, then it's possible to have multiple environments 2018-02-22 13:57:05 something like virtualenv for an entire filesystem :) 2018-02-22 13:57:23 heh 2018-02-22 13:57:28 this isn't likely to happen in 3.8 though 2018-02-22 13:57:50 but such modularity is on the roadmap for adelie linux 2 2018-02-22 14:02:23 so possibly 3.9 or 3.10 2018-02-22 14:22:46 >virtualenv for an entire filesystem 2018-02-22 14:23:05 i see that software is crappy enough that we even need this 2018-02-22 14:23:22 its still something i dont want ever to deal with 2018-02-22 15:05:21 Some people would find this functionality useful though 2018-02-22 16:08:30 I have a 10Giga Eth card Broadcom NetXtreme II BCM57810, installed on my alpine server ( xen 3.7 ), anybody with similar network card? 2018-02-22 16:08:37 any problems? 2018-02-22 18:31:36 liwakura: re: the mkinitfs stuff we talked yesterday. It looks like when we boot from iso image, after the kernel is loaded, it looks for "init" program in initramfs-vanilla image. then *this* init script will create a (tmpfs) sysroot, then switch_root to it. 2018-02-22 18:34:05 at first I thought it will switch_root to modloop-vanilla squashfs filesystem, but this squashfs just contains kernel modules. 2018-02-22 18:39:35 ye 2018-02-22 18:41:07 For what it's worth, liwakura, I agree that I don't ever want to deal with it either. I would never personally use such feature (and would avoid software that would need it), but I know some people don't have a choice. 2018-02-22 19:12:59 pushing new musl in a minute 2018-02-22 19:13:27 i was about to do it *now* :) 2018-02-22 19:13:52 oh, 1.19 out 2018-02-22 19:14:01 ncopa, well, if you have it ready, go ahead 2018-02-22 19:14:07 i was going through still the change logs 2018-02-22 19:14:27 security release or just regular? 2018-02-22 19:14:32 feature release 2018-02-22 19:14:38 bunch of bug fixes too 2018-02-22 19:16:14 i dont have it ready 2018-02-22 19:16:19 if you have it, push it 2018-02-22 19:16:31 all patches are to be removed? 2018-02-22 19:17:29 not all 2018-02-22 19:17:35 that's why it's taking time :) 2018-02-22 19:18:43 2000-pthread-internals-increase-DEFAULT_GUARD_SIZE-to-2-p.patch and handle-aux-at_base.patch are not upstream 2018-02-22 19:19:35 i think i got it ready 2018-02-22 19:19:43 yeah, same conclusion 2018-02-22 19:19:48 test built and seems to work 2018-02-22 19:19:51 on x86_64 2018-02-22 19:20:49 done 2018-02-22 19:22:39 i did on x86 2018-02-22 19:22:41 push it 2018-02-22 19:22:42 seems to work yes 2018-02-22 19:24:23 fabled: i have been looking at a somewhat interesting bug 2018-02-22 19:24:42 apparently getaddrinfo(3) from glibc does not work in user qemu-ppc64le built with musl 2018-02-22 19:24:45 but debian qemu works 2018-02-22 19:24:52 that is, it does not resolve anything when AF_UNSPEC is used 2018-02-22 19:24:56 when using AF_INET or AF_INET6 it works 2018-02-22 19:25:42 oh? 2018-02-22 19:27:36 AF_UNSPEC works under debian's qemu-ppc64le 2018-02-22 19:27:36 #8131 2018-02-22 19:27:37 algitbot: hi 2018-02-22 19:27:38 https://bugs.alpinelinux.org/issues/8131 2018-02-22 19:27:39 i looked at the debian patches for qemu and it does not look like they have anything relevant 2018-02-22 19:28:11 algitbot: sorry if i woke you up from your sleep 2018-02-22 19:29:13 next plan is to build a static ppc64le strace and a C app that only calls getaddrinfo. 2018-02-22 19:29:14 i have only had access to python's socket.getaddrinfo 2018-02-22 19:29:49 its just weird... 2018-02-22 20:41:13 ncopa: the latter patch is from dalias 2018-02-22 20:41:18 ncopa: he intends to commit a more complete patch to musl 2018-02-22 20:42:09 ncopa: the former is a mitigation against stack jumping that dalias didn't want 2018-02-23 00:16:16 I'm trying to reproduce the build error http://build.alpinelinux.org/buildlogs/build-3-7-ppc64le/community/go/go-1.9.4-r0.log. My ppc64le box is installed with Ubuntu 16.04 and I'm starting an Alpine:3.7 container. In the container I 2018-02-23 00:16:16 apk update, apk upgrade, and apk add alpine-sdk, clone aports and git checkout the 3.7-stable branch. With this config I'm abuild'ing the community/go package and am not seeing any errors. Are there some other items I should be installing 2018-02-23 00:16:16 to more closely mimic the real ppc64le build machine environment in hopes of reproducing the error? 2018-02-23 01:22:07 humm that should really be close enough 2018-02-23 02:49:14 tox with python3 is broken huh? 2018-02-23 04:39:21 mksully221: could that be a special case of the different kernel (hardened vs. Ubuntu kernel)? 2018-02-23 04:44:43 i though the hardened kernel was just x86? Is there a ppc64le version too? 2018-02-23 04:46:05 please review/commit https://github.com/alpinelinux/aports/pull/3386 2018-02-23 05:00:48 mksully221 my assumption was because it writes the reopening fails. that suggest that the file was there/accessible even if there are warn messages before that say it was not found 2018-02-23 05:01:31 I don't know the exact build environment. 2018-02-23 05:03:38 mksully221: could there also be a simple limit of max opened files? I don't know the exact error message for that case. 2018-02-23 05:13:42 thanks i'll look at that 2018-02-23 09:05:43 mksully221: i am rebooting the ppc64le machine. it had some OOPS and was very slow 2018-02-23 09:18:20 lol these checkdependencies are growing expodentially 2018-02-23 09:18:31 i'm about to give up on this 2018-02-23 09:18:39 just insanity 2018-02-23 09:19:33 koldbrutality: what are you trying to do? 2018-02-23 09:19:53 i am trying to fix all these check() 2018-02-23 11:22:28 the ppc64le machine nevver came back :-/ 2018-02-23 11:31:12 <_ikke_> ncopa: :( 2018-02-23 12:38:02 ncopa: check email 2018-02-23 12:38:12 ibm is having a look at ppc64le 2018-02-23 12:48:25 thanks 2018-02-23 14:36:58 kaniini: is your new apk tools version going to have a way to generate a dependency graph? 2018-02-23 14:41:22 apk dot already does that 2018-02-23 15:08:51 kaniini: i think i mean runtime dependency tree. so i can get a list of what alpine-base pulls in. 2018-02-23 15:09:51 it sort of does that, just presents it as a graphical graph :) 2018-02-23 15:09:55 clandmeter: i pushed mqtt-exec with crypto support 2018-02-23 15:09:58 ah yes thx 2018-02-23 15:09:58 it was all ok, right? 2018-02-23 15:09:59 i wanted to ask you :) 2018-02-23 15:10:02 except the help text typo 2018-02-23 15:10:05 i want to tag new release 2018-02-23 15:10:06 i didnt test the keys 2018-02-23 15:10:08 but cert base yes 2018-02-23 15:10:21 the psk? 2018-02-23 15:10:26 yep 2018-02-23 15:10:32 do you think you could give it a testrun? 2018-02-23 15:10:38 i never used it so i need to check it. 2018-02-23 15:10:53 i think you set a pre shared "password" 2018-02-23 15:11:07 its user:key if im right 2018-02-23 15:11:43 where user can be used as auth 2018-02-23 17:10:38 what's left here https://github.com/alpinelinux/aports/pull/3303 to be accepted? 2018-02-23 17:11:33 <_ikke_> Might take some time before things are merged 2018-02-23 17:38:53 I am an awk programmer, but I have a hang at : https://git.alpinelinux.org/cgit/aports/tree/main/openrc/networking.initd#n26 2018-02-23 17:39:03 with this : for i in $(grep auto $ifconf ); do [ "$i" == "auto" ] && continue; printf "%s " $i; done 2018-02-23 17:39:06 I made it work 2018-02-23 17:39:14 is it okay to make this change ? 2018-02-23 17:40:28 * I am not an awk programmer 2018-02-23 17:40:38 :( 2018-02-23 17:40:48 this line works out for me for a while now. 2018-02-23 18:00:28 what is the standard java on this distro? 2018-02-23 18:03:04 nm i think i found it 2018-02-23 18:07:11 tmh1999: it should rather not hang. the only easy way I see it hanging is if ifconf is empty, but it should be not. your workaround is not good enough. it disregards commented out lines and uses bashism (== instead of =) 2018-02-23 18:08:18 przemoc : == should be = just fine. yeah I agree with comments. 2018-02-23 18:08:30 you can replace grep auto $ifconf with sed '/^[^#]*auto[ \t][ \t]*/!d;s,,,;' "$ifconf" and then you can also remove short-circuit on "auto" 2018-02-23 18:09:07 przemoc: why the empty substitution? 2018-02-23 18:09:46 reusing pattern from the search 2018-02-23 18:09:47 przemoc : afaik, find_ifaces() takes no argument, correct ? the only place calls it is : https://git.alpinelinux.org/cgit/aports/tree/main/openrc/networking.initd#n43 2018-02-23 18:11:50 yeah, it takes no args 2018-02-23 18:15:57 tmh1999: are you fighting with some s390x perhaps still? maybe your awk misbehaves there. 2018-02-23 18:16:11 yeah 2018-02-23 18:17:52 przemoc : funny thing, I have this tweak a while ago. Now I am revisiting it, # /etc/init.d/networking restart works ok. but if I take the function out and run it alone, it hangs. Not really sure if I should be concerned about this anymore. 2018-02-23 18:18:59 yeah, it won't work alone, because ifconf is not defined then, so awk expect data on stdin 2018-02-23 18:19:09 s/expect/&s/ 2018-02-23 18:19:22 hah 2018-02-23 18:19:24 interesting 2018-02-23 18:19:29 thanks ! 2018-02-23 18:19:42 right I forgot $ifconf 2018-02-23 18:20:09 since no arg is passed, $1 = 'auto' kind of strange to me 2018-02-23 18:20:39 $1 means the first field in awk 2018-02-23 18:21:56 I should take a crash course in awk 2018-02-23 18:22:09 that's interesting though 2018-02-23 18:22:45 awk is quite nice, at least it's readable compared to more complex sed scripts 2018-02-23 18:36:36 przemoc : while you're here, may I ask you one more thing ? would kernel parm console=/dev/console override those ttyX in /etc/inittab ? 2018-02-23 18:37:15 only /dev/console works out for me on s390x, and passing that kernel parm wouldn't help. I have to hard code in /etc/inittab 2018-02-23 18:37:46 like : console::respawn:/sbin/getty 38400 /dev/console 2018-02-23 18:42:29 I think I will submit a patch for alpine-baselayout for this 2018-02-23 18:44:24 maybe console=console work 2018-02-23 18:45:06 tmh1999: no, console=... passed to kernel not influences inittab. 2018-02-23 18:45:49 and kernel does not take console as /dev/... 2018-02-23 18:47:44 so your console parameter passed to kernel is possibly bogus 2018-02-23 19:00:23 tmh1999: I could be misunderstood, so let me clarify. while inittab is not influenced per se, if you use /dev/console there, it will be influenced by console= kernel parameter. also openrc's init does use /dev/console early, so if console=... is correct but not pointing to anything you can see, you won't see openrc's output. 2018-02-23 19:03:16 przemoc : understood 2018-02-23 19:24:26 I've managed to package the current version of LizardFS (3.12.0) - which also needs some other libraries not available in egde currently. There is also an older version of LizardFS (2.6.0) in testing but it is not listed on pkgs.alpinelinux.org. How does a PR work in that case? 2018-02-23 19:29:08 BernhardG: It's currently disabled by arch="". Looks like unmaintained to me. If you want to take a maintainership/ bump to new ver, just submit a pr. 2018-02-23 19:36:48 tmh1999, thank you for your answer. I consider doing so because we are using LizardFS anyway in some context and these systems get migrated to alpine in the near future. 2018-02-23 19:41:48 hi any news on backporting the gcc changes for "indirect thunk" to Alpine? 2018-02-23 20:36:19 chromium crashed for selenium with chromedriver: https://pastebin.com/C5R3MgFa 2018-02-23 20:39:37 i ran chromedriver with --help it seems to not crash 2018-02-23 20:55:30 trying no-sandbox 2018-02-23 20:59:10 Would it be acceptable to enable S/MIME in the main/mutt package? 2018-02-23 21:00:11 Looks like it adds about 100 kB to the size of the package. 2018-02-23 21:10:23 lol it works.... it opened the web browser and did the tests 2018-02-23 21:14:34 what app would benefit? 2018-02-23 21:14:51 i just read email that is all no fancy stuff 2018-02-23 21:15:37 probably an external framebuffer viewer 2018-02-23 21:15:45 might be a good idead 2018-02-24 01:07:17 i have to build entire testing/firefox for small a geckodriver :'( 2018-02-24 14:59:57 the mesa package has no test suite 2018-02-24 15:00:10 not run but on gentoo it does 2018-02-24 20:16:30 hey i was wondering how stuff gets moved from testing to community? 2018-02-24 20:17:08 <_ikke_> bleb: the maintainer usually requests the move 2018-02-24 20:17:54 nvi has been in testing for a couple years now 2018-02-24 20:18:56 <_ikke_> you can ask Sören Tempel if it can be moved to community 2018-02-24 20:20:10 ok will do, thanks 2018-02-24 21:35:02 bleb: I am the nvi maintainer, I just send you a response to your mail ;) 2018-02-25 07:25:51 nmeum: I guess its due to that nvi is not maintained upstream (that it will never leave testing). Debian ships i vim-tiny for base installs, that would be a nice option to the busybox version vi on Alpine, instead of nvi. 2018-02-25 12:11:13 Hey alpinists... 2018-02-25 12:11:29 Is there a known interaction between globbing and fakeroot? 2018-02-25 12:12:17 because I have a line in an APKBUILD's package() function doing: cp -f "$builddir/inc/*" "$pkgdir/usr/include/" 2018-02-25 12:12:35 and it fails, saying it can't stat $builddir/inc/* (builddir is expanded) 2018-02-25 12:12:44 because ENOENT 2018-02-25 12:12:58 but I know for a fact there are files there, and doing the cp manually works 2018-02-25 12:13:14 so the only explanation I have is that fakeroot messes up the globbing somehow 2018-02-25 12:13:21 is it something well-known? 2018-02-25 12:15:11 ok, forget it 2018-02-25 12:15:34 sorry for the noise. 2018-02-25 12:16:51 (the only difference between single and double quotes is $ expansion, so globbing doesn't happen inside double quotes. sigh.) 2018-02-25 16:28:48 Test from Matrix 2018-02-25 16:52:50 too many messed up python packages 2018-02-25 16:53:11 i will make a lot of pull requests because of this 2018-02-25 16:56:58 everything that sits on top of them will have to be updated 2018-02-25 18:41:15 I wonder how libcanberra-gtk2 can exist with the current APKBUILD... for me it just complains GTK can not be found, so it seems to lack some dependencies. 2018-02-25 18:41:33 the build log gives a 404... http://build.alpinelinux.org/buildlogs/build-edge-aarch64/main/libcanberra-gtk2/libcanberra-gtk2-0.30-r2.log 2018-02-25 18:42:01 is it maybe an idea to drop libcanberra-gtk2? it seems there are no packages depending on it other than libcanberra itself, and gtk2 is old anyway 2018-02-25 21:13:51 <_ikke_> clandmeter: thanks for merging piknik :) 2018-02-25 23:05:21 Hello) looks like Flag button do not work, I tried to flag https://pkgs.alpinelinux.org/package/v3.7/main/x86_64/haproxy# as outdated.. 1.7.9 vs. 1.8.4.. 2018-02-25 23:05:46 <_ikke_> clandmeter: ^ 2018-02-25 23:05:50 <_ikke_> returns 404 not found 2018-02-25 23:06:12 thats correct 2018-02-25 23:06:29 you cannot flag stable branches 2018-02-25 23:06:47 ha 2018-02-25 23:06:57 i need to remove the button 2018-02-25 23:07:53 lorddaedra: you can only flag on edge branch 2018-02-25 23:07:56 I try to flag https://pkgs.alpinelinux.org/package/edge/main/x86_64/haproxy# but do not see any output after button click 2018-02-25 23:08:13 Tried in Chromium and FF 2018-02-25 23:08:29 its already flagged 2018-02-25 23:08:58 https://pkgs.alpinelinux.org/flagged?origin=haproxy 2018-02-26 00:39:48 just as idea: add votes for packages to sort their update priority order 2018-02-26 00:40:13 it will allow to see which packages are "most wanted" 2018-02-26 11:13:50 Is it considered as a bug that there is a /etc/conf.d/hostname file which is never used? It seems /etc/hostname gets used. Or is there any other reason behind having this file in openrc? 2018-02-26 11:17:29 <_ikke_> BernhardG: what does apk info -W /etc/conf.d/hostname return? 2018-02-26 11:18:00 <_ikke_> ah, openrc 2018-02-26 11:19:20 <_ikke_> BernhardG: So it's just automatically added for every *.initd file 2018-02-26 11:20:30 _ikke_, ok. But the description in it is misleading "Set to the hostname of this machine". It seems it does not change anything. 2018-02-26 11:21:43 <_ikke_> Hm, I think that file comes from openrc itself 2018-02-26 11:22:11 <_ikke_> https://github.com/OpenRC/openrc/blob/master/conf.d/hostname 2018-02-26 11:23:24 <_ikke_> https://github.com/OpenRC/openrc/blob/master/init.d/hostname.in 2018-02-26 11:23:27 _ikke_, seems so. Those scripts also don't use that file. So this could be an upstream problem. 2018-02-26 11:24:09 <_ikke_> BernhardG: the hostname.in script does use it (it's automatically loaded by openrc) 2018-02-26 11:25:52 _ikke_, thank you. 2018-02-26 11:25:54 <_ikke_> BernhardG: So the default initd script does seem to use it, but it's overridden in alpine 2018-02-26 20:10:57 gerrit seems to be cool, could replace/merge github + bugs.a.o + alpine-aports ml, into 1 place. 2018-02-26 20:11:24 not sure if it was brought here or not, just want to speak out 2018-02-26 20:13:36 it seems also play nicely with cgit 2018-02-26 21:06:57 fabled: do you have any thoughts on apk rollbacks 2018-02-26 21:26:17 kaniini: https://github.com/alpinelinux/aports/pull/3026#issuecomment-368656010 2018-02-26 21:26:48 kaniini, i have had them on my todo 2018-02-26 21:27:16 kaniini, initial thought is to keep track of pkg=id records somewhere for rollback 2018-02-26 21:35:55 fabled: do you know if somebody is working on "indirect thunk" for gcc shipped with Alpine? 2018-02-26 21:36:33 HRio, what's that? 2018-02-26 21:36:43 needed for SP2 mitigations 2018-02-26 21:37:09 can not prepare the XEN SP2 mitigations without that support in gcc 2018-02-26 21:38:02 oh that one 2018-02-26 21:38:11 the new switch to emit those 2018-02-26 21:38:35 not sure. 2018-02-26 21:39:28 I guess its needed for linux retpoline as well, but not sure 2018-02-26 21:45:57 https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01043.html 2018-02-26 21:47:28 HRio, i think yeah, i remember the retpoline name only 2018-02-26 21:49:32 we should probably cherrypick the commits unless they do release soon 2018-02-26 21:50:49 debian released an updated 6.3 version of gcc the other day, could be a start to see what patches the picked 2018-02-26 21:50:59 s/the/they/ 2018-02-26 21:52:56 would be good reference, yes 2018-02-26 21:58:06 seems to be patches by "H.J. Lu" seems to be 8 patches in total, the first three have hjl and the last "H.J. Lu" 2018-02-26 21:58:37 can not find where Debian maintain gcc for stable at the moment 2018-02-26 21:58:47 so just downloaded the source package 2018-02-26 22:10:36 First patch in series: Subject: [PATCH] i386: Move struct ix86_frame to machine_function 2018-02-26 22:11:17 last: [PATCH] x86: Disallow -mindirect-branch=/-mfunction-return= with -mcmodel=large 2018-02-27 02:25:06 what the fuck 2018-02-27 02:25:13 the lynx package has no https support 2018-02-27 02:46:20 adelie's does! 2018-02-27 02:46:46 mepholic: lynx is slated to get adelie's changes at some point, ISTR. 2018-02-27 02:47:12 good, glad to hear it 2018-02-27 02:55:40 lol 2018-02-27 07:38:19 ncopa, et al: if you're going to update the kernel or its modules, please consider merging this pr first: https://github.com/alpinelinux/aports/pull/3365 2018-02-27 10:07:03 xentec: thanks for the reminder 2018-02-27 10:45:08 jirutka/Shiz: what is the status of porting rust to the remining arches? 2018-02-27 10:45:19 i'd love to have rust on every arch for the v3.8 release 2018-02-27 12:20:21 ncopa: well, I’ve tried to use mrustc to bootstrap rustc and cargo for x86_64 from sources and eventually use it even for other arches 2018-02-27 12:20:51 ncopa: but there are still some problems, cargo compiled by rustc compiled by mrustc segfaults 2018-02-27 12:22:57 ncopa: I didn’t try to cross-compile rustc from x86_64 to other arches yet, tbh I currently don’t have so strong interest in it to invest the time, b/c I have very limited experience with cross-compiling, so it would take me quite long to figure out how to actually do that for rustc 2018-02-27 12:24:50 ncopa: and I’m still balancing between “I want to support the Rust language” and “I don’t wanna maintain this crap and deal with ignorance/stupidity/immaturity of people behind Cargo” 2018-02-27 12:28:04 talking about cargo, there are still some pending issues :( 2018-02-27 13:21:53 Guys, I'm working on a new copy of aports git repo. Git hooks seem not working. Is there something to configure? 2018-02-27 13:22:10 <_ikke_> terra: what hooks do you expect to run? 2018-02-27 13:22:25 new aport: 2018-02-27 13:22:53 <_ikke_> You need to manually place those hooks 2018-02-27 13:23:10 <_ikke_> (I'm not aware of any aports git hooks, but they will never be automatically installed after clone) 2018-02-27 13:23:38 hmm.. I fotgot how I enabled previous oneç 2018-02-27 13:26:50 It seems I have to copy .githooks/* to .git/hooks 2018-02-27 13:26:59 <_ikke_> right 2018-02-27 13:27:10 <_ikke_> make sure they're executable as well 2018-02-27 13:27:22 yep.. thanks. 2018-02-27 15:28:08 I’d like to know why I have quite often problem with Alpine not booting after upgrade, this time syslinux cannot find configuration file… I’ve been using syslinux even on Gentoo for 5 years and never had such problem 2018-02-27 16:06:15 difficult to know based on the above info 2018-02-27 16:06:35 why didn't syslinux find the config? 2018-02-27 16:07:49 I don’t know, i can’t figure it out 2018-02-27 16:07:58 I can boot it when i manually enter the kernel line 2018-02-27 16:08:08 so it can find vmlinuz and initrd 2018-02-27 16:08:30 it may be also caused by that shitty OpenNebula :( 2018-02-27 16:11:12 vanilla kernel? 2018-02-27 16:11:32 i had issue with the vmlinuz -> vmlinuz-vanilla rename in my boot loader 2018-02-27 16:15:19 did you? i'm sorry if so 2018-02-27 16:16:45 not sure it was your fault 2018-02-27 16:16:46 i use gummiboot 2018-02-27 16:16:48 and the config is not generated 2018-02-27 16:16:49 i dont think we have trigger script for it 2018-02-27 16:17:03 and i dont think its worth implement either because gummiboot is sort of dead upstream 2018-02-27 16:17:22 i tried to "fix" that issue by create a vmlinuz symlink 2018-02-27 16:17:31 but that does not work if your /boot is on FAT 2018-02-27 16:17:31 eg UEFI 2018-02-27 16:17:41 so i reverted that 2018-02-27 16:18:23 ah i switched to grub2 a while ago 2018-02-27 16:19:08 i suppose i should too 2018-02-27 16:19:20 kind of wish someone picks it up, it's just so much cleaner than the monstrosity that is grub2 2018-02-27 16:20:55 gummi was sucked into systemd iirc 2018-02-27 16:21:30 thats what i meant with "sort of" 2018-02-27 16:23:51 that's what happened, yes 2018-02-27 16:25:12 jirutka: I did not have any boot problems with Alpine and Opennebula so far. 2018-02-27 16:26:47 jirutka: are you sure the problem is not related to your way you are using the whole /dev/sda without a partition table? 2018-02-27 16:29:03 bernhardgruen[m]: I don’t think so 2018-02-27 16:29:34 bernhardgruen[m]: I really think this case is really caused by some issue in our infra, b/c, well, we curently have many issues… 2018-02-27 16:29:41 with storage 2018-02-27 16:31:50 Maybe I can help. I am using Alpine and I need working systems. I also use opennebula and so I may be able to find a test case to debug it. 2018-02-27 16:33:06 but this does not happen on all VMs 2018-02-27 16:35:45 Does it happen for a newly generated VM already? 2018-02-27 16:36:04 Or does it only happen with edge kernel? 2018-02-27 16:37:01 no, for old VMs 2018-02-27 16:37:14 as I said, when upgrading from older version (to stable, not edge) 2018-02-27 16:39:14 any objection to add nghttp2 support to curl? 2018-02-27 16:39:24 I could easily test 3.6 to 3.7 (virthardened kernel) 2018-02-27 16:43:47 bernhardgruen[m]: thanks for interest, but I think that it’s not worth the effort, this is some old VM installed manually (not by alpine-make-vm-image), cloned from another VM, and we have serious problems with Ceph now 2018-02-27 16:45:20 bernhardgruen[m]: when I wrote my complain it was right after it didn’t boot, but now when I checked that all configs are okay, manually running syslinux --install didn’t fix it etc. so it’s for 99 % not Alpine’s fault 2018-02-27 16:51:52 Ok. Did you have some read timeouts in ceph?, Jirutka? 2018-02-27 16:52:22 bernhardgruen[m]: I don’t operate the Ceph cluster, so can’t say 2018-02-27 16:52:47 bernhardgruen[m]: and really, this infra is currently in almost critical state and we’re currently building new one and preparing rebuild of this 2018-02-27 16:56:50 Oh, that does not sound that good. At the moment I am running a LizardFS Cluster as an alternative to Ceph. Maybe that's a solution for you too. I already packaged it for Alpine. ;) 2018-02-27 16:58:20 by the way, if you guys are interested in playing with apk-tools 2.10 2018-02-27 16:58:39 http://raccoon.dereferenced.org/repos/ 2018-02-27 16:58:52 if the apk offered here blows up your system, tough shit 2018-02-27 16:59:07 in other words, do not use these packages in production 2018-02-27 16:59:33 i have gone out of my way to ensure that using these packages in production is undesirable, such as hosting the repo out of my garage 2018-02-27 17:00:02 and while i do have a metro ethernet circuit to my house, if some idiot blows the breaker while doing laundry, the server hosting said repo may be down for a while 2018-02-27 17:03:22 kaniini: binaries are cheap. show me the code 2018-02-27 17:04:24 what about code 2018-02-27 17:04:34 https://git.alpinelinux.org/cgit/apk-tools/ 2018-02-27 17:04:35 it is just the normal apk-tools APKBUILD with a custom unpack 2018-02-27 17:07:17 http://raccoon.dereferenced.org/repos/APKBUILD.txt 2018-02-27 17:09:41 kaniini: how does that work with the ${COMMIT} variable? in pkgver? 2018-02-27 17:10:45 i just run 2018-02-27 17:10:49 kaniini: this does only work for git, right? (i.e. not for bazaar or mercurial) 2018-02-27 17:10:58 env COMMIT=... PKGREL=... abuild -r 2018-02-27 17:10:59 so the code is in upstream apk-tools code and i can build it myself…? 2018-02-27 17:11:06 you can do whatever you want in unpack() 2018-02-27 17:11:09 but it's horrible 2018-02-27 17:11:30 jirutka: code for what 2018-02-27 17:11:33 there is no subtrees code yet 2018-02-27 17:11:39 "by the way, if you guys are interested in playing with apk-tools 2.10" 2018-02-27 17:11:52 oh 2018-02-27 17:11:58 yes 2018-02-27 17:12:03 ok - thanks, kaniini This makes some of my packaging work easier. 2018-02-27 17:12:10 what is presently in git will become apk-tools 2.10 2018-02-27 17:12:16 after more stuff is added 2018-02-27 17:13:22 i made the repo because a few people wanted to try out apk list and see if it did better for their needs than apk search 2018-02-27 17:13:30 aha 2018-02-27 17:17:46 bernhardgruen: note that overriding unpack() is technically a policy violation 2018-02-27 17:18:31 kaniini: I thought so. But I need to package some (internal) legacy stuff. 2018-02-27 17:19:40 I really hope most of that (java) code dies before we use it in practice on alpine linux. 2018-02-27 17:26:17 what you guys think. about this situation. in order to run the test suite i need to compile the build as scons debug=1 but i want the release build also. suggestions? you think i need to change the code to build the tests for release or recompile the code in debug in check()? 2018-02-27 17:27:08 or just ship the debug build? 2018-02-27 17:28:03 koldbrutality: i dont like idea of rebuilding it in check 2018-02-27 17:28:38 can you do both builds in build() in different build trees? 2018-02-27 17:28:47 i was thinking about that 2018-02-27 17:28:50 does it support out-of-tree build? 2018-02-27 17:29:02 Is there a reason for not having the ZFS module on the virt and virthardened kernels? Also the new virt kernel depends on linux-firmware-* as it seems. 2018-02-27 17:29:17 i don't know... i can just duplicate both 2018-02-27 17:30:46 Natanael Copa: koldbrutality This in fact does not test the same code but only the version with debug code. This can be a difference. But I assume this will be no real issue for normal programs. 2018-02-27 17:31:05 imo don't bother with running tests if the testsuite binary is going to be different than the real one 2018-02-27 17:31:05 koldbrutality: but otoh, you'd be testing a different build than what the user ends up with 2018-02-27 17:31:23 what we are trying to do with check() is verify the real binary 2018-02-27 17:31:27 i just ship the debug then 2018-02-27 17:31:45 this is a game engine 2018-02-27 17:31:49 and no, do not just run $binary --version 2018-02-27 19:23:07 <_ikke_> We are doing an upgrade on bugs.alpinelinux.org, it will be offline for a few minutes 2018-02-27 21:50:11 koldbrutality: hi i am reviewing your stuff, are you around 2018-02-27 21:50:59 yeah but busy trying to fix godot's check() function. I can't switch git branch. 2018-02-27 21:52:24 ok 2018-02-27 21:52:51 koldbrutality: i can fix bear for you, i just wanted you to be aware of the review i left for future reference 2018-02-27 22:22:34 kaniini: this is not okay https://github.com/alpinelinux/aports/commit/14d028ef5e2f505291dbd744eb71b81cfc11d736#diff-750eb93fe928340442b0d9ea4b69e7cbR13 2018-02-27 22:22:43 good luck with bumping this 2018-02-27 22:23:51 kaniini: https://wiki.alpinelinux.org/wiki/APKBUILD_examples:Python#source 2018-02-27 22:25:01 i already fixed it 2018-02-27 22:26:03 it’s imo better to fix it right before merging 2018-02-27 22:26:32 and the !archcheck thing 2018-02-27 22:26:37 this is also bad https://github.com/alpinelinux/aports/commit/be409dcb9b03d61234bf59a9e264a622b376b5ef#diff-979a30223dd769bfb70838221be21dd0R17 2018-02-27 22:26:38 just didnt push yet 2018-02-27 22:26:39 because was trying to fix patchwork 2018-02-27 22:26:40 because patchwork sucks 2018-02-27 22:27:29 really 2018-02-27 22:27:38 I’m talking it qutie a long time that patchwork is unusable crap :P 2018-02-27 22:27:55 that is on the maintainer to deal with 2018-02-27 22:28:10 what? 2018-02-27 22:28:47 this is how to deal with hash in dirname https://github.com/alpinelinux/aports/blob/master/main/graphviz/APKBUILD#L30 2018-02-27 22:29:33 sure 2018-02-27 22:29:47 kaniini: sigh 2018-02-27 22:29:48 omfg 2018-02-27 22:29:51 what is this https://github.com/alpinelinux/aports/commit/6f33fb4651d968f69abbdd4303ff7a425e296316? 2018-02-27 22:30:01 testing/rakudo: new aport … and what is there…? 2018-02-27 22:30:12 totally unrealted changes in two other pkgs 2018-02-27 22:30:29 i’m rather gonna close it and go sleep 2018-02-27 22:31:14 that sounds like a good productive use of your time 2018-02-27 22:31:20 the PR was a mess, i had to clean it up somehow 2018-02-27 22:32:38 what about archcheck thing, why is it used? 2018-02-27 22:37:45 i didn't notice it on that one, but i fixed that too 2018-02-27 23:07:51 11:39:14 any objection to add nghttp2 support to curl? 2018-02-27 23:07:53 no none 2018-02-27 23:09:09 nghttp2 is support for HTTP2, right? 2018-02-27 23:09:22 if yes, then no objection 2018-02-27 23:09:33 (from me) 2018-02-27 23:09:38 yes 2018-02-27 23:11:41 yeah it is 2018-02-27 23:12:28 actually sort of surprised that wasn't in the adelie merge 2018-02-28 06:58:57 ncopa: THANK YOU FOR FIREFOX 58 2018-02-28 06:59:06 currently testing for you 2018-02-28 06:59:58 i'm also testing kaniini's apk 2.10 2018-02-28 10:15:45 mepholic: yw 2018-02-28 13:36:55 kaniini: do you have a solution for libressl missing cms function? 2018-02-28 13:42:57 what needs cms? 2018-02-28 13:43:46 ipxe 2018-02-28 13:43:52 to sign the images 2018-02-28 13:43:56 (somehow I can kinda tell kaniini's solution would be "use openssl") 2018-02-28 13:44:18 probably 2018-02-28 13:44:19 hmm 2018-02-28 13:44:26 but our openssl lacks it 2018-02-28 13:44:35 oh? 2018-02-28 13:44:46 how so? 2018-02-28 13:44:58 i dont think it has the openssl cmd at all 2018-02-28 13:45:03 because of limited config 2018-02-28 13:45:53 you mean iPXE needs an "openssl cms" command oslt, instead of a C API to use CMS? 2018-02-28 13:47:45 http://ipxe.org/crypto 2018-02-28 13:48:09 maybe there is another way, thats why im asking. 2018-02-28 13:50:17 oh, this is not a hard dependency, just an operational need to sign a binary? 2018-02-28 13:50:47 probably would be worth it to have an openssl-bin package with the openssl binary 2018-02-28 13:51:02 with cms support and everything you want to throw into it 2018-02-28 13:51:13 and have openssl-bin in ipxe's makedepends 2018-02-28 13:51:21 or wherever it's needed 2018-02-28 13:54:30 thats what i was expecting. 2018-02-28 14:22:20 so openssl does ship the openssl binary, but libressl replaces openssl so openssl does not provide it if you have libressl installed. 2018-02-28 14:22:51 libressl provides its own openssl binary? 2018-02-28 14:22:53 and i cannot remove libressl because its needed by something else... 2018-02-28 14:23:14 yes, libressl has an openssl binary of course. 2018-02-28 14:26:28 the only way would be to have a compat(or similar) subpkg with the openssl version of openssl binary and rename it to something different (openssl-compat/real or whatever) 2018-02-28 14:26:50 should probably rename that to libressl and provide a symlink that openssl can override. 2018-02-28 14:28:48 "provides: openssl-bin" 2018-02-28 14:29:15 or separate libressl's openssl binary into a libressl-bin package, conflicting with openssl-bin 2018-02-28 14:29:37 so you can have both the libressl and openssl libraries installed, but only one implementation of the openssl binary 2018-02-28 14:39:16 I think it would be better to have libressl-openssl (just like there are various libressl-lib* pkgs), where openssl binary would be provided with libressl- prefix, and libressl-openssl-compat, where this binary would be symlinked from mere openssl. such compat pkg would be the only one conflicting package. anyone installing libressl would get both (from depends), but those caring about more 2018-02-28 14:39:22 options and wanting original openssl (but maybe libressl's too for some reason), could be specific and go with libressl-openssl instead of libressl, so installing openssl wouldn't be a problem. 2018-02-28 14:48:41 What is the current reason to use libressl over openssl? I know that it is not possible to switch and recompile all packages in just one day. 2018-02-28 14:50:58 There isn't really one unless you specifically want the libtls API, which IIRC isn't available outside of libressl at the moment (aside from bearssl, maybe?) 2018-02-28 14:51:28 tbh both openssl and libressl need to die in a fire, since they're both awful. 2018-02-28 14:52:34 But openssl seems to be used more often in the wild, right? 2018-02-28 15:27:22 bernhardgruen[m]: there's a discussion thread about it on the alpine-devel mailing-list 2018-02-28 15:27:59 tl;dr: Alpine switched to libressl at a time when it made sense, but today those reasons are less valid 2018-02-28 15:28:31 Aerdan[m]: no, bearssl doesn't have a libtls API, but I plan to write a wrapper at some time 2018-02-28 15:59:39 ncopa: am I missing something or did you forget to push the patch https://git.alpinelinux.org/cgit/aports/tree/main/alpine-conf/0001-update-kernel-handle-vanilla-suffix-in-System.map-co.patch to the alpine-conf repository? 2018-02-28 16:07:28 oh, maybe I misremembered who else had one (or recalled wrongly /that/ there was another impl). 2018-02-28 16:16:04 maybe there's another impl, but I don't know about it, and it's certainly not over bearssl. 2018-02-28 17:10:35 skarnet: I just read the mail archive. From my point of view an open policy (i.e. using both libraries for community builds) could make a possible switch easier. That way only the rather small part of main packages need a forced rebuild to openssl. 2018-02-28 17:17:07 ncopa: Have we considered before making the initramfs, that allows installing a SSH server, instead of searching for a boot media (ISO), then user can ssh into that and run #setup-alpine? Because I am going to do that and wonder if it was considered before. 2018-02-28 17:21:57 probably for some installation where direct user's input is prohibited/limited. 2018-02-28 17:54:19 bernhardgruen: there is already an open policy 2018-02-28 17:54:38 by default, most maintainers use libressl because they don't want to pull in openssl 2018-02-28 20:08:58 I don't know the exact process for moving packages from testing to community, but Adélie would greatly appreciate these being moved: https://bpaste.net/raw/5599f4e88670 2018-02-28 20:12:36 ncopa can you please restart the ppc64le builders 2018-02-28 20:42:08 mksully222: ask in #alpine-infra 2018-02-28 20:42:20 leitao should be able to start the ppc64le builder too 2018-02-28 20:52:15 kaniini: https://github.com/alpinelinux/aports/pull/3026#issuecomment-368656010 can not see the original series before flattening, but are we sure all hunks in musl-support.patch are unneded? 2018-02-28 20:52:55 if not I have rebased musl-support.patch to 4.10 and can push it 2018-02-28 20:57:45 AWilcox[m]: contact the maintainer of each package 2018-02-28 20:59:39 i can move them 2018-02-28 21:00:23 AWilcox[m]: regardning texlive https://github.com/alpinelinux/aports/pull/3004 2018-02-28 21:00:43 kaniini: did you testbuild firefox-esr? 2018-02-28 21:01:17 looks like its blocking the builder 2018-02-28 21:01:32 probably because of gconf3 transition 2018-02-28 21:04:22 let me check on what we can do there 2018-02-28 21:06:26 Ah okay thanks HRio. 2018-02-28 21:08:24 checking MOZ_GCONF_CFLAGS... Package ORBit-2.0 was not found in the pkg-config search path. 2018-02-28 21:08:27 i see 2018-02-28 21:08:51 an unannounced transition broke it 2018-02-28 21:09:22 i think we need to generate better pc: dependencies in abuild to prevent this in future 2018-02-28 21:09:42 --print-depends in pkgconf can be used in combination with scanning the .pc files 2018-02-28 21:09:56 we need fix gconf package to pull in orbit2-dev package 2018-02-28 21:10:47 So I guess https://github.com/alpinelinux/aports/pull/3434 was somewhat accurate then 2018-02-28 21:11:44 But I think yes, orbit2-dev in depends_dev 2018-02-28 21:12:49 i fixed it 2018-02-28 21:12:57 but the pc: dependency topology needs to be better 2018-02-28 21:19:10 bump https://github.com/alpinelinux/aports/pull/3052? (tagged: A-move + A-fix) 2018-02-28 21:39:27 A. Wilcox: it was sort-of accurate yes