2018-05-01 09:59:40 kaniini: does gzip really need coreutils for checks? 2018-05-01 10:00:08 commit c6f4cfa642e9cbcb114344cc7a8dedf63acab681 2018-05-01 10:00:09 Author: William Pitcock 2018-05-01 10:00:09 main/gzip: reconcile checkdepends between adelie-base and alpine-base 2018-05-01 10:00:09 Date: Sat Feb 10 02:48:42 2018 +0000 2018-05-01 10:00:18 it introduces circular deps 2018-05-01 10:18:29 ncopa: yes, it really does 2018-05-01 10:19:10 it seems to work for me without? 2018-05-01 10:27:17 more circular deps: automake has checkdepends="bash gzip coreutils diffutils" 2018-05-01 10:27:29 but also options="!check" 2018-05-01 12:53:57 ollieparanoid[m]: im pushing qt 5.10 now 2018-05-01 12:54:45 i need to fix qtwebengine too, but i think i can push the others first 2018-05-01 13:10:17 ncopa: great. hope chromium 66 comes next. 2018-05-01 13:10:39 need get the 3.8 builder up and run first 2018-05-01 13:10:50 i have looked at chromium a couple of times, but its a bit tricky 2018-05-01 13:11:08 and im a bit tuck tbh 2018-05-01 13:11:12 stuck* 2018-05-01 13:11:44 if they didn't add linux video hardware acceleration, I wouldn't even ask. 2018-05-01 13:13:33 I ported Pale Moon to Alpine but I'm a bit reluctant to create PR. 2018-05-01 13:14:22 I think that it's going to be rejected. 2018-05-01 13:14:28 :) 2018-05-01 13:15:09 Even though PM dev, checked the my mozconfig 2018-05-01 13:16:56 ncopa: It buggered me and dig into the issue. Even created a tuto, so once I sorted out every detail, I'll be glad to post it on the forum 2018-05-01 13:17:44 Sorry, wrong channel 2018-05-01 13:19:16 I could help on chromium but it requires very powerful system to compile 2018-05-01 13:21:45 chromium is a monster indeed 2018-05-01 13:28:59 oh yes it is 2018-05-01 13:29:02 just look at the patchset we use lol 2018-05-01 13:36:44 ncopa: qt5-multimedia still uses gstreamer0.10 2018-05-01 13:36:58 oh 2018-05-01 13:37:24 propably you forgot it 2018-05-01 13:37:32 i did... sorry 2018-05-01 13:38:45 no problem. I just checked. 2018-05-01 14:00:00 If a new system group needed, which install-script must create this group for both new and existing installs? 2018-05-01 14:07:13 i have done pre-install and symlink pre-upgrade 2018-05-01 14:13:00 ncopa: thanks. that was what I thought. 2018-05-01 14:16:56 ncopa: btw, I asked this for plugdev group and networkmanager issue 2018-05-01 14:44:06 armhf and x86 builde servers for v3.8 are up 2018-05-01 15:23:38 x86_64 and s390x build servers for v3.8 is up too 2018-05-01 15:25:31 ERROR: qt5-qtx11extras-5.10.1-r0: trying to overwrite usr/lib/libQt5X11Extras.so.5 owned by qt5-x11extras-5.9.3-r0. 2018-05-01 15:25:52 ah 2018-05-01 15:25:55 due to the rename 2018-05-01 15:25:59 "apk fix" helps to solve anyway 2018-05-01 15:27:43 same problem with qt5-qtwebsockets 2018-05-01 15:28:02 ncopa: s390x builder still on the current server ? 2018-05-01 15:28:24 yes 2018-05-01 15:28:32 i guess we can move it when new machine is up 2018-05-01 15:28:48 many thanks 2018-05-01 15:29:00 tmh1999: were you able to reproduce the sudo testsuite problem? 2018-05-01 15:29:31 I have many fixes for current disabled packages/tests on s390x pending for new server. can't believe these people ... 2018-05-01 15:29:44 I could 2018-05-01 15:30:36 I'm looking for another source 2018-05-01 15:32:10 has anyone noticed that openttd on alpine just dies after some minutes play? 2018-05-01 15:33:00 nope 2018-05-01 15:33:31 mh, its in testing, i'll investigate 2018-05-01 15:35:05 I also ported UrbanTerror but I couldn't decide to depend it 900MB -data package. Any rules about user contributed packages regarding package size? 2018-05-01 15:43:51 It looks like there is something wrong with the mupdf package - at least it's not working for me 2018-05-01 19:14:52 Can someone maybe confirm the issue with mupdf-1.11-r1 - or am I doing something wrong? 2018-05-01 19:42:00 jirutka: Should we do if/else for each arch to when choosing build target for llvm, instead of building everything by default with DLLVM_TARGETS_TO_BUILD ? 2018-05-01 19:42:57 or llvm will automatically pick up the build target itself on each arch ? I'm an expert in this. 2018-05-01 23:13:01 is anyone be able to build OpenBLAS master branch on x86_64 ? 2018-05-01 23:26:06 ncopa: thanks! would it be possible to send out a mail to alpine-devel a few days before the next qt update? 2018-05-01 23:26:11 ncopa: regarding qt5-qtwebengine: we had it with qt5.9 working, maybe these musl patches are helpful: https://github.com/postmarketOS/pmbootstrap/tree/26a0a018ca99cf315d9c94990e585fb09526d139/aports/main/qt5-qtwebengine/patches-musl 2018-05-01 23:58:23 no worries, just another day, another PEBKAC. 2018-05-02 06:53:11 ollieparanoid[m]: i will try remember that for qt 5.11 2018-05-02 07:43:37 ollieparanoid[m]: those patches for qtwebengine was helpful, thanks! 2018-05-02 07:43:43 i had issues with yasm 2018-05-02 10:07:13 the builderes for v3.8 is up 2018-05-02 10:07:21 i am thinking of how to report build errors 2018-05-02 10:07:50 i think we initially want continue-on-error so we build as much as we can 2018-05-02 10:08:18 but that will create lots of errors due to missing dependencies and we dont want to spam #alpine-commits 2018-05-02 10:09:01 i think what i'll do for now is to disable reporting build failures for build-3-8-* on irc 2018-05-02 10:09:25 while figuring out a way to collect all errors 2018-05-02 10:09:41 and then publish a list 2018-05-02 11:49:43 hey friends 2018-05-02 11:50:06 i have a strange problem, every 3 weeks or so my mariadb server crashes without any traces in the log file or somewhere else 2018-05-02 11:50:13 has someone else noticed this problem? 2018-05-02 11:50:19 i am on edge 2018-05-02 11:50:23 x64 2018-05-02 11:50:39 I'd be on edge too if it happened to me 2018-05-02 11:51:22 does it happen to you? 2018-05-02 11:52:04 it doesn't, but I don't use mariadb so that's not a helpful data point for you 2018-05-02 12:01:52 indeed 2018-05-02 12:06:22 i havent seen it 2018-05-02 12:09:26 hmm, very strange 2018-05-02 12:11:03 "without any traces in the log file or somewhere else" --- can't you set you system up so that it writes a coredump when this happens? 2018-05-02 12:11:21 you should probably enable coredumps 2018-05-02 12:14:13 ncopa: i have core dumps enabled. there is no core dump. That causes me to beleave that the daemon crashesin a way where a core dump cannot be written (maybe getting killed by grsec disabled core dumps in some cases) or that is just shutsdown normally without any reason 2018-05-02 12:16:50 nothing in dmesg either? 2018-05-02 12:17:31 no sir, i only have an error message regarding a php segfault, but nothing for mariadb/mysql 2018-05-02 12:19:16 thats why this is confusing me so much ... this started a year ago or so ... and i never found anyhthing in the logs 2018-05-02 12:19:40 it's just an internal development server, but it's still anoying because my coworkers always call me about the when i am sleeping *g* 2018-05-02 12:27:01 tmh1999: feel free to upgrade openblas, but don’t forget to rebuild all dependent pkgs 2018-05-02 12:28:02 fcolista: I don’t know what is -gns3 :/ 2018-05-02 12:31:31 tmh1999: "Should we do if/else for each arch to when choosing build target for llvm, instead of building everything by default with DLLVM_TARGETS_TO_BUILD ?" … no, it’s useful for cross-compiling 2018-05-02 12:33:23 ncopa: kaniini: I’m sad that I didn’t get any feedback re https://github.com/jirutka/apk-autoupdate/ from you :( 2018-05-02 12:33:57 i had a short look at it. it looks ok 2018-05-02 12:34:03 i didnt have time to dig deeper 2018-05-02 12:35:06 what is good: you have written documentation. it does not have many dependencies. its implemented as a separate package instead of built into apk 2018-05-02 12:36:03 I’m also interested what is bad, so I can fix/improve it :) 2018-05-02 12:36:12 oh that was the C code you did 2018-05-02 12:36:34 yes, procs-need-restart is written in C 2018-05-02 12:39:47 it looks like it automatically restart services? 2018-05-02 12:40:25 yes… automatic upgrades without restarting affected services are quite useless 2018-05-02 12:40:52 but you can specify what services can or cannot be restarted 2018-05-02 12:41:20 can you disable it all? 2018-05-02 12:41:33 ofc 2018-05-02 12:41:57 it supports wildcards https://github.com/jirutka/apk-autoupdate/blob/master/man/autoupdate.conf.5.adoc#variables 2018-05-02 12:42:33 i was thinking of running apk-autoupdate --skip-restart or similar 2018-05-02 12:42:54 and just get a list of what services that needs restart 2018-05-02 12:43:04 that wouldn’t make much sense, it’s supposed to be run by cron 2018-05-02 12:43:17 yes, you always get this 2018-05-02 12:43:36 its sort of convenient wrapper for people who likes to apk upgrade -U -a manually 2018-05-02 12:43:59 the benefit here woudl be to get a list of what services needs to restart after the upgrade 2018-05-02 12:44:02 then you can just use https://github.com/jirutka/apk-autoupdate/blob/master/man/procs-need-restart.1.adoc directly 2018-05-02 12:44:25 and pipe it into https://github.com/jirutka/apk-autoupdate/blob/master/src/rc-service-pid.in to get list of services instead of just PIDs 2018-05-02 12:45:21 right, so soemthing like: apk upgrade -U -a && procs-need-restart | rc-service-pid 2018-05-02 12:45:31 however, by default all services are blacklisted, so when you run apk-autoupdate without touching config, it will upgrade all pkgs except linux-* and list services that you should restart 2018-05-02 12:45:49 ok 2018-05-02 12:45:50 nice 2018-05-02 12:46:11 maybe look at this https://github.com/jirutka/apk-autoupdate/blob/master/src/apk-autoupdate.in#L208-L256 2018-05-02 12:46:52 yes i saw that, just missed that all services are blacklisted by default 2018-05-02 12:47:57 however, services_blacklist and services_whitelist are currently quite confusing, I need to rework this part, but I want to keep all services blacklisted by default to prevent accidental isuses 2018-05-02 12:49:07 and it has also --simulate mode ;) 2018-05-02 12:49:30 (actually just -s, no --options here) 2018-05-02 13:05:05 jirutka: thanks! 2018-05-02 13:48:21 so, i want to collect the build errors from mqtt and publish them som place 2018-05-02 13:48:41 so we can find the build logs 2018-05-02 13:49:18 but i think we want to keep the errors for a short time 2018-05-02 13:49:30 mqtt messages only keep the last build error 2018-05-02 13:50:12 this can be done in a json file in /tmp or sqlite database 2018-05-02 13:50:40 or something in /var/spool/ 2018-05-02 13:52:13 the nice thing with a json file is that the web page presenting the build errors can be static 2018-05-02 14:45:25 ncopa, would it be possible to record if we have run check in apk metadata? 2018-05-02 15:57:20 TBB: Did you try Connman before? 2018-05-02 18:20:08 ncopa: I'm glad the patches were helpful - could you upload your WIP version of qt5-qtwebengine with 5.10? (we can't use the version from Alpine for this one, because we need LuneOS UI specific patches as of now) 2018-05-02 18:36:30 easy-rsa with libressl is broken :-/ 2018-05-02 18:37:06 voidlinux got rid of easy-rsa because of that 2018-05-02 18:37:15 https://github.com/OpenVPN/easy-rsa/issues/74 2018-05-02 18:37:15 https://github.com/voidlinux/void-packages/issues/7478 2018-05-02 18:37:27 113665925188556:error:0EFFF068:configuration file routines:CRYPTO_internal:variable has no value:conf/conf_def.c:563:line 3 2018-05-02 18:38:12 I’d prefer to get rid of LibreSSL instead, it would solve tons of other issues… 2018-05-02 18:38:39 jirutka, i don't think is doable for 3.8.. 2018-05-02 18:38:55 but package is in community and it's broken 2018-05-02 18:39:06 yeah, unfortunately it’s not, due to ncopa‘s decision 2018-05-02 18:39:13 it’s not the only package broken due to LibreSSL (update) 2018-05-02 18:40:20 probably we should ship also a static openssl package 2018-05-02 18:56:30 oh we have already a bug report on this.. 2018-05-02 18:56:30 https://bugs.alpinelinux.org/issues/6477 2018-05-02 19:09:56 last time i looked at easy-rsa it didnt look like very difficult to fix it 2018-05-02 19:10:05 but i dont have time for it 2018-05-02 19:12:25 Yes, I heard that from other users too... Gentoo takes times to maintain... 2018-05-02 19:12:37 sorry, wrong channel 2018-05-02 20:13:51 gcc 8.1 out 2018-05-02 21:42:16 danieli: o/ 2018-05-02 21:42:28 \o 2018-05-02 21:42:44 danieli: what prevents us from upgrading gcc ? Last time there was a discusion but I didn't get it 2018-05-02 21:42:54 idr the details 2018-05-02 21:42:57 kind of late for you over there 2018-05-02 21:43:04 okay 2018-05-02 21:43:13 iirc it has some thing to do with the kernel 2018-05-02 21:58:32 gcc was not upgraded because nobody had time to make a gcc6 package with gcc-java so we can bootstrap openjdk 2018-05-02 21:59:05 gcc7 and later does not provide gcc-java 2018-05-02 21:59:33 also it was so late that we decided to wait with the upgrade 2018-05-02 22:09:35 can someone help me iwth openvswitch? the test suite leaves varioius processes running 2018-05-02 22:09:58 maybe a killall ovsdb-server or similar at the end of make check 2018-05-02 22:31:53 yes right gcj thing 2018-05-02 22:32:19 let me see if I could do something 2018-05-02 23:52:25 last time the idea was to create a package like main/gcj right ? and gcc can move on to newer version 2018-05-02 23:52:38 that sounds right 2018-05-03 00:10:58 or guess what, could we just move main/gcc to main/gcc-6.4 ? 2018-05-03 00:37:01 I’d personally prefer main/gcj and build gcc with gcj only if possible 2018-05-03 01:21:54 jirutka: that sounds better. 2018-05-03 01:22:14 iirc there was a discusion on this that had a pretty good solution 2018-05-03 01:23:02 checking irc log 2018-05-03 02:13:11 fabled: Would you mind reminding me about the state of go-bootstrap, at least on s390x for example ? Does community/go can be built on it own source ? Last time iirc we need go-1.4 with the bootstrap code written in C. 2018-05-03 02:16:45 seems like it could be built on its own 2018-05-03 04:10:11 no 2018-05-03 11:51:49 i 2018-05-03 11:55:13 oops 2018-05-03 13:03:36 my colleague: “I have very minimal Gentoo system for running LXC, just about 300 packages”; I literally burst out laughing 2018-05-03 13:04:11 Gentoo is rather beefy with fewer packages than that 2018-05-03 15:42:59 is there anyone running Linux on desktop? 2018-05-03 15:43:22 What do you mean? 2018-05-03 15:44:01 I need copy of /proc//maps with entries such as /SYSV0000*, /shm* etc. 2018-05-03 15:44:18 e.g. Chromium uses this 2018-05-03 15:45:33 jirutka: I do 2018-05-03 15:46:48 what you need 2018-05-03 15:46:52 mps: could you please find some process that use shared memory, look into /proc//maps if there are some entries like /SYSV000*, /shm* etc. and send me dump of this? 2018-05-03 15:47:22 just moment 2018-05-03 15:50:23 ok, found some 2018-05-03 15:51:59 where and how to send 2018-05-03 15:52:45 use e.g. https://dpaste.de/ 2018-05-03 15:53:52 what would you prefer, X server, awesome wm or evince 2018-05-03 15:54:45 I don’t care, just some process with /SYSV00000000, /shm*, /drm* and similar weird entries 2018-05-03 15:55:38 http://tpaste.us/lWD6 2018-05-03 15:56:13 evince maps, I have tpaste cli installed, hope the URL is ok for you 2018-05-03 15:56:53 thanks! 2018-05-03 15:57:04 do you have some process with /shm* or /drm*? 2018-05-03 15:57:50 only /proc/sysvipc/shm 2018-05-03 16:01:10 mps: what do you have in /proc/devices? 2018-05-03 16:01:56 http://tpaste.us/dVyL 2018-05-03 16:02:48 devices list is at the URL above 2018-05-03 16:13:30 it looks that all these weird mappings have major device number 0 2018-05-03 16:13:39 that’s good, I can easily identify them 2018-05-03 16:56:18 gcc/APKBUILD runs $ patch -F3, thus patch like https://git.alpinelinux.org/cgit/aports/tree/main/gcc/gcc-4.8-build-args.patch turns out to very 'wrong' meaning 2018-05-03 16:56:40 it just blindly inserts at at line 11720 2018-05-03 16:57:51 the original purpose of the patch is to insert BUILD_CXXFLAGS at that if-else block 2018-05-03 16:59:02 I think I should just remove this patch. That if-else was patched with (CXXFLAGS_FOR_BUILD) since 6.4.0 2018-05-03 17:06:23 anyone on who can merge the bugfix https://github.com/alpinelinux/aports/pull/4191 ? 2018-05-03 17:10:55 oh, yeah, that reminds me of one thing... I do package things every now and then but I'm not familiar with the workflow; I think I've only sent some APKBUILDs privately or filed fix suggestions without patches so far 2018-05-03 17:12:32 so, help a noob and tell me how I should -actually- do it. I suppose wrt new packages I can just submit the APKBUILD to the issue db? 2018-05-03 17:16:04 https://github.com/alpinelinux/aports/blob/master/.github/CONTRIBUTING.md 2018-05-03 17:16:08 TBB: ^ 2018-05-03 17:16:26 but i don't know if that's still accurate 2018-05-03 17:16:44 i have two PRs open since more than two months and still no sign of them getting any attention 2018-05-03 17:17:20 Fusl: everyone is busy for new release and we are short-staffed atm 2018-05-03 17:17:43 that CONTRIBUTING doc is still correct 2018-05-03 17:17:56 thank you, both of you 2018-05-03 17:17:59 TBB: sent some APKBUILDs privately? 2018-05-03 17:18:51 we have TBB here and TBK on github. same person ? 2018-05-03 17:19:47 What would suggest so? 2018-05-03 17:20:28 jirutka: there's a package or two in aports with me as contributor; I submitted them via one of the devs as they were basically just for the purpose of him not having to do them himself (and for my own testing), and they were quite poorly done 2018-05-03 17:20:31 Fusl: hm, I should visit guys in CZ.NIC and explain them to not stupidly expect that everyone builds their soft from their git repo, god damn >_< 2018-05-03 17:20:51 tmh1999: nope, I'm not yet on github 2018-05-03 17:22:58 now I pretty much have the permission from my project to submit ports to Alpine... wasn't that clear before 2018-05-03 17:32:46 jirutka: totally agree, and thanks for the quick merge 2018-05-03 23:40:50 ncopa: We're trying to make a custom "microkernel" for bare-metal provisioning using Puppet's Razor software. We're working with Alpine Vanilla 3.7 on ppc64le. Basically need a custom iso based on Vanilla that has additional software vendored, custom service scripts, a couple of ruby gems installed, etc. We need to get at the vmlinuz and initrd/initramfs in /boot afterward to package them up in a specific format. 2018-05-03 23:41:34 We're able to make an iso with mkimage, but must be doing something wrong with our apkvol because we just end up with a vanilla initramfs with none of our apks vendored in there. 2018-05-03 23:41:36 https://github.com/mtarsel/alpine-vanilla-ppc64le 2018-05-03 23:42:26 wondering if mkintfs is something we need to use. 2018-05-03 23:42:38 *mkinitfs 2018-05-04 06:32:52 fabled: I'm working on upgrading gcc7 2018-05-04 06:33:34 wondering if this patch is still needed : https://git.alpinelinux.org/cgit/aports/tree/main/gcc/gcc-4.8-build-args.patch 2018-05-04 06:34:19 apparently with patch -F3, this patch just blindly applies to line 11720 and has nothing to do with that if-else block at all 2018-05-04 06:34:31 it happens also in gcc-6.4 2018-05-04 07:25:22 tmh1999, it has been for the bootstrap script 2018-05-04 07:26:36 fabled: I agree. but what I mean is, it should be put into proper if-else clause at it should be. I mean -F3 option in patch does make patching process work but the semantics is not maintained. 2018-05-04 07:26:59 just rebase the patch? 2018-05-04 07:28:19 yeah that might work 2018-05-04 07:34:15 fabled: how do you think ? http://tpaste.us/aMNM 2018-05-04 07:34:41 probably ok if it works still 2018-05-04 07:35:17 okay cool I'll careful with this. Will cc you in github pr :D. Thanks 2018-05-04 08:23:13 nice, scaleway has updated its images to 3.7 and now uses custom kernel. 2018-05-04 08:23:21 jirutka, ^ 2018-05-04 08:48:40 anyone know if there is a specific reason we prefer chronyd over busybox ntpd? 2018-05-04 09:36:27 clandmeter: I don't know why AL developers prefer chrony but I agree with them because it is more secure and better maintained than ntpd code (though I don't know how it is maintained in busybox) 2018-05-04 09:38:47 mps, im sorry but your arguments are vague. 2018-05-04 09:40:21 I know, but that is just my view or small note, noting more 2018-05-04 14:20:14 clandmeter: why is there a need for custom kernel ? I thought it should be running as-is, or at least I could upload my own Alpine image. I'm about to open a Scaleway account btw 2018-05-04 14:22:15 Before you needed to run their kernel 2018-05-04 16:49:56 jirutka : can you remove 'S-unwanted' tag from #4188 please? 2018-05-04 16:51:55 I updated the PR. 2018-05-04 22:53:26 jirutka: I've an update for you regarding the WSL App. The current stable version of Windows has a bug within the api. It prefixes every command with "/bin/bash -c". Would it be possible to have an official tar.gz "mini root fileystem" with bash? I've requested to backport the fix, but the microsoft employee was not really convinced of that. 2018-05-04 22:54:58 agowa338: I don’t think so; prefixing every command with "/bin/bash -c" is so stupid that I’m quite speechless 2018-05-04 22:55:42 It's fixed in the current insider versions, but not in the 1803 version which was released a few days ago... 2018-05-04 22:56:15 how long is the release cycle, i.e. when they’re gonna release new version? 2018-05-04 22:56:28 in 1/2 a year 2018-05-04 22:56:43 uh, aha 2018-05-04 22:57:21 Technically it is possible to include the newest version of the wslapi.dll within the app, but store rules prevent that... 2018-05-04 22:57:26 maybe it’d be better if we make special rootfs for WSL 2018-05-04 22:58:06 If so, including shadow would be great, because currently I'm installing it while deploying... 2018-05-04 22:58:08 I wanna go sleep now, could you please give me your email so I can contact you when you’re not on IRC? 2018-05-04 22:58:45 jirutka: you got pm 2018-05-04 22:59:16 yup 2018-05-04 22:59:57 If the /bin/bash commands don't actually contain any bashisms, you might be able to work around it by symlinking /bin/bash -> /bin/sh (which you can do without repacking the whole tarball using tar -r) 2018-05-04 23:00:17 Actually, that won't work since /bin/sh is a symlink to busybox, which checks argv[0] to see what to run 2018-05-04 23:01:17 pardis: doesn't work, because /bin/sh is already a symlink to busybox and busybox errors out. 2018-05-04 23:02:21 well, you can create simple script /bin/bash with just `exec /bin/bash "$@"`, but that would be very hackish, we can’t assume that they will not pass some nasty bashisms to it 2018-05-04 23:04:02 well, that such a simple script would work, but it needs to be within the tar.gz before deploying, as any command will fail because it is prefixed with "/bin/bash -c", except the interactive propt, that one for some reason works... 2018-05-04 23:05:41 special rootfs for WSL is the way to go, I’ll do it once have some time 2018-05-04 23:05:45 sleep now, gn! 2018-05-04 23:06:04 agowa338: and thanks for taking care of this! 2018-05-04 23:06:58 jirutka: gn, and no problem, that what thouse windows people are good for :p 2018-05-04 23:46:42 anyone knows 'HRio' on github ? 2018-05-04 23:46:51 wonder what's his name on IRC 2018-05-04 23:51:37 https://dev.alpinelinux.org/irclogs/%23alpine-devel-2018-02.log show his name is also 'HRio' but /whois HRio doesn't show 2018-05-06 19:30:02 can a subpackage have a version different from the main package version? 2018-05-06 19:31:27 mitchty: no 2018-05-06 19:32:12 hrm, trying to figure out how i'm going to deal with ghc 8.6 where i'll need to have cabal to bootstrap a new ghc 2018-05-06 19:32:31 it'll be like rust with cargo 2018-05-06 19:33:25 hm :/ 2018-05-06 19:33:26 the easiest would be to have ghc itself build cabal once ghc is built 2018-05-06 19:34:24 well, it’d not be the first package providing some bundled thing with version of the origin instead of the thing 2018-05-06 19:34:42 we have similar situation e.g. in ruby package 2018-05-06 19:34:47 will have in rust package 2018-05-06 19:35:00 well its not bundled really, its just when building ghc, i'll need cabal installed 2018-05-06 19:35:02 also have in python3 package 2018-05-06 19:35:09 or to build it at build time 2018-05-06 19:35:13 aha, cyclic deps 2018-05-06 19:35:22 yeah 2018-05-06 19:35:28 can you build statically linked cabal? 2018-05-06 19:35:37 yeah thats not the hard part 2018-05-06 19:35:48 it would be easiest to build cabal while building ghc though 2018-05-06 19:36:05 its just cross compiling would be... rather not 2018-05-06 19:36:15 ok, then you can build statically linked cabal, upload it to dev.a.o and use in apkbuild for bootstrapping 2018-05-06 19:36:18 making it a subpackage would be easiest 2018-05-06 19:36:23 that’s what i currently do in the case of cargo 2018-05-06 19:36:33 well i still hit the issue of boostrapping then 2018-05-06 19:36:40 bootstrapping rather 2018-05-06 19:37:12 it must be handled specially, there’s probably nothing we can do :/ 2018-05-06 19:38:29 would be nice if i could just build it as a subpackage, means just need to bootstrap ghc with no special sauce 2018-05-06 19:38:50 the it'll build itself on native platform and build its cabal as well 2018-05-06 19:40:25 so general question then on cyclic dependencies such as this and bootstrapping, any example apkbuilds I should look to? 2018-05-06 19:41:32 currently there’s cyclic dep between rust and cargo 2018-05-06 19:42:00 when bootstrapping, rust must be handled specially, i.e. installed from existing package 2018-05-06 19:42:18 gotcha 2018-05-06 19:42:30 so another possible sequence would be bootstrap ghc 2018-05-06 19:42:40 actually, maybe I broken the cycle using static cargo, don’t remember now 2018-05-06 19:42:50 then to build native ghc you'll need to build cabal, then ghc again and then might as well rebuild cabal 2018-05-06 19:43:03 anyway, there’s no magic to handle this, we just have to add ghc to list of special cases for bootstrapping… 2018-05-06 19:43:11 doesn't need to be fully static though for cabal, just haskell static libs 2018-05-06 19:43:27 which is the default, but could be fully static if wanted 2018-05-06 19:44:22 and as a note, im going to drop armhf from ghc for now, bootstrapping ghc 8.6 will not be possible from 8.0, and armhf is the thing holding that back 2018-05-06 19:44:43 for example in the case of cargo, static binary is necessary, because cargo links TLS libs, so if it would be linked dynamically, then this binary used for bootstrapping will stop working after LibreSSL upgrade… 2018-05-06 19:44:50 so basically i need to get an update in at least to 8.4 now, and help debug armhf 2018-05-06 19:45:05 ah 2018-05-06 19:45:22 i forget what cabal has for libs, let me look 2018-05-06 19:46:19 just libz/gmp/ffi/libc 2018-05-06 19:46:25 so dynamic should be fine 2018-05-06 19:46:55 and i could remove gmp if we really needed to, ffi possibly as well 2018-05-06 19:47:19 but the new build system is nice in that it produces relocatable binaries 2018-05-06 19:47:42 and should make cross compiling a bit easier 2018-05-06 19:47:53 not tried that yet however 2018-05-06 20:55:03 I have problems building the networkmanager package. or rather, the built package contains a "NetworkManager" binary that defines no dynamic symbols but these are needed for loading plugin .so files and the package in the (edge) repo also defines them. has there been anything changed recently that could explain this difference? 2018-05-06 20:59:17 Or in other words: with my package, "nm -D --defined-only /usr/sbin/NetworkManager" has no output but with the package from the repo this lists quite some symbols (as it should be) 2018-05-06 22:24:43 michitux[m]: you seem to be using Matrix, please join #alpine-devel:alpinelinux.org rather than #freenode_#alpine-devel:matrix.org 2018-05-07 05:32:43 ncopa: grpc 1.11.0 seems need the same patch https://github.com/hrnr/aports-1/blob/master/testing/rethinkdb/libressl.patch 2018-05-07 05:34:42 and this patch https://github.com/grpc/grpc/pull/13522/commits/21c4bb67f8dbe7f60f86b04f93939a5baae1d36e is these patch are acceptable or there are better solutions ? 2018-05-07 06:25:07 my mistake, I should use the edge to build the package, with libressl 2.7, everything is fine. 2018-05-07 10:42:26 Hm. I made a change to mkinitfs, so one can have xfs_repair in the recovery shell. Would this be a good change? https://github.com/refacto/mkinitfs/commit/7c4901286883dce44670dafb8c434bc1c1e7d1c2 2018-05-07 10:44:14 (this change could've helped me in a sticky situation yesterday ;) ) 2018-05-07 10:51:33 azarus: sounds like a good idea to me 2018-05-07 10:51:59 ncopa: great to hear. Should I make a PR? 2018-05-07 10:53:40 i think i can use https://github.com/refacto/mkinitfs/commit/7c4901286883dce44670dafb8c434bc1c1e7d1c2.patch 2018-05-07 10:53:44 so not needed 2018-05-07 10:54:06 Ah, cool. 2018-05-07 10:54:23 applied. thanks! 2018-05-07 10:54:49 You're welcome :) 2018-05-07 11:29:02 x86_64 build failures for v3.8/main: http://tpaste.us/Dez0 2018-05-07 11:52:38 ncopa: fix for main/ttf-ubuntu-font-family https://github.com/refacto/aports/commit/43f649621114f6aa7bf190d12c90bec41dfa83c4 2018-05-07 11:53:08 (also, that URL looks a bit sketchy, as it contains part of some checksum :/ ) 2018-05-07 11:56:18 i would prefer that source url does not include any hash, so we can upgrade by simply change pkgver 2018-05-07 12:01:41 Agreed. I don't see a URL that doesn't have it, tough. I'll look some more. 2018-05-07 12:08:15 Arch has that URL, so does Gentoo. Seems Canonical just isn't providing "clean" links anymore :( 2018-05-07 12:13:03 ok 2018-05-07 13:16:52 build failures for ppc64le: http://tpaste.us/gaQv 2018-05-07 13:28:00 ncopa: I'll start taking a look at these (ppc64le: http://tpaste.us/gaQv) 2018-05-07 13:28:18 great! thanks! 2018-05-07 13:29:08 you find the build logs here: http://build.alpinelinux.org/buildlogs/build-3-8-ppc64le/main/ 2018-05-07 15:27:30 I found fix for LLVM5 test failure 2018-05-07 15:30:19 ncopa: would you mind reviewing/merging : https://github.com/alpinelinux/aports/pull/4062, https://github.com/alpinelinux/aports/pull/4061 so I could these changes and install on the new builder ? 2018-05-07 15:38:46 4061 could wait but 4062 is needed, or else the builder will mix my packages (built with my keys) with official packages. 2018-05-07 15:41:23 <_ikke_> "o info and progress should go to the 2018-05-07 15:41:25 <_ikke_> standard output in general." 2018-05-07 15:42:07 <_ikke_> wrong channel, sorry 2018-05-07 15:42:08 _ikke_: context? 2018-05-07 15:42:16 ah right, im still interested tho 2018-05-07 15:42:19 <_ikke_> git 2018-05-07 15:43:02 <_ikke_> liwakura: https://public-inbox.org/git/xmqq604rzytx.fsf@gitster-ct.c.googlers.com/ 2018-05-07 15:45:25 this doesn't make sense to me, did he mean standard output? 2018-05-07 15:45:31 *standard error 2018-05-07 15:45:35 making the same mistake smh 2018-05-07 15:48:25 <_ikke_> Yeah, I was confused about that as well 2018-05-07 15:51:01 this is a nice feeling, after questioning your own sanity, getting assured that its not you 2018-05-07 15:51:32 <_ikke_> In the reply, they Thomas asks the same question, but no answer 2018-05-07 16:32:05 jirutka: do you have any recommendation for getting variable + values from $@ ? 2018-05-07 16:32:14 $@ might contain things like dasd=123 qeth=456 2018-05-07 16:32:34 I would like to get $dasd value, which is 123, for example 2018-05-07 16:33:20 don't know other cleaner way compared to what I did 2018-05-07 16:35:03 I think I will for loop through $@ and detect dasd and qeth then 2018-05-07 16:35:42 do you have pre-set values you want to gather or anything that has key=val in it? 2018-05-07 16:36:14 TBB: yes preset values in kernel parm and I want to extract them in init script 2018-05-07 16:38:17 I think the way initramfs-init does it is pretty clean 2018-05-07 16:38:47 tmh1999: I’ll look at it later 2018-05-07 16:39:16 so you just need to add those presets to myopts and the KOPT parser handles them nicely 2018-05-07 16:40:30 TBB: oops, you are right. I missed that. 2018-05-07 16:40:48 TBB: Thanks. that's way better 2018-05-07 18:26:26 mksully22: FYI, autoreconf should be called in prepare(), not build() 2018-05-07 19:09:20 jirutka: thanks, i'll add it there on any subsequent changes 2018-05-07 19:09:50 mksully22: I’ve already fixed it augeas 2018-05-07 19:53:20 jirutka: thx 2018-05-07 20:04:51 could please someone fix http://build.alpinelinux.org/buildlogs/build-edge-x86_64/testing/qt5-qtwebengine/qt5-qtwebengine-5.10.1-r0.log ? 2018-05-07 20:04:58 fails on all archs 2018-05-07 20:34:32 jirutka: I updated the pr : https://github.com/alpinelinux/mkinitfs/pull/26 2018-05-07 20:52:08 jirutka: updated again :) 2018-05-07 20:52:23 hopefully it's ok now 2018-05-07 21:08:06 Say, upstream says a version is "v1.0", should $pkgver be "v1.0" or "1.0"? 2018-05-07 21:14:36 azarus: I think 1.0. never seen v1.0. or you can use _realver=v1.0 for downloading the source 2018-05-07 21:23:20 tmh1999: thanks. 2018-05-07 21:28:44 also, I have a man page file, how to I go about compressing it and installing it to /usr/share/man? 2018-05-07 21:30:05 azarus: I thinking add subpackage -doc would help handling man pages 2018-05-07 21:30:14 *think adding 2018-05-07 21:30:47 tmh1999: i do have a subpackage -doc. 2018-05-07 21:31:03 it's just a plain $pkgname.1 file in $srcdir 2018-05-07 21:31:11 doesn't seem to handle it 2018-05-07 21:31:19 azarus: then install it into correct location inside package() 2018-05-07 21:31:41 jirutka: thanks, will try. 2018-05-07 21:32:00 should man pages always be compressed? 2018-05-07 21:33:07 preferrably 2018-05-07 21:33:20 azarus: yes, but don’t worry about it, abuild will handle it 2018-05-07 21:33:27 Oh, nice. 2018-05-07 21:38:40 strange. installed the manpage to "$pkgdir"/usr/share/man1/$pkgname.1, but it still ends up in the regular package, although the LICENSE file makes it into the -doc package just fine...? 2018-05-07 21:39:08 azarus: /usr/share/man/man1… 2018-05-07 21:39:30 *facepalm* 2018-05-07 21:39:32 thanks :) 2018-05-07 21:53:57 Okay, think I'm done with my APKBUILD. What's the preferred way to submit it, github PR or a post on the mailing lists? 2018-05-07 21:54:26 GitHub PR 2018-05-07 21:54:35 OK, will be done. 2018-05-07 22:22:39 https://github.com/alpinelinux/aports/pull/4214 , if anybody wants to take a look. 2018-05-07 22:22:53 (it's an aport for sacc, a console gopher client) 2018-05-07 22:24:01 Gopher still exists?! o.O 2018-05-07 22:24:25 Aww yes it does! 2018-05-07 22:26:12 we should probably start promoting gopher 2018-05-07 22:26:21 www is ruined 2018-05-07 22:26:30 with how terrible the internet is, yes 2018-05-07 22:26:56 idiots and marketing have taken over, the internet is a smoking pile of ash 2018-05-07 22:27:16 WTF http://bitreich.org/ 2018-05-07 22:27:32 I clearly specified gopher://, right? ;) 2018-05-07 22:28:01 https://twitter.com/jaseemabid/status/966024235536719872 2018-05-07 22:28:14 yes, I just hoped that there’s also some content on http://, I don’t have gopher browser 2018-05-07 22:28:28 "Huh! the @alpinelinux images on @Docker hub are probably smaller than the JS they serve per page." 2018-05-07 22:28:41 lynx is a good gopher browser 2018-05-07 22:32:05 Internet != HTTP 2018-05-07 22:32:08 HTTP != WWW 2018-05-07 22:33:06 everything can be misused when you give it to hands of idiots 2018-05-07 22:35:10 true, but that's terminology. i'm sure it's clear what's being talked about. 2018-05-07 22:36:22 yes, but I can’t agree that Gopher is a usable alternative 2018-05-07 22:36:31 (although being pedantic does prevent useless arguments sometimes) 2018-05-07 22:37:13 well, gopher is not there to replace the WWW, but it's cool none the less :) 2018-05-07 22:39:53 Anyway, did the corrections to the aport, will head to bed now. goodnight. 2018-05-08 02:36:08 can somebody re-trigger this build? it failed due to a network issue: https://github.com/alpinelinux/aports/pull/4141 2018-05-08 09:54:48 Can one specify that a package conflicts with another? 2018-05-08 09:54:58 (in an APKBUILD, that is) 2018-05-08 10:25:02 fcolista: please do not merge rust aports 2018-05-08 10:25:47 fcolista: `cargo build --release` downloads dependencies from internet without verification 2018-05-08 10:26:30 fcolista: I’m gonna revert this commit 2018-05-08 10:27:22 fcolista: read this https://github.com/alpinelinux/aports/blob/master/community/cargo/APKBUILD#L18-L26 2018-05-08 10:27:44 ACTION grubles something about inventing package systems 2018-05-08 10:30:04 btw why some people started removing builddir variable? 2018-05-08 10:30:47 (I know that abuild defined default builddir) 2018-05-08 10:34:48 i fixed the fd leak 2018-05-08 10:35:15 omfg, people stop inventing version numbers! if upstream does not bother to release their crap, use e.g. 0_git20180508, not 20180508! think about consequences 2018-05-08 10:35:56 i created another aport, but I doubt it's PR worthy yet: https://github.com/refacto/aports/tree/openssh-hpn 2018-05-08 10:36:13 (it's for OpenSSH with the HPN patchset applied) 2018-05-08 10:36:53 we used to have hpn patches for out openssh package 2018-05-08 10:37:11 it was removed for some reason, but i dont remember exactly why 2018-05-08 10:37:25 they probably lagged behind vanilla OpenSSH 2018-05-08 10:37:33 I hope that the one who removed it also wrote a comment to git log… 2018-05-08 10:37:55 the latest -hpn is now at 7.6p1, one behind vanilla 2018-05-08 10:38:15 that was not the only reason 2018-05-08 10:38:17 (multithreaded AES-CTR is there for 7.7p1 already, tough) 2018-05-08 10:39:20 nope, the reason why hpn patches was removed was not included in the commit message 2018-05-08 10:39:28 main/openssh: upgrade to 7.6_p1 2018-05-08 10:40:22 oh, okay then 2018-05-08 10:40:52 (well, anyways. my tree is there to try it out, worked in my local testing) 2018-05-08 10:40:55 fcolista: wrote a comment on https://github.com/alpinelinux/aports/pull/4125 2018-05-08 10:41:00 :-/ 2018-05-08 10:41:36 ncopa: aha, great… and YOU merged it 2018-05-08 10:43:48 jirutka: what is your point? 2018-05-08 10:44:14 ncopa: do I really have to explain you what the hell is wrong with not documenting changes?! 2018-05-08 10:44:28 StarWarsFan, sorry but I went to merge it from the newer rather than older 2018-05-08 10:44:36 jirutka: what do you think? 2018-05-08 10:44:46 ncopa: do you remember why it has been removed? no; can anyone else know it? no; is it so hard to write one fucking comment about why the change is made?! 2018-05-08 10:44:57 ncopa: so future you and other people can know WHY? 2018-05-08 10:45:09 ncopa: is this so f*cking difficilt to understand? 2018-05-08 10:45:15 jirutka, behave 2018-05-08 10:45:18 jirutka: dont think think i understand it? 2018-05-08 10:45:28 sorry, but I’m really annoyed by this level of stupidity 2018-05-08 10:45:39 ACTION gets behind cover 2018-05-08 10:45:39 … 2018-05-08 10:45:42 do you really think i dont understand that i did a mistake? 2018-05-08 10:45:49 ncopa: if you understand it, then why you asking…? 2018-05-08 10:46:04 [12:43:50] ncopa: jirutka: what is your point? 2018-05-08 10:46:08 jirutka: because i wonder what you are trying to do here. what is your goal? 2018-05-08 10:46:32 jirutka: is your goal to make me angry? to demovtiate me? leave the project? 2018-05-08 10:46:37 no 2018-05-08 10:46:48 so what is your point? 2018-05-08 10:46:54 what is your goal 2018-05-08 10:47:22 my goal is to point why it’s important to always explain WHY in commit logs for non-obvious changes 2018-05-08 10:47:40 this is not the first time we’re wondering why something has been changed 2018-05-08 10:47:52 it’s repeating over and over again 2018-05-08 10:48:01 yes, i understand perfectly that this could have been done better 2018-05-08 10:48:05 ncopa is human. we all make mistakes. 2018-05-08 10:48:20 but i cannot go back in time and change that now 2018-05-08 10:48:29 then I don’t understand why you asked “what is your point?”, when the point is obvious 2018-05-08 10:49:20 well, if your goal is to prevent this to happen again in the future, then i think you are using wrong method to reach that goal 2018-05-08 10:49:31 so what should I do instead? 2018-05-08 10:49:36 +1 ncopa 2018-05-08 10:49:57 you should learn how to deal with people 2018-05-08 10:50:05 read a book on the topic or something 2018-05-08 10:50:08 you are not stupid 2018-05-08 10:50:20 how can this prevent people not documenting changes again? 2018-05-08 10:50:58 how can you control what people do or not do? 2018-05-08 10:51:28 the only thing I can do is to point to and put a stress on every problem caused by not doing this, so people will maybe finally understand why it’s important and will start doing it 2018-05-08 10:52:09 well, technically, you cannot really force people to do what you want them to do, the way you want them to do it 2018-05-08 10:52:55 <_ikke_> jirutka: it helps to not call people stupid 2018-05-08 10:53:02 actually you can, it’s called QA 2018-05-08 10:53:20 serious projects have this, to prevent human mistakes 2018-05-08 10:53:35 sure, you can force people using your power 2018-05-08 10:54:06 but often that leads to you ending up losing the power (if people gets annoyed enough) 2018-05-08 10:54:27 anyway, I’m sorry for this burst, I’m not in good mood and I’m depressed from the current state of build infra and lack of proper QA 2018-05-08 10:54:44 let’s continue this in #alpine-team instead 2018-05-08 10:54:51 i understand that. i think that is pretty clear to everyone 2018-05-08 10:54:54 ok 2018-05-08 10:55:30 hm, if I see deep the niveu has fallen here, I should do something different... 2018-05-08 10:55:31 c ya 2018-05-08 10:55:56 jirutka: fwiw. im sorry for pushing a commit with non-optimal commit message 2018-05-08 11:33:00 (should I scrap my testing/openssh-hpn aport?) 2018-05-08 11:42:20 azarus: do you know if HPN actually do any real difference? 2018-05-08 11:43:23 ncopa: I know it does. If you want me to provide real benchmarks using the packages that abuild generatates, I can provide them. 2018-05-08 11:43:30 it's analogous to grsec and openssh 2018-05-08 11:43:43 uh 2018-05-08 11:43:48 analogous to grsec and linux 2018-05-08 11:43:54 i am searching for the discussion 2018-05-08 11:43:54 just more fundamental 2018-05-08 11:44:12 ncopa: [alpine-aports] [PATCH] main/openssh: upgrade to 7.6_p1 2018-05-08 11:44:14 it's mentioned there 2018-05-08 11:44:18 im pretty sure we discussed it, but i dont remember where 2018-05-08 11:44:29 On 2017-12-28 1:56 PM, Natanael Copa wrote: 2018-05-08 11:44:29 > I think you are right. Lets drop HPN in edge and see what happens. 2018-05-08 11:44:50 https://hastebin.com/aquqaxayev 2018-05-08 11:45:12 missed a reply where he said "Cheers, thanks!" but that was the entire thing, commented around a patch file i believe 2018-05-08 11:45:12 I'm 100% ok in making openssh-hpn not the standard, but a choice the user conciously makes 2018-05-08 11:45:18 agreed 2018-05-08 11:45:25 like linux-hardened is in a separate package 2018-05-08 11:45:30 yup! 2018-05-08 11:46:13 http://lists.alpinelinux.org/alpine-aports/5150.html 2018-05-08 11:46:20 there, yes 2018-05-08 11:47:03 the point is, we should never have the HPN patchset prevent upgrades to vanilla SSH 2018-05-08 11:47:17 shouldn't have it masquerading as vanilla openssh either 2018-05-08 11:47:25 and by having a seperate aport for that, problem solved 2018-05-08 11:47:33 it's misleading too 2018-05-08 11:47:39 mm 2018-05-08 11:48:45 "A few years ago, OpenSSH increased the channel limits enough to support 2018-05-08 11:48:46 a cross-country gigabit connection without slowdown. For most users, this 2018-05-08 11:48:46 means that the HPN patches are an unnecessary complexity with little to no 2018-05-08 11:48:46 benefit. In addition to that, they would frequently held FreeBSD back from 2018-05-08 11:48:46 updating their version of OpenSSH because of HPN backporting and manual 2018-05-08 11:48:46 refactoring of the patchset." 2018-05-08 11:49:13 Yes. FreeBSD wanted only one SSH, the one with the patchset applied. 2018-05-08 11:49:19 That held them back. 2018-05-08 11:49:29 that's not a good attitude 2018-05-08 11:49:34 (from freebsd) 2018-05-08 11:49:40 Agreed. 2018-05-08 11:50:54 well, "For most users, ... the HPN patches are an unnecessary complexity with little to no benefit." 2018-05-08 11:51:09 > most users 2018-05-08 11:51:16 that's why we should make it a choice 2018-05-08 11:51:19 ;) 2018-05-08 11:52:04 where does HPN help? IIRC it was for people with really old kernels 2018-05-08 11:52:21 or for people with "wrong" tcp settings 2018-05-08 11:53:47 An explanation of the author of HPN-SSH: https://stackoverflow.com/a/21097076 2018-05-08 11:53:53 explanation by* 2018-05-08 11:57:02 that was 2013? 2018-05-08 11:57:35 but openssh has since then increased the channel limits? 2018-05-08 11:58:02 we have a serious problem with clang 5.0.1 on ppc64le (a lot of Illegal instruction) http://build.alpinelinux.org/buildlogs/build-3-8-ppc64le/main/clang/clang-5.0.1-r0.log 2018-05-08 11:58:28 i dont mind adding openssh-hpn if you can show that it makes an actual difference 2018-05-08 11:58:53 jirutka: ouch 2018-05-08 11:59:33 maybe mksully can help us with that? 2018-05-08 11:59:37 you can see that it currently blocks build-edge-ppc64le, I was afraid that it’s caused by my recent changes, but since 5.0.1-r0 fails too, it’s not 2018-05-08 12:03:24 the good thing is that with https://github.com/am11’s help we fixed lldb 5.0.1 and probably even other or future packages depending on LLVM or Clang 2018-05-08 12:03:43 (https://github.com/am11, not https://github.com/am11’s) 2018-05-08 12:04:29 it’d be great if someone can test lldb if it really works correctly, so I can move it to the community repo 2018-05-08 12:05:51 also upgrade to LLVM 6 should be now ready, but it’s too late for v3.8, so we will merge it after v3.8 is released 2018-05-08 12:06:22 sounds good 2018-05-08 12:06:41 i wonder if it may be related recent binutils upgrade? 2018-05-08 12:07:04 ref https://github.com/alpinelinux/aports/pull/2342 2018-05-08 12:07:13 failure on ppc64le? 2018-05-08 12:08:58 oh, btw, that LLVM 5.0.1 failure on aarch64 is quite interesting… I fixed it with 6 years old patch for FreeBSD! I wonder why only aarch64 behaves differently in this https://bugs.llvm.org/show_bug.cgi?id=14278#c10 2018-05-08 12:09:33 ACTION will get to do some real life benchmarks with openssh-hpn soon 2018-05-08 12:11:14 I retested llvm5 on armhf (armv8l machine) and x86_64, but this issue is not present here, only on aarch64 2018-05-08 12:11:21 jirutka: yes failure on ppc64. 2018-05-08 12:11:38 interesting that it only affects aarch64 2018-05-08 12:11:51 im building llvm5 on ppc64le now 2018-05-08 12:12:00 and will do clang after that 2018-05-08 12:13:14 ncopa: well, it probably may be; clang-5.0.1-r0 succeeded on edge on 2017-12-29 2018-05-08 12:14:51 we also added secfixes to gcc https://git.alpinelinux.org/cgit/aports/commit/main/gcc?id=47bd50a950f32db3bd14e779c54c29a275738fa5 2018-05-08 13:23:26 ncopa: when you have a window to do s390x, please let me know. 2018-05-08 13:23:38 no pressure 2018-05-08 13:37:32 gimme 15mins 2018-05-08 13:40:25 yeah sure any time :D 2018-05-08 13:50:20 irssi-xmpp should be rebuild-ed for edge with to work with irssi version in edge 2018-05-08 13:50:55 else, couldn't be loaded because of incompatible API 2018-05-08 13:54:59 *rebuilt 2018-05-08 13:55:08 also, where's the PR? ;) 2018-05-08 13:55:26 if there isn't one, i'll do it 2018-05-08 13:57:32 I'm self taught in English, so sorry for mistakes 2018-05-08 13:58:40 I don't think PR is needed because nothing is changed except pkgrel is incremented by one 2018-05-08 14:00:25 https://github.com/alpinelinux/aports/pull/4221 2018-05-08 14:00:30 Oh well ;P 2018-05-08 14:02:58 tmh1999: ping 2018-05-08 14:03:03 ncopa: pong 2018-05-08 14:03:30 ncopa: so here are patches I need to be merged/built, so I could bootstrap a new builder 2018-05-08 14:03:35 ok 2018-05-08 14:03:53 https://github.com/alpinelinux/mkinitfs/pull/26 and https://github.com/alpinelinux/aports/pull/4062 are 1. 2018-05-08 14:04:01 https://github.com/alpinelinux/aports/pull/4213 another 2018-05-08 14:04:46 https://github.com/alpinelinux/aports/pull/4061 this can wait but if you could give some comment that'd be fine ( I will download setup-disk.in to run setup-alpine so this patch is optional for now) 2018-05-08 14:27:32 any comment ? 2018-05-08 14:38:37 im reading 2018-05-08 14:42:03 hm 2018-05-08 14:47:47 tmh1999: in the case of Alpine projects, pls first send patch to the project, then maybe backport to the aport if needed; it’s quite confusing and impractical to do both at once and quite nonsense to do it in reverse order 2018-05-08 14:48:56 tmh1999: ok i finally read it 2018-05-08 14:49:18 jirutka: yeah I learned that from your comment couple days ago. Those are opened earlier. 2018-05-08 14:49:49 tmh1999: does it make sense to set up software raid on dasd devices? 2018-05-08 14:50:03 eg md0 2018-05-08 14:50:20 i suppose that does not make sense? 2018-05-08 14:50:39 ncopa: that part I was not be able to come up with when writing this last month because I didn't have enough resoureces. Just got new resources last week... 2018-05-08 14:51:10 ncopa: for the alpine-conf + ssetup-disk patches, please just ignore it for now 2018-05-08 14:51:32 s390-tools and mkinitfs are higher priorities 2018-05-08 14:52:30 right, i just looked at those to try understand where the inital dasd=value came from 2018-05-08 14:52:37 since you read it from /proc/cmdline 2018-05-08 14:52:41 1 sec 2018-05-08 14:52:58 ncopa: come from here : https://github.com/alpinelinux/aports/pull/4100 2018-05-08 14:53:30 ${OUTDIR}/parmfile is kernel parm 2018-05-08 14:54:19 azarus: you made PR about irssi-xmpp, if I understand, https://github.com/alpinelinux/aports/pull/4221 2018-05-08 14:54:49 s390-tools (zipl) will pick up these configuration (dasd, qeth, etc.) when installing and add to /etc/zipl.conf : https://git.alpinelinux.org/cgit/aports/tree/main/s390-tools/s390-tools-script#n31 2018-05-08 14:55:15 zipl.conf is like grub.cfg and syslinux conf 2018-05-08 14:56:03 understood 2018-05-08 14:59:53 tmh1999: do you have experience with zipl from other distros? 2018-05-08 15:00:24 ncopa: everyone uses it. suse did some magic to make it work with grub. 2018-05-08 15:00:31 is it common to generate a zipl config from parsing the /proc/cmdline? 2018-05-08 15:00:56 zipl.conf could be manually edited to serve user's needs 2018-05-08 15:01:18 i didnt really like the part where it reads /proc/cmdline 2018-05-08 15:01:20 for now zipl.conf is updated/triggered for new changes with kernel 2018-05-08 15:02:16 which part ? 2018-05-08 15:03:00 https://git.alpinelinux.org/cgit/aports/tree/main/s390-tools/s390-tools-script#n17 2018-05-08 15:03:23 also where you autodetect the /dev/root 2018-05-08 15:04:14 but i dont know how those things are normally done on s390x 2018-05-08 15:04:38 that script is only triggered when kernel changes ( e.g upgrading kernel on a running system). current running system's config are stored in /proc/cmdline. 2018-05-08 15:05:10 ? 2018-05-08 15:05:17 sorry. /dev/root ? 2018-05-08 15:05:59 this would have not been acceptable on x86 2018-05-08 15:06:03 the problem is 2018-05-08 15:06:09 lets say you add a temporary boot parm 2018-05-08 15:06:15 to troubleshoot something 2018-05-08 15:06:35 lets say that you at the boot prompt add noquiet verbose 2018-05-08 15:06:40 to display extra info 2018-05-08 15:06:55 it will display during current reboot 2018-05-08 15:07:06 but unles you edit the syslinux config file it will not persist 2018-05-08 15:07:50 with zipl, i dont know if you get an early boot prompt, but if you do 2018-05-08 15:08:07 you could add a temporary boot opt for troubleshooting 2018-05-08 15:08:11 you manage to boot it up 2018-05-08 15:08:16 and then you upgrade kernel 2018-05-08 15:08:38 at that point the temporary boot options will be permanent, since it reads the /proc/cmdline 2018-05-08 15:09:14 with syslinux/extlinux, you need to edit /etc/update-extlinux.conf to make it permanent 2018-05-08 15:09:48 i dont know if you can override any boot options from a zipl boot prompt 2018-05-08 15:10:25 if you can, then we should not generate zipl.conf from /proc/cmdline 2018-05-08 15:10:30 thats my thinking 2018-05-08 15:10:42 unless all other distros does that 2018-05-08 15:11:24 also, the parmfile 2018-05-08 15:11:36 is that something that other distros do too? 2018-05-08 15:11:38 so it's problem with s390-tools (and possibly setup-disk). but since it's already there, I will try to change it later. 2018-05-08 15:11:57 yes. 1 sec to find doc. 2018-05-08 15:13:09 re: zipl.conf. I got this. I will try to fix later with setup-disk. From my perspective when writing these code, I find this easier to do things. That might be wrong. But it could wait since it's already merged. 2018-05-08 15:13:23 understand 2018-05-08 15:15:00 this is a completely new world to me :) 2018-05-08 15:16:22 how are you supposed to create boot media? 2018-05-08 15:16:30 or do you need to do net boot, like ipxe? 2018-05-08 15:16:46 i suppose you dont plug in a boot usb 2018-05-08 15:16:58 or insert a dvd or cdrommt 2018-05-08 15:17:20 ncopa: yeah it's all new to me too. I'm looking up the documentation for the kernel parm for you. 1 sec. For installation media, https://github.com/alpinelinux/aports/pull/4100. Kernel + Initramfs + parmfile. 2018-05-08 15:18:07 so you need to create a special boot media with the correct boot options stored 2018-05-08 15:18:27 how do you "insert" the created boot media to the machine? 2018-05-08 15:18:31 so it has a terminal (3270) - dumb terminal. That terminal allows access to a virtual reader ( litterally, in 60s-90s, it IS a reader, paper reader, now it's virtual). That reader reads in kernel + initramfs + parmfile and boot Linux (or any kind of virtual machine) 2018-05-08 15:19:01 "z/VM reader" might have some resources 2018-05-08 15:19:33 that makes sense ? 2018-05-08 15:19:49 I just learned these for the last 3-4 months. 2018-05-08 15:19:56 so it's new 2018-05-08 15:20:01 :) 2018-05-08 15:20:19 so basically, you need to print the bootmedia to a paper :D 2018-05-08 15:20:21 lol 2018-05-08 15:20:35 lol yeah litterally in 60s-90s they do that 2018-05-08 15:21:02 to compile code, you punch to paper. then push into the machine/reader, it reads, compiles and print out results using PAPER printers 2018-05-08 15:21:20 but that's decades ago. 2018-05-08 15:21:20 :D 2018-05-08 15:23:02 ncopa: this might be one : https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/installation_guide/ap-s390info 2018-05-08 15:26:09 z/VM reader (things I'm using) is virtual env : It's a hypervisor. There's another way to boot using ISO (like normal x86*), but it requires either physical access to the server or privilege access, both of which I can't afford. Most people don't I guess. 2018-05-08 15:26:43 yes 2018-05-08 15:27:01 and i found your trick to start sshd sort of nice 2018-05-08 15:27:17 and i think we should do that possible for other arches too 2018-05-08 15:28:03 beside zipl.conf, what else should I fix ? Yeah booting (small) initial initramfs then run installer through ssh is the way other distros do. 2018-05-08 15:28:34 I still think ipxe is better, the way clandmeter did. 2018-05-08 15:28:58 bad thing z/VM can't do ipxe 2018-05-08 15:30:54 don't sweat about these s390x changes, as long as they don't break other arches. I won't be going any where so if it breaks on s390x, I will fix it :D 2018-05-08 15:34:50 re: print bootmedia to a paper : that's 60s-90s. now it's virtual. 2018-05-08 15:38:51 tmh1999: sorry i think need help clandmeter and jirutka with the builders 2018-05-08 15:39:34 tmh1999: but generally, i wonder if we could add a ssh pubkey instead of password 2018-05-08 15:39:50 and make it possible to do so for the other arches as well 2018-05-08 15:39:53 not only for s390x 2018-05-08 15:40:41 ncopa: how can I help with the builders when I don’t have access to them? 2018-05-08 15:40:57 ncopa: we do set up password somewhere?! 2018-05-08 15:42:09 I think he means help us with builders :) 2018-05-08 15:42:22 jirutka: never mind. i was looking at the tmh1999 patches for s390x, which had soem password for ssh 2018-05-08 15:42:46 ncopa: that's only for during the installation process. setup-disk will remove that root password config. 2018-05-08 15:43:08 ncopa: yeah, he allowed password login to root in sshd_config; but that’s just for s390x 2018-05-08 15:43:52 ncopa, jirutka: it's for like 1-2 minutes during the installation process only. Or other wise, people could never add their ssh key through the parmfile. It's too long. 2018-05-08 15:48:32 I think enabling this ssh installation feature on all other arches seems like a lot of work at this time. I believe we have other priorities. 2018-05-08 16:07:24 just fyi, I was working with gcc-7.3.0 and gcc6-java. And I've got them working. But upstream musl (musl-cross-make) still does not merge gcc7-3.0 patches yet (even though I tested them okay) so I guess I'll hold it till they do. Maybe fabled wants an opinion on this. 2018-05-08 16:12:08 cooking lunch brb 2018-05-08 17:47:53 are the build queue/logs publicly accessible? 2018-05-08 17:51:59 kpcyrd: yes. but there's a few problems with it being worked on. 2018-05-08 17:52:14 http://build.alpinelinux.org/ 2018-05-08 17:54:59 tmh1999: I see, thanks! 2018-05-08 19:22:53 B3sp1n35 2018-05-08 19:24:20 time to change password :) 2018-05-08 19:25:11 <_ikke_> lol 2018-05-08 19:25:59 its my gratest fear to type the password in wrong window 2018-05-08 19:26:26 This is why I only use rsh 2018-05-08 19:29:31 I once had my screen locker spaz out, typed the password twice, the first entry was accepted by the screen locker, the second was accepted by irssi :/ 2018-05-08 19:30:06 <_ikke_> auch 2018-05-08 19:36:12 i once accidentally grabbed a coworkers steam password by texting him in xmpp 2018-05-08 19:36:26 and his client popped up a new focused window midst typing 2018-05-08 19:36:33 <_ikke_> That's horrible 2018-05-08 19:54:06 I'd appreciate if a maintainer could review https://github.com/alpinelinux/aports/pull/4075. Thanks! 2018-05-08 22:46:55 could this be merged rather quickly, so weston can build again? (bump mesa pkgrel after libwayland update) https://github.com/alpinelinux/aports/pull/4229 2018-05-08 22:51:51 ollieparanoid[m]: merged 2018-05-08 22:52:03 ollieparanoid[m]: but why it’s needed? there’s no ABI breakage according to https://abi-laboratory.pro/tracker/timeline/wayland/ 2018-05-08 22:55:30 thanks jirutka! 2018-05-08 23:09:22 jirutka: I've written the output of apk in the pull request. building weston currently failed, because 'mesa-dev depends on pc:wayland-egl=17.3.6' and 'wayland-dev depends on pc:wayland-egl=18.1.0' 2018-05-08 23:14:57 pc is pkg-config, right? 2018-05-08 23:18:56 yes 2018-05-08 23:19:48 i suspect that the dependency generator for abuild + pkg-config might need to not generate specific versions 2018-05-08 23:19:57 if you want that, you should declare it manually, i suppose. 2018-05-08 23:31:23 kaniini: long time no see you! 2018-05-08 23:31:52 kaniini: how do you do? how does it look with the enhancements to apk-tools we’ve talked about? 2018-05-09 00:37:11 is emscripten packaged for alpine? 2018-05-09 04:14:40 jirutka: sorry, i have been very busy 2018-05-09 06:54:53 duncan^: http://build.alpinelinux.org/buildlogs/build-edge-armhf/community/xbps/xbps-0.52-r0.log 2018-05-09 09:59:56 early morning ncopa 2018-05-09 10:26:00 obnam is failing to build in alpine 3.8 and the project is retired: https://blog.liw.fi/posts/2017/08/13/retiring_obnam/ 2018-05-09 10:26:00 Can we remove obnam from alpine 3.8? 2018-05-09 10:27:20 i suppose we can remove obnam 2018-05-09 10:28:14 ncopa: ok, I can do that if no one disagree with it 2018-05-09 10:30:43 i think you can just move it to unmaintained 2018-05-09 10:30:52 or just delete it, even better 2018-05-09 10:35:40 ncopa: thanks, done 2018-05-09 10:36:25 im no sure how to deal with the mesa/libva circular dep 2018-05-09 10:36:51 option 1) revert building libva dri drivers 2018-05-09 10:37:45 option 2) "bundle" a libva build with mesa, where we first build libva without glx support and then build the rest of mesa against that build 2018-05-09 10:38:19 option 3) build libva without glx all together 2018-05-09 10:38:58 option 4) same as option 3, but add a separate libva-glx package which only include libva-glx 2018-05-09 10:40:15 i think i like option 1 or 4 best 2018-05-09 11:57:33 Say I have 2 small disks, I want to create LVM on top of them with RAID 0 : /boot on sda1, LVM (root+swap) on sda2 and sdb. Default setup with 'sys' and 'lvm' uses RAID 1 instead. So what I did was, use option 'lvm' on sda only during installation process, then after installation, extend lv_root (on sda2) to sdb. Is that correct ? 2018-05-09 11:58:05 that looks right to me, not sure if it's okay. 2018-05-09 11:59:16 ncopa: to answer your question yesterday about hardware raid on s390x, it's not supported. But, software raid, is it the thing I'm talking above ? It's either raid0 or raid1. 2018-05-09 12:00:55 tmh1999: if you want custom disk setup, then do it yourself and then just run setup-disk in sys mode with path to mounted FS instead of dev 2018-05-09 12:01:36 tmh1999: actually I’ve never used setup-disk for setting partitions, volumes etc. when thinking about it 2018-05-09 12:04:15 jirutka: I see. I'm trying to work from user's perspective on how to setup on disks. Thanks for clarifying that. So default is raid1. And if anyone wants to customize other than that, he/she needs to do it first before setup-disk. 2018-05-09 12:04:31 tmh1999: yes 2018-05-09 12:04:48 jirutka: o/ 2018-05-09 12:07:43 so I think we can do software raid (like above) on s390x, but that can wait after the new builder is up (which is after current PRs are merged) 2018-05-09 12:12:59 that might be pretty hard since those dasd devices don't use gpt/mbr partition table id 2018-05-09 12:13:03 hm 2018-05-09 12:13:42 what does they use? 2018-05-09 12:13:52 btw s390x is for mainframe system? 2018-05-09 12:15:19 jirutka: I don't see any documentation so far for partition table id for dasd devices. Yes, s390x is the Linux running on top of mainframe hardware/hypervisor. 2018-05-09 12:15:42 dasd devices are either virtual plugged into the s390x linux, or direct hardware adapter. 2018-05-09 13:14:36 ncopa: If we could review/merge s390-tools and mknintfs PRs for s390x this week, that'd be great, because I'm not sure I would have some free time next week (doing paperwork for moving to Europe). To answer your question yesterday if we could do ssh + pubkey instead of password during installation process on s390x, the answer is unfortunately no because it's due to constraint allowing user getting their ssh key into the installer (kernel + 2018-05-09 13:14:37 initramfs + parmfile). Other arches do this password thing as well. As I mentioned yesterday, this password config will be removed after setup-disk is finished and not leaked to newly installed system. 2018-05-09 13:17:38 i will try look at it this week 2018-05-09 13:17:50 i need to unblock the builders first 2018-05-09 13:18:28 ncopa: sure thanks. 2018-05-09 13:25:58 tmh1999: is it possible to emulate dasd in qemu? 2018-05-09 13:26:34 ncopa: not that I know of 2018-05-09 13:26:39 ok 2018-05-09 13:27:30 ncopa: you can use Hercules emulator, but it's painfully slow on x86* (running entirely on tmpfs might help a little bit if you have enough ram) 2018-05-09 13:33:21 ncopa: maybe I could plug block device /dev/dasdX to a qemu. Let me try and come back to you. 2018-05-09 14:27:47 ncopa: It seems thing get messed up when vaapi drivers enabled in mesa. 2018-05-09 14:28:54 anyone working on firefox 60? 2018-05-09 14:29:18 ncopa: I think there's no need to make another package (libva-glx) to solve circular dep 2018-05-09 14:29:38 ncopa: Could you refer to https://github.com/alpinelinux/aports/pull/4106 please? 2018-05-09 14:32:48 i got a nasty little compile issue. musl has a field __pad1 in struct cmsghdr that isn't there on glibc. rust complains that firefox is skippind the value. 2018-05-09 14:51:34 ncopa: The answer to "is it possible to emulate dasd in qemu?" is yes. But it requires adding kernel configuration to current linux-vanilla config. 2018-05-09 14:52:04 Gottox: sounds ugly... 2018-05-09 14:52:38 ncopa: if you want to do that (now or later ?) I will submit a patch to linux-vanilla 2018-05-09 14:52:56 terra: i dont think that will help. if libva has mesa in makedepends and mesa has libva-dev in makedepends you still have circular dep 2018-05-09 14:54:02 I setup a s390x qemu here, guest + host are all Alpine. but dasd block device is not recognized due to lack kernel module. 2018-05-09 15:00:20 which kernel module is it? 2018-05-09 15:08:28 ncopa: probably https://wiki.qemu.org/Features/Channel_I/O_Passthrough 2018-05-09 15:15:25 ncopa: Is that means we can't bootstrap them if they refer each other in makedepends? Sorry for the noise then. 2018-05-09 15:49:46 yes. thats the problem. 2018-05-09 15:50:04 thanks for upgrading mesa though. glad we did it before 3.8.0 release 2018-05-09 15:56:34 I thank for merging it. 2018-05-09 16:08:47 ncopa: do you think you will have time to look at https://github.com/alpinelinux/aports/pull/4057 ? 2018-05-09 16:10:54 please review https://github.com/alpinelinux/aports/pull/4013 2018-05-09 16:59:04 HRio: will try do so when i get a chance. please ping me again friday if nothing happens 2018-05-09 17:08:20 ncopa: I know it must be really hectic days, so I really get it if its simply too much. Really appreciate your hard work! 2018-05-09 17:14:33 thanks 2018-05-09 17:15:00 \o/ 2018-05-10 01:49:32 Oh I just realize that, features listed in https://github.com/alpinelinux/mkinitfs/blob/master/Makefile#L10 are not always included in the initramfs, unless we explicitly specify them. 2018-05-10 10:28:57 ncopa: it seems there's a typo here: https://github.com/alpinelinux/aports/blob/master/main/mesa/APKBUILD#L241 2018-05-10 10:29:26 hmm, why has testing/wireguard-vanilla not been upgraded to 4.14.39? 2018-05-10 10:58:14 terra: good catch. thanks! 2018-05-10 10:58:48 azarus: 3246f1f5ef2f260ae535948df6a896f1b0edf4a7 2018-05-10 11:00:35 ncopa: yes, saw that the APKBUILD is up to date, but nowhere in the mirrors in the last 3 days? 2018-05-10 11:00:49 is something keeping it from being built? 2018-05-10 11:28:22 i guess there were a bunch of other build breakages 2018-05-10 11:28:39 i think it was qt5-qtwebengine 2018-05-10 11:28:42 its building now 2018-05-10 11:43:49 ncopa: qt5-qtwebengine still fails 2018-05-10 11:44:02 ncopa: http://build.alpinelinux.org/buildlogs/build-edge-x86_64/testing/qt5-qtwebengine/qt5-qtwebengine-5.10.1-r0.log 2018-05-10 11:44:27 ncopa: is it caused by Grsec as you suggested? if yes, then why the hell don’t just get rid of grsec kernel right now on the builders? 2018-05-10 11:45:43 anything in dmesg? 2018-05-10 11:45:55 grsec tends to be pretty verbose if it kills something 2018-05-10 11:46:03 that’s true 2018-05-10 11:47:03 <_ikke_> http://tpaste.us/N7Xm 2018-05-10 11:47:21 oh yup 2018-05-10 11:47:30 this doesn’t look like killed by grsec 2018-05-10 11:47:39 grsec just logged it 2018-05-10 11:48:06 Not quite sure about that... I'll try building it. 2018-05-10 11:48:15 (on my non-grsec machine) 2018-05-10 11:48:43 ACTION gets ready for hours of builing 2018-05-10 11:48:46 building* 2018-05-10 11:50:47 I’ll try it too 2018-05-10 11:52:00 (do be warned, qtwebengine is a beast to build 2018-05-10 11:56:54 I have one free 24cores x86_64 with vanilla kernel, so hopefully it will not take eternity to build 2018-05-10 12:00:04 qt5-webengine dependencies don't seem correct 2018-05-10 12:00:45 http://tpaste.us/xem1 2018-05-10 12:01:25 ... should we add paxmark to the build deps? 2018-05-10 12:15:02 <_ikke_> probably, yes 2018-05-10 12:16:00 i believe whoever introduced testing/qt5-webengine quit, correct? 2018-05-10 12:18:22 <_ikke_> Natanael was the first maintainer, so I'd say no 2018-05-10 12:18:39 <_ikke_> qt5-qtwebengine that is 2018-05-10 13:02:24 it builds fine on my machine with vanilla kernel 2018-05-10 13:02:46 I just logged to the machine after meeting and it was done 2018-05-10 13:03:52 so, ncopa, could you PLEASE install vanilla kernel on builders instead of wasting huge amount of your and ours time on fixing qt5-qtwebengine for Grsecurity kernel we already do not support and cannot support because it’s a proprietary closed-source project? 2018-05-10 13:05:03 <_ikke_> jirutka: afaik ncopa was already planning that 2018-05-10 13:05:12 _ikke_: just planning… 2018-05-10 13:05:30 _ikke_: yet this qt5-qtwebengine is blocking build queue for several days 2018-05-10 13:05:45 <_ikke_> @ncopa │ _ikke_: when would be a good time to upgrade kernel of bld1 and bld2? 2018-05-10 13:05:54 _ikke_: and IIRC ncopa was trying to fix it for grsecurity instead of installing vanilla on builders 2018-05-10 13:21:00 my machine is still on "[55/2327] CXX obj/third_party/WebKit/Source/core/html/html/html_jumbo_5.o 2018-05-10 13:21:05 ACTION sighs 2018-05-10 13:21:32 maybe I should allocate more resources to my aports dev vm 2018-05-10 13:25:13 ACTION I literally built everything on my 2-core laptop. boostrapping gcc + openjdk7 + openjdk8 usually took half a day lol  2018-05-10 13:25:44 Never bothered with java stuff before :P 2018-05-10 13:26:11 azarus: Me too, until it hit my desk. 2018-05-10 13:27:15 tmh1999: half a day when everything goes fine and the build don't fail, right? :) 2018-05-10 13:27:45 now it's all the past, sometimes I wake up at night missing the laptop's fans *flying* and missing the pain when errors occur. 2018-05-10 13:27:50 rdutra: you got me there :D 2018-05-10 13:28:10 heheh 2018-05-10 13:29:10 the laptop's fan slowly spinning down as you investigate the error 2018-05-10 13:44:31 I never build stuff on my notebook, not just because I have MacBook, but also that I need to work on it, not utilizing CPU for compilation XD 2018-05-10 13:44:51 so I run builds on servers 2018-05-10 14:21:37 Hi, I have a question if there is possibility to configure `apk` default behaviour system-wide? 2018-05-10 14:21:37 I would like to have argument `--no-cache` for `apk add` enabled by default 2018-05-10 14:21:37 I was looking into code at https://git.alpinelinux.org/cgit/apk-tools/ 2018-05-10 14:21:37 Also I found that options are parsed in `src/apk.c`, but form my short look it's not reading any config file 2018-05-10 14:21:37 There is `CONFDIR` but I don't see it usage anywhere 2018-05-10 14:21:37 So, does `apk` search for any config file for default values that I can provide? 2018-05-10 14:21:37 Yet I found on wiki that there is something like `/etc/apk/apk.conf` but only used for `APK_PATH` that I can't find in `apk-tools` code 2018-05-10 14:24:48 I'm looking for this because now I'm creating base image for OpenStack Monasca services and would like to set this as default behaviour for all container using this base image (so users don't need to remember to add every time `--no-cache` to `apk add` 2018-05-10 15:15:51 jirutka: I mentioned it because I couldn't afford a server :D 2018-05-10 15:16:14 surprised that you have a mac though 2018-05-10 15:19:02 tmh1999: not for a long time, it’s 7 years old, I need new notebook and new MacBooks are craps, so I have to leave macOS and gonna switch to Linux on notebook 2018-05-10 15:19:23 jirutka: thinkpad ? 2018-05-10 15:19:30 tmh1999: but I’m not happy about it, I think that macOS is still the best desktop OS 2018-05-10 15:19:39 kindof agreed 2018-05-10 15:19:49 tmh1999: no, Fujitsu Lifebook U748 2018-05-10 15:21:43 nice one 2018-05-10 15:24:18 can't beat Japanese quality 2018-05-10 15:26:31 I just hope there will not be any compatibility issues with Linux 2018-05-10 15:26:36 I couldn’t find any info about it 2018-05-10 15:28:43 dns stub resolver talk from kubecon (why not use alpine if you care about dns) https://youtu.be/ZnW3k6m5AY8 2018-05-10 15:30:11 ncopa: what’s gonna be our counterattack? 2018-05-10 15:31:01 im thinking of giving a talk on why musl stub resolver behavior is a good idea 2018-05-10 15:31:16 +1! :) 2018-05-10 15:31:19 but thats not until november 2018-05-10 15:31:23 :( 2018-05-10 15:31:27 o/ 2018-05-10 15:31:34 dalias talked about a ewontfix article 2018-05-10 15:31:54 but we should also make some talk “Why not use Google/Kubernetes/similar if you care about X” :) 2018-05-10 15:32:28 or “Why you should not trust Google ’experts’” 2018-05-10 15:37:12 nah 2018-05-10 15:37:23 I’m really getting tired of fixing stuff for LibreSSL >_< 2018-05-10 15:37:53 and more when I’m encountering random failures in TLS handshake in OpenLDAP and don’t know what’s the cause… 2018-05-10 15:42:31 Weren't there plans on switching to OpenSSL? 2018-05-10 15:42:51 I actually use Alpine on my main computer, no problems 2018-05-10 15:43:54 PureTryOut[m]: yes, there were, but the last info I got is that ncopa is against switching to OpenSSL :( 2018-05-10 15:44:38 oh, that'd be dissapointing. I have a package which doesn't compile because the whole dependency chain uses LibreSSL 😕 2018-05-10 15:45:53 I feel like we could have arguments about {Open,Libre}SSL for days and be none the wiser 2018-05-10 15:49:09 the problem with libre is they aren't claiming to keep a compatible api, which makes it hard to keep stuff working that depends on openssl apis 2018-05-10 15:49:46 anyway, I already stopped wasting my time on non-trivial compat fixing for LibreSSL, because I don’t see any sense in it; LibreSSL used to be more secure option, but that’s not quite true anymore and there are way more downsides than upsides; that’s why we still don’t have nodejs 10.0 for example 2018-05-10 15:50:23 LibreSSL devs promised to be compatible with OpenLDAP 1.0.x API, but they violated this promise 2018-05-10 15:50:31 on a side note, how does one fix the wtmp thing with alpine? 2018-05-10 15:50:44 <_ikke_> Adran: musl does not support it 2018-05-10 15:50:54 wtmp? 2018-05-10 15:50:58 my understanding is it could and there's a ticket for it 2018-05-10 15:51:54 https://bugs.alpinelinux.org/issues/3282 2018-05-10 15:54:24 argh. qtwebengine failed because I didn't have enough memory 2018-05-10 15:54:26 i give up 2018-05-10 15:54:53 azarus: IMHO you don’t have to build it, I’ve already confirmed that it builds fine on vanilla kernel 2018-05-10 15:55:09 jirutka: agreed 2018-05-10 15:55:14 ncopa: so how about it? 2018-05-10 15:55:44 ncopa: see my messages 15:02:23, 15:02:45 and 15:03:51 2018-05-10 15:55:55 (CET) 2018-05-10 15:55:56 (timezone?) 2018-05-10 15:56:00 ah, cool :) 2018-05-10 15:56:18 CET == GMT+2 2018-05-10 15:57:07 sorry, need to run. re qtwebengine i tried to look at it today but got distracted, but we will try update the kernel tomorrow morning and that should fix it 2018-05-10 15:57:27 i didnt feel it was worth spending more time 2018-05-10 15:57:30 ncopa: \o/ 2018-05-10 15:57:43 spent several hours earlier this week to try build mksnapshot separately 2018-05-10 15:57:53 but its qmake -> make -> gn -> ninja 2018-05-10 15:57:57 or something like that 2018-05-10 15:58:15 i tried a hack but apparently it didnt work 2018-05-10 15:58:24 new kernel should fix it though 2018-05-10 15:58:35 i need to run. cu l8r 2018-05-10 15:58:44 ncopa: I wonder why do you waste your precious time… 2018-05-10 15:58:58 ncopa: if you already knew that it’s Grsec related problem 2018-05-10 18:15:44 because some grsec like thing may arrive in the future, and being prepared for it makes sense 2018-05-10 18:16:40 is the standard kernel in 3.8 going to ship with grsec? 2018-05-10 18:16:46 probably not, right? 2018-05-10 18:34:04 kaniini: that’s irrelevant, we can fix it later when it arrive, not now when we’re busy with new release and there are tuns of more important issues 2018-05-10 18:34:41 s/tuns/tons/ 2018-05-10 18:38:18 Is there like a todo list for the release? I'd love to help where I can. 2018-05-10 19:28:55 I'm having an interesting problem with alpine 2018-05-10 19:29:05 looks like the auto part of mount -t auto isn't working 2018-05-10 19:29:12 ACTION uploaded an image: image.png (30KB)  2018-05-10 20:40:56 MartijnBraam[m]: this is afaik due to busybox 2018-05-10 20:41:19 im not even sure of busybox's mount has autodetection of any sort 2018-05-10 20:44:10 got closer to the solution of my problem: there are no real filesystems listed in /proc/filesytems so busybox won't test them with -t auto 2018-05-10 20:44:16 it works if I modprobe ext4 first 2018-05-10 20:45:58 uhm, the modprobe ext4 should have happened automatically by the initramfs /init 2018-05-10 20:46:43 hm... only if its in the bootparam 2018-05-10 20:47:04 how does alpine ever boot? 2018-05-10 20:47:07 if you depend on the -t auto feature, one could ass modules=ext4 to the kernel command line 2018-05-10 20:47:24 MartijnBraam[m]: initramfs has /etc/fstab, where its explicitly given 2018-05-10 21:02:13 oh found the solution, adding `modules=ext4` to the kernel commandline 2018-05-10 21:08:29 unexpected :P 2018-05-11 10:48:52 Hi guys, im looking for some good docs on building AlpineLinux from source, is the wiki article How_to_make_a_custom_ISO_image_with_mkimage the way forward? 2018-05-11 10:49:08 ive installed the alpine-chroot on debian 2018-05-11 10:49:27 nsh-core: what exactly do you want to achieve? 2018-05-11 10:49:52 if you want to build custom VM image, you can use https://github.com/alpinelinux/alpine-make-vm-image 2018-05-11 10:50:20 if create customized rootfs for container (“base image”), then https://github.com/jirutka/alpine-make-rootfs 2018-05-11 10:54:49 where looking to compile an ISO to burn to a rasp pi to run some software 2018-05-11 10:54:56 not on containers but bare metal 2018-05-11 10:56:09 hm, RPi is quite special case 2018-05-11 10:56:58 https://wiki.alpinelinux.org/wiki/How_to_make_a_custom_ISO_image_with_mkimage for start 2018-05-11 10:57:09 but I don’t know how RPi is handled 2018-05-11 10:57:13 this is what im currently working through 2018-05-11 10:57:40 why would there be an issue with Rpis, i was under the understanding that alpine supported arm? 2018-05-11 10:58:00 yes, we support arm 2018-05-11 10:58:13 we're basically looking to build it from source to run an embedded c++ application 2018-05-11 10:59:19 I didn’t mean that there’s some issue with RPi, just that it has different booting than x86* and requires some BLOBs; and that I don’t know this stuff, so can’t tell more 2018-05-11 11:00:04 ah see, these BLOBS container the Rpi drivers? 2018-05-11 11:00:10 but we provide image for RPi on https://alpinelinux.org/downloads/ and the scripts supports it 2018-05-11 11:01:09 yes, some drivers for RPi are proprietary 2018-05-11 11:01:15 ok so is there a repo with the source build/make files for this image 2018-05-11 11:01:49 it should be in https://github.com/alpinelinux/aports/tree/master/scripts 2018-05-11 11:02:51 perfect thank you I will look through this now. 2018-05-11 16:30:11 I'm looking to package a daemon, that has a /etc/conf.d/blah and a /etc/init.d/blah file. Must there be an -openrc subpackage? 2018-05-11 16:32:16 azarus: I think you can just put there. 2018-05-11 16:33:03 pickfire: Thanks, it works. 2018-05-11 16:33:04 Along with the package. 2018-05-11 16:33:57 azarus: I think I have 2 package that I just embed it into the package. 2018-05-11 16:33:57 MY 2018-05-11 16:34:13 taskd and tlp 2018-05-11 16:36:41 pickfire: https://github.com/alpinelinux/aports/pull/4257 2018-05-11 16:44:01 azarus: I think you should remove makedepends= 2018-05-11 16:44:24 And pkgdesc should be "simple gopherd" 2018-05-11 16:44:51 pickfire: Suppose so. makedepends= doesn't hurt, but it isn't pretty either ;/ 2018-05-11 16:45:11 And -openrc is not needed in subpackages 2018-05-11 16:45:25 abuild complains otherwise. 2018-05-11 16:45:41 azarus: Yes, but it's better to remove it. https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package#Code_review 2018-05-11 16:46:02 Oh, maybe abuild was changed recently, I never knew that. 2018-05-11 16:46:37 Hmm...? nothing about removing -openrc there 2018-05-11 16:47:15 <_ikke_> I think -openrc is fairly new 2018-05-11 16:47:25 <_ikke_> preparing for a different init system in the future 2018-05-11 16:47:31 s6? 2018-05-11 16:47:42 <_ikke_> I don't think anything has been decided yet 2018-05-11 16:47:55 _ikke_: Any candidates? 2018-05-11 16:47:59 Rather, I hope not systemd. 2018-05-11 16:48:04 :p 2018-05-11 16:48:12 <_ikke_> no, it will never be systemd 2018-05-11 16:49:11 so... -openrc subpackage, yes or no? 2018-05-11 16:49:34 <_ikke_> if abuild complains, then yes 2018-05-11 16:49:38 yes 2018-05-11 16:49:41 OK. 2018-05-11 16:49:50 PR is updated. 2018-05-11 16:50:42 (git push -f to the rescue) 2018-05-11 16:50:56 azarus: Is the install line too long? 2018-05-11 16:51:08 that's how newapkbuild does it 2018-05-11 16:51:22 Okay, another thing that's new to me. 2018-05-11 16:51:37 I used to merge then into a line if it's shorter than 80. 2018-05-11 16:52:51 azarus: As well, the commit message. 2018-05-11 16:53:02 I got a hook for that. 2018-05-11 16:53:17 azarus: https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package#Commit_your_work 2018-05-11 16:53:34 will fix. 2018-05-11 16:53:36 IIRC I used to put the url in the commit message. But not sure if it's yet another new thing. 2018-05-11 16:54:18 Everything else looks fine to me. 2018-05-11 16:54:30 azarus: Good work. +1 2018-05-11 16:55:19 no problem. commit message ammended 2018-05-11 16:56:30 Haha, appended. Now looks perfect for me. 2018-05-11 16:56:45 (i used git commit --amend) 2018-05-11 17:01:00 Haha, and git push -f 2018-05-11 17:01:18 of course. can't let them see I make mistakes. 2018-05-11 17:01:25 :P 2018-05-11 17:01:31 ACTION ops 2018-05-11 17:01:32 Me too 2018-05-11 17:25:03 say, a build system checks if `sphinx-build` exists, and py{2,3}-sphinx only provide sphinx-build-{2,3}, how should one proceed? 2018-05-11 17:49:13 <[[sroracle]]> look for configure option to explicitly point to sphinx-build-3 2018-05-11 18:45:04 looks like builders are back on track 2018-05-11 18:45:15 have a nice weekend everyone 2018-05-11 18:45:22 <_ikke_> ncopa: thanks for your hard work :) 2018-05-11 18:45:36 _ikke_: thank you for your help! 2018-05-11 18:49:36 <_ikke_> always 2018-05-11 19:01:06 do we need to bump the pkgrel on mkinitfs to include the xfs.files change? 2018-05-11 19:01:27 -- or a whole new mkinitfs release? 2018-05-11 19:03:03 <_ikke_> pkgrul bump is for changes to the packaging 2018-05-11 19:03:58 <_ikke_> pkgrel* 2018-05-11 19:04:29 ah yup, of course. 2018-05-12 13:21:42 suggesting someone package the pcscd and scdaemon software as APKs... can't use yubikey smartcards in alpine presently 2018-05-12 13:27:21 ageis: There is an alternative, which is to enable gnupg's internal CCID driver. 2018-05-12 13:27:56 I did that for a while. You'd need to create the correct udev rules to allow a given group to access the USB devices. 2018-05-12 13:28:27 E.g. Debian package both GnuPG with the internal CCID driver enabled, as well as pcsc-lite and ccid driver. 2018-05-12 13:29:01 But arguably the former is cleaner, and the Yubikey (and most smartcards) work fine without pcscd and ccid. 2018-05-12 13:29:22 as for scdaemon, scdaemon does not need to be packaged separately. it's part of GnuPG. 2018-05-12 13:29:33 You just need to enable it in the build system. 2018-05-12 13:30:03 There's actually a feature request I made a while back for this: https://bugs.alpinelinux.org/issues/8621 2018-05-12 13:30:16 I made that because it's not clear what the best approach is. 2018-05-12 13:31:03 duncan: oh right 2018-05-12 13:32:04 duncan: can you help? i have udev rules (i've written one of the popular guides on doing this) https://gist.github.com/ageis/14adc308087859e199912b4c79c4aaa4 2018-05-12 13:32:10 so the solution is just to rebuild gnupg? 2018-05-12 13:32:16 You can trivially do it locally. I nicked Gentoo's definition for the USB group (which allowed anyone in that group full access to all USB devices) because I couldn't for the life of me work out how to make Debian's udev rules to work 2018-05-12 13:32:43 is alpine gnupg built with CCID enabled? 2018-05-12 13:32:48 no 2018-05-12 13:32:57 k 2018-05-12 13:32:57 but yes, the solution is to just rebuild GnuPG. Use --enable-ccid-driver and --enable-scdaemon. 2018-05-12 13:33:05 Should just work 2018-05-12 13:33:13 great 2018-05-12 13:33:13 the udev rules are the hard bit 2018-05-12 13:33:22 i dont mind doing this as root 2018-05-12 13:33:36 need docs on fetching source and building software in alpine 2018-05-12 13:33:37 ACTION searches 2018-05-12 13:33:58 https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package 2018-05-12 13:34:00 setup ^ 2018-05-12 13:34:08 thank you 2018-05-12 13:35:04 You can probably use ccid and pcsc-lite as well. 2018-05-12 13:35:51 If you enable scdaemon you might as well enable gnupg's ccid driver too, though. GnuPG allows you to specify which driver to use, at any rate. 2018-05-12 13:36:24 pcsc-lite and (maybe?) ccid have service scripts that makes them run in the background 2018-05-12 13:36:38 I wasn't sure how to get them to work when I last tried though. 2018-05-12 13:37:26 appreciate it 2018-05-12 13:37:32 whats the status of alpine's access to newer grsec patches? 2018-05-12 13:41:24 is there a way to pass the config options to abuild? 2018-05-12 13:41:32 ah 2018-05-12 13:41:34 will just edit the APKBUILD 2018-05-12 22:11:03 it's quiet 2018-05-12 22:12:01 <_ikke_> it's late 2018-05-12 22:12:13 oh right i forgot 2018-05-12 22:17:04 how is life in Europe _ikke_, compared to other places you've been to ? 2018-05-12 22:17:29 just some random questions late night :) 2018-05-12 22:17:40 it's find if you don't want to answer :D 2018-05-12 22:17:40 <_ikke_> hehe :D 2018-05-12 22:17:44 *fine 2018-05-12 22:18:02 <_ikke_> Pretty okay 2018-05-12 22:18:18 <_ikke_> I haven't been to a lot of places though 2018-05-12 22:21:11 <_ikke_> I think it also matters a lot what you're used to 2018-05-12 22:21:18 it's great! 2018-05-12 22:21:23 I heard it's the environment (physical and political) is pretty good compared to America. In exchange, the salary is a little bit lower. 2018-05-12 22:21:54 taxes are on par 2018-05-12 22:22:17 *its 2018-05-12 22:25:37 my friends working at Microsoft in Seattle making like $ 200k a year (for 2-3 years now). For the same-level position in Germany, it's like EUR 50k. 2018-05-12 22:26:22 yet he has to pay more on insurance (tax, maybe) 2018-05-12 22:27:29 I just hope life in (Central) Europe to be more peaceful 2018-05-12 22:28:24 <_ikke_> I live in a very quiet place :) 2018-05-12 23:04:17 I live in rural northern Norway so 2018-05-12 23:04:28 it would be boring, but norwegians can't handle alcohol for shit, so :P 2018-05-13 00:11:08 with Norwegian alcohol prices, no wonder 2018-05-13 09:50:42 are virtualbox modules available for 4.9.73-r0? 2018-05-13 09:55:11 nevermind :P 2018-05-13 09:58:32 yeah i dunno why this is 404 https://pkgs.alpinelinux.org/package/edge/community/x86/virtualbox-guest-modules-virthardened 2018-05-13 09:59:24 it used to be there 2018-05-13 10:01:38 i can checkout the commit but cant build w/out linux-hardened-dev and linux-virthardened-dev 2018-05-13 10:03:49 ohh i see " 2018-05-13 10:03:49 we no longer support the linux-hardened kernel so we remove it and all 2018-05-13 10:03:49 the 3rdparty kernel modules." 2018-05-13 10:04:50 gonna try building the kernel to get it back 2018-05-13 10:49:11 ageis: hardened is unmaintained. It doesn't have spectre/meltdown patches because they were incompatible with the last public grsec code. 2018-05-13 10:49:56 As such there has been no update of that kernel pretty much since then... 2018-05-13 13:46:12 What happened to this PR? https://github.com/alpinelinux/aports/pull/3337 2018-05-13 13:47:25 <_ikke_> I don't think a lot has happened to it yet 2018-05-13 13:47:54 so, probably in limbo :/ 2018-05-13 13:52:22 (i'm asking because I'd like to see qutebrowser as a package) 2018-05-13 14:48:44 question on travis, https://github.com/alpinelinux/aports/pull/4255 reported that ghc isn't available as a package to test with, not sure how big of a deal that is/nt 2018-05-13 14:49:17 and for the two things that depend on ghc cabal and idris, I'm updating those as well this morning, should I just include those with that pr? 2018-05-13 14:49:45 i had to rip out armhf support to ghc due to the upcoming release not being buildable via 8.0, so bit of a rock and hard place 2018-05-13 14:50:40 the new build system should make bootstrapping armhf again easier however so i'm torn, i use armhf a lot but at a certain point have to kick that can to the curb if that platform has problems 2018-05-13 15:17:53 I'll try building firefox-esr 60 now, let's see how much work the APKBUILD needs... 2018-05-14 08:28:20 I'm trying to create a python package. Is it bad if the package creates a .egg-info directory in /usr/lib/python3.6/site-packages ? 2018-05-14 12:35:24 ncopa: friendly ping again on mkinitfs/s390-tools PRs. Is there any suggestion for me to change/improve it to get merged ? 2018-05-14 12:35:52 ah 2018-05-14 13:18:07 ncopa: I think I will move the logic doing CONF_FILES and adding to mkinitfs.conf to aports/mkinitfs/APKBUILD instead of doing it in the Makefile. Would it be better ? 2018-05-14 13:18:52 *CONF_FILES logic could stay but mkinitfs.conf needs to move 2018-05-14 13:37:19 that would work, but i think it woudl be better to generate the mkinitfs.conf 2018-05-14 14:00:23 ncopa: how do you mean 'to generate mkinitfs.conf' ? https://github.com/alpinelinux/aports/pull/4062/commits/52e19a4c4aca4222630e769e60460d7fd230ce6e#diff-b83611720f3665cf8c04b43af06fb4c7R31 2018-05-14 14:10:56 i mean: echo 'features="$(DEFAULT_FEATURES)"' > mkinitfs.conf 2018-05-14 14:11:30 ncopa, can we have something different than the current splitted firmware package? maybe something called linux-firmware-base? 2018-05-14 14:12:11 im not sure who splitted it up 2018-05-14 14:12:19 check the git log 2018-05-14 14:12:35 im not sure what the idea with that was 2018-05-14 14:12:52 i mean, sure the package is huge, and you will likely not need all of it 2018-05-14 14:12:56 the current situation is kinda eh 2018-05-14 14:13:08 install linux-vanilla and boom, so much unnecessary firmware 2018-05-14 14:13:23 but i dont know how you are supposed to pull in the needed firmware 2018-05-14 14:13:40 <_ikke_> or even know what to pull in 2018-05-14 14:13:46 exactly 2018-05-14 14:13:48 hrm, some people don't need any firmware 2018-05-14 14:14:06 some of my computers work fine without /lib/firmware 2018-05-14 14:14:19 so how do we solve that? 2018-05-14 14:14:38 how do we detect when firmware is needed and how do we detect what firmware 2018-05-14 14:14:50 can we do that from setup-alpine? 2018-05-14 14:15:04 have people install the necessary firmware themselves? not really intuitive, tough,,, 2018-05-14 14:15:29 even if they need to do it manually, how do you figure out what firmware you need? 2018-05-14 14:16:01 some people know what packages they need, for others we could make a metapackage that installs everything? 2018-05-14 14:16:25 when should the meta pacakge be installed? 2018-05-14 14:16:33 do you need to manually install it? 2018-05-14 14:16:43 good questions :s 2018-05-14 14:17:05 "Does your computer need additional firmware? [Y] " 2018-05-14 14:17:24 how do you know if your computer need firmware? 2018-05-14 14:17:24 in setup-alpine, so by default, yes, but "experts" can disable it 2018-05-14 14:17:29 ncopa: https://github.com/alpinelinux/aports/pull/2898 what should we do with the sssd PR? it seems the person that opened it is not that responsive 2018-05-14 14:17:36 by studying dmesg ;) 2018-05-14 14:18:47 ncopa: I have found the reason that check() is not working and fixed it, if we can get in sssd as is in PR2898 I can submit a new PR fixing check() 2018-05-14 14:20:46 ncopa, the idea was to limit the size in some cases. 2018-05-14 14:20:56 i understand 2018-05-14 14:21:04 but now its blowing up my console so its not optimal. 2018-05-14 14:21:12 and its slower to do it like this 2018-05-14 14:21:16 clandmeter: what's blowing up? 2018-05-14 14:21:22 i just dont have a good way to solve it 2018-05-14 14:21:45 i think we should pull in some general firmware package 2018-05-14 14:21:49 ncopa: for example, debian installs by default without it 2018-05-14 14:22:08 do you manually need to install it if needed? 2018-05-14 14:22:27 which can be replaced by some of the splitted ones. 2018-05-14 14:22:32 if thats even possible 2018-05-14 14:22:39 ah, that was wrong. they have firmware-linux and firmware-linux-nonfree 2018-05-14 14:23:12 firmware-linux is installed by default, my bad 2018-05-14 14:24:51 so somethjing like linux-firmware with all firmwares and the other splitted ones that can be installed and replace the default one. but im not sure thats possible with replaces and provides. 2018-05-14 14:27:29 i think we can have a linux-firmware which depends on all the splitted ones, but not liet linux-vanilla depend on any firmware package 2018-05-14 14:27:43 instead, we can have a script that checks what kernel modules are currently loaded 2018-05-14 14:27:58 and walk though all those modules and check if there are any firmware for it 2018-05-14 14:28:26 and then install the needed firware 2018-05-14 14:28:29 not letting linux-vanilla depend on firmware is a good idea, not sure if one can determine the necessary firmware from loaded modules tough 2018-05-14 14:28:44 i think it is possible 2018-05-14 14:28:59 sure, but how reliable would it be? 2018-05-14 14:29:19 also, what if the hardware changes? 2018-05-14 14:29:38 re hardware changes 2018-05-14 14:29:50 i would prefer having all of them per default but make it configurable afterwards. 2018-05-14 14:29:52 the only way to protect against that is to always install all fireware 2018-05-14 14:29:58 true :/ 2018-05-14 14:30:18 clandmeter: agreed 2018-05-14 14:30:21 the idea is that by default we install apk add linux-vanilla linux-firmware 2018-05-14 14:30:49 and one can always remove linux-firmware if so desired. 2018-05-14 14:30:54 then you can manually apk del linux-firmware && apk add $the_needed_firmware_packages 2018-05-14 14:30:56 but if you depepnds on all those subpkgs you still have the same issues 2018-05-14 14:31:07 it pulls in a lot of them. 2018-05-14 14:31:13 which makes things slower 2018-05-14 14:31:19 and spams my console 2018-05-14 14:31:27 and fills your disk 2018-05-14 14:31:38 thats another issue 2018-05-14 14:31:42 (well, compared to how tiny the rest of alpine is) 2018-05-14 14:31:46 apk add --quiet will fix the spam issue 2018-05-14 14:31:54 but it will not speedup 2018-05-14 14:32:11 adding 1 large pkg will be faster than 40 small ones. 2018-05-14 14:32:34 so basically, what you propose is to revert the split 2018-05-14 14:33:16 tmh1999: this is what i mean: http://tpaste.us/KdPP 2018-05-14 14:33:39 make it pull all in 1 pkg, but let it be replaceable with smaller ones by choice of user. 2018-05-14 14:34:53 hrm. wonder how'd that be implemented in an APKBUILD 2018-05-14 14:35:02 im not sure what the perfect solution is. i just know i dont like the current implementation. 2018-05-14 14:35:16 the splitted package only needs: replaces="linux-firmware" 2018-05-14 14:35:31 right 2018-05-14 14:35:43 the only drawback is that it will take double space on repository 2018-05-14 14:35:45 and the meta pkg should also carry all of the firmwares. 2018-05-14 14:35:49 ncopa: Oh. You're talking about something else completely different... Okay. I think I will need to create a separate PR for your change then apply mine 2018-05-14 14:36:15 my laptop *only* needs linux-firmware-intel, and none if I use my other wireless card 2018-05-14 14:36:18 tmh1999: i can push the above and let you rebase? 2018-05-14 14:36:39 ncopa: that's even better :D 2018-05-14 14:37:07 yes the repo will be bigger. 2018-05-14 14:38:20 our repo is growing a lot recently 2018-05-14 14:38:33 tmh1999: pushed 2018-05-14 14:38:40 is the infrastructure hitting its limits? 2018-05-14 14:38:40 now we got all those openrc subpkgs coming. 2018-05-14 14:38:54 ncopa: updating in few mins, will ping you back here 2018-05-14 14:39:33 tmh1999: this may be an idea too: http://tpaste.us/oQmB 2018-05-14 14:40:20 or more like: http://tpaste.us/jDzl 2018-05-14 14:40:24 oh 2018-05-14 14:40:37 its supposed to be: ARCH := $(shell uname -m) 2018-05-14 14:40:41 but you get the idea 2018-05-14 14:42:51 we currently pull in 80 firmware subpkgs :| 2018-05-14 14:43:44 HRio: im not sure what to do with PR2898, i guess you could pull it, and merge the commits, still usse the contributor as author 2018-05-14 14:44:04 and then create a new PR where you comment that it replaes PR2898 2018-05-14 14:46:09 ncopa: should I squash the changes into one per package? 2018-05-14 14:46:20 yeah 2018-05-14 14:46:38 OK, thanks. 2018-05-14 14:49:05 ncopa: where did you push :P 2018-05-14 14:55:39 ok pushed now 2018-05-14 14:55:43 thanks 2018-05-14 14:59:21 hey, I wonder why gcc 8 / 8.1 isn't in aports atm? are there any ongoing effords? 2018-05-14 15:00:15 molle: we're currently at 6.4.0, and we have many patches we'd have to port to newer versions. 2018-05-14 15:00:19 it might take quite a while 2018-05-14 15:00:58 ah took a quick look at it, thought it would be quite some efford porting them over 2018-05-14 15:01:40 do you know if gcc 8.1 is working with musl oob? can't find any info it's working... 2018-05-14 15:01:56 I do not know. Try it and see? ;p 2018-05-14 15:02:07 or ask the proper channel #musl :) 2018-05-14 15:02:13 exactly ;) 2018-05-14 15:02:18 molle: has there ever been any gcc that worked oob with musl? 2018-05-14 15:02:33 i dont even remember an gcc that worked out of the box at all :P 2018-05-14 15:03:00 molle: I am asking/pushing musl dev to merge gcc 7.3 into muls-cross-make so that we can have them in aports 2018-05-14 15:03:12 not sure how things are today, did some gcc bootstrapping when lfs was the hot shit, but that gcc stuff it never felt right ;) 2018-05-14 15:03:34 and it was ages ago 2018-05-14 15:03:35 tmh1999: that would also allow us to compile the kernel with retpoline, yes? 2018-05-14 15:04:12 hey molle how about you going to #musl and rant about it again so musl dev will merge https://github.com/richfelker/musl-cross-make/pull/40 :D 2018-05-14 15:04:51 azarus: that might not be my forte atm :D need a couple of spare days ... 2018-05-14 15:05:07 tmh1999: i might be able to help. 2018-05-14 15:05:24 azarus: noted. thanks o/ 2018-05-14 15:06:55 No problem. 2018-05-14 15:58:43 ncopa: tested and worked. so https://github.com/alpinelinux/mkinitfs/pull/26, this https://github.com/alpinelinux/aports/pull/4062 and this https://github.com/alpinelinux/aports/pull/4213 and we're good to go 2018-05-14 20:07:08 tmh1999: i wonder if we could make the s390x_installer option be non-s390x specific? 2018-05-14 20:31:07 tmh1999: i think i would prefer sshd_pass="secret" 2018-05-14 21:20:19 ncopa: Of course we can do it that way. I will make another PR later. I did it at first place because only s390x people do this kind of (weird) installation kernel + initramfs + parmfile (close to ipxe, but still different) I made it specific to s390x. 2018-05-14 21:21:05 noted this. 2018-05-14 22:23:54 oh you haven't merged the second commit. Okay I will fix the s390x_installer part 2018-05-15 05:40:44 testsuite for stunnel is not suitable for reproducible builds 2018-05-15 05:40:52 they have tests with certs 2018-05-15 05:41:01 and those certs are out of date now 2018-05-15 05:41:06 so tests fails 2018-05-15 06:53:39 jirutka: I've redone what user `tmpfile` wanted to do in PR #1933, in a single commit: https://github.com/alpinelinux/aports/pull/4286 2018-05-15 06:54:32 jirutka: (also, that's with an up-to-date aports tree) 2018-05-15 08:22:42 clandmeter: since you have been working on ipxe 2018-05-15 08:22:52 ok? 2018-05-15 08:23:04 tmh1999 has a PR where he adds a boot option where you can set a root password 2018-05-15 08:23:18 s390x_installer=yes,secret 2018-05-15 08:23:37 if its set, it will install and start ssh and set the password to "secret" 2018-05-15 08:23:56 i wonder if that can be useful for ipxe installs? 2018-05-15 08:24:39 hmm 2018-05-15 08:24:40 im a probably user for that, until now, i just had /etc/shadow in the apkovl, if any password at all 2018-05-15 08:24:47 im thinking to call the boot option sshd_pass="secret" 2018-05-15 08:24:59 why specific to sshd tho? 2018-05-15 08:25:04 but i was thinking of providing ssh key as boot option 2018-05-15 08:25:08 is this how others distros also do it? 2018-05-15 08:25:13 i dont know 2018-05-15 08:25:16 i dont think so 2018-05-15 08:25:29 i think they have special config file 2018-05-15 08:25:38 both password and ssh key can be done by pre-generating an apkovl tarball 2018-05-15 08:25:56 does adding an bootparam for that give an advantage? 2018-05-15 08:25:58 you can supply an ovl on tthe cmdline iirc 2018-05-15 08:26:16 but my question is if it is easier to set custom boot option or pass an apkovl to ipxe 2018-05-15 08:26:43 if you have an working ovl it doesnt matter, else yes. 2018-05-15 08:27:19 ssh_key="ssh-ed25519 AAAAC3....GNZe4 ncopa@ncopa-desktop" 2018-05-15 08:27:40 if its set it will copy the ssh key to /root/.ssh/authorized_keys and start sshd 2018-05-15 08:28:03 why not set it to an url if you do netboot? 2018-05-15 08:28:17 right 2018-05-15 08:28:21 that works too 2018-05-15 08:28:50 does the initramfs support https at this point? 2018-05-15 08:28:50 ssh_key="https://dev.alpinelinux.org/~ncopa/keys/authorized_keys" 2018-05-15 08:28:59 else you would get a pretty big line 2018-05-15 08:29:06 liwakura, yes we do 2018-05-15 08:29:12 good then 2018-05-15 08:29:22 but you need to add libressl to pkgs option. 2018-05-15 08:29:25 ed25519 is not that long 2018-05-15 08:29:31 i really dont like the libressl naming 2018-05-15 08:29:53 i read libressl often like lib-ressl 2018-05-15 08:29:58 it will break setup again when we switch 2018-05-15 08:30:15 apk add cmd:openssl 2018-05-15 08:30:27 ncopa, i think we have libressl hardcoded already in scripts. 2018-05-15 08:30:55 i think fabled also mentiond we should rename it like other distros do. 2018-05-15 08:31:07 how they name it? 2018-05-15 08:31:32 i think it was regarding libssl 2018-05-15 08:31:42 not sure what openssl would be called? 2018-05-15 08:34:17 i think if we would do ssh_key option it should always be over https. so maybe we should make initramfs already fetch openssl binary or dont use bb wget. 2018-05-15 08:35:16 we dont need to do it from initramfs 2018-05-15 08:35:22 technically speaking 2018-05-15 08:36:57 correct, not for the key. 2018-05-15 08:38:49 ncopa, what is the current pr? 2018-05-15 08:41:12 the second patch was not applied: https://github.com/alpinelinux/mkinitfs/pull/26/commits/6b17757a9389dd7a7046c889260c44e1846a4c40 2018-05-15 08:43:03 if its being loaded from an external url, i dont see the advantage over apkovl 2018-05-15 08:44:10 apkovl does it a generic way already, so i see the ssh_key option as reimplementation of an specific aspect of it 2018-05-15 08:44:42 its easier to paste an url than create an apkovl 2018-05-15 08:44:51 its not the same 2018-05-15 08:48:24 i agree this should not be specific to s390 2018-05-15 08:48:43 ncopa, do we have an issue with http://dl-cdn.alpinelinux.org/alpine/latest-stable/main? 2018-05-15 08:48:59 what happens if we switch version? 2018-05-15 08:49:03 and if we decide that apkovl is enough and the way to go, then we should use apkovl for s390x too 2018-05-15 08:49:14 clandmeter: what kind of issue? 2018-05-15 08:49:25 file name in cache 2018-05-15 08:49:31 yes 2018-05-15 08:49:34 how did we solve that before? 2018-05-15 08:50:01 can we purge recursively on that path? or should we redirect? 2018-05-15 08:50:05 manually purge the url from cache 2018-05-15 08:50:38 i wonder if we should set the ttl shorter for .*/latest-stable/.* 2018-05-15 08:50:54 maybe we can redirect from fastly to vXXX 2018-05-15 08:52:07 the ssh_key options sound like a nice simple alternative to ovl. but i have no real preference. 2018-05-15 08:53:08 i wonder how other distros solve this 2018-05-15 08:55:41 i guess we dont have a setup-ovl? 2018-05-15 08:56:10 we dont 2018-05-15 08:56:21 maybe thats the missing key here. 2018-05-15 09:01:37 might be nice to have that as a web service 2018-05-15 09:02:15 key.alpinelinux.org? ;) 2018-05-15 09:02:39 apkovl.alpinelinux.org 2018-05-15 09:03:08 much better. 2018-05-15 09:03:17 where you have a web form with network config (default to dhcp), and can upload an ssh key 2018-05-15 09:03:28 and you get an apkovl to download 2018-05-15 09:03:40 or maybe even a temp url 2018-05-15 09:08:03 im in favour of an script to make generating an base apkovl from scratch easier 2018-05-15 09:09:46 the ssh_key option IMHO makes more sense with the key instead of an url to an keyfile 2018-05-15 09:10:27 because if its loaded via url, it can as well be done via the apkovl mechanism 2018-05-15 09:10:46 It should be a separate project so it can be used by non Alpine users 2018-05-15 09:11:21 is there a case where being able to specify the ssh key via bootparam without network is of benefit? 2018-05-15 09:11:21 apkovls for non-alpine users? 2018-05-15 09:11:24 that doesnt make a terrible lot of sense 2018-05-15 09:11:32 yeah 2018-05-15 09:11:40 and generic curl hosters already exist 2018-05-15 09:11:55 I mean not as your desktop 2018-05-15 09:12:40 Not part of our current setup scripts 2018-05-15 09:13:27 ah, so that its doable from non-alpine systems, that makes sense 2018-05-15 09:13:41 a portable mkapkovl script 2018-05-15 09:14:47 mh, tar stores the uid, and the root ssh key has certain requirements on owner and chmod flags 2018-05-15 09:15:00 not sure if uid->0 can be set with tar in a portable way 2018-05-15 09:15:15 theoretically it can 2018-05-15 09:18:56 ncopa, for netbooting i think we should keep dns format as specified in https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt 2018-05-15 09:19:19 i thought we already added that in our initramfs. 2018-05-15 09:20:41 agree 2018-05-15 09:24:11 btw, apk add cmd:openssl doesnt work, its provided by both libressl and openssl. 2018-05-15 09:24:52 i guess we need to set provider priority to make it work? 2018-05-15 09:24:57 yah 2018-05-15 09:25:59 heh i never used it like this before. 2018-05-15 09:26:18 it kind of makes sense :) 2018-05-15 09:26:53 i finally see the benefit of in increased apkindex. 2018-05-15 09:30:00 i have a relatively safe PR open: #4274, an upgrade to non-free/adobe-flashplayer. Tested with both firefoxes we have. 2018-05-15 09:30:07 argh, algitbot 2018-05-15 09:47:27 azarus, add options="!tracedeps !check" 2018-05-15 09:50:01 azarus, and its probably cleaner to do install -D 2018-05-15 09:52:15 clandmeter: OK 2018-05-15 09:54:00 clandmeter: one could also remove install="", depends_dev="", subpackages="", right? 2018-05-15 09:54:30 and makedepends="" 2018-05-15 09:54:49 yup 2018-05-15 09:55:14 they are automatically added by newapkbuild. 2018-05-15 09:56:08 will amend that commit very soon 2018-05-15 10:00:19 clandmeter: commit amended 2018-05-15 10:01:12 azarus, test your apkbuilds first before submitting them. 2018-05-15 10:01:35 http://tpaste.us/DePR 2018-05-15 10:03:35 clandmeter: argh. the -D broke it 2018-05-15 10:03:50 my bad, never used install(1) like that 2018-05-15 10:05:47 Now it should be truly fixed ;) 2018-05-15 12:43:59 mksully221: can you help with clang? http://build.alpinelinux.org/buildlogs/build-3-8-ppc64le/main/clang/clang-5.0.1-r1.log 2018-05-15 13:02:02 ncopa: this doesn’t make sense, I’ve added linux-headers to makedepends, so sys/sysctl.h should be present; what’s going on? http://build.alpinelinux.org/buildlogs/build-edge-x86/testing/qt5-qtwebengine/qt5-qtwebengine-5.10.1-r0.log 2018-05-15 13:09:42 jirutka: that's wrong 2018-05-15 13:09:51 Shiz: ? 2018-05-15 13:09:53 linux-headers doesn't give you sys/sysctl.h 2018-05-15 13:09:57 it gives you linux/sysctl.h 2018-05-15 13:10:08 musl doesn't include sys/sysctl.h because it's an awful deprecated interface 2018-05-15 13:10:12 ah, crap, you’re right! 2018-05-15 13:10:15 the depenedency should probably be patched out of qtwebengine 2018-05-15 13:10:29 hm, but how’s that it passed on other arches? 2018-05-15 13:10:49 sigh, it's in their vendored ffmpeg 2018-05-15 13:11:16 Shiz: btw, I’m glad to see you here! :) 2018-05-15 13:11:42 it's in libav's cpu.c 2018-05-15 13:11:47 which means it's likely __x86__ guarded 2018-05-15 13:12:49 or the sysctl.h detection code (HAVE_SYSCTL) is different for x86 2018-05-15 13:13:22 i think we should not allow vendoring ffmpeg there if we can avoid it 2018-05-15 13:15:55 Shiz: agree 2018-05-15 13:16:16 ncopa: ^^ 2018-05-15 14:08:02 ncopa: yep, i'll take a look at clang 2018-05-15 14:15:15 the detecion code to fine HAVE_SYSCTL was non-trivial 2018-05-15 14:15:24 i have no clue where the detection code for it is 2018-05-15 14:15:37 and i suspect that there are no detection code for it at all 2018-05-15 14:16:23 they have likely just taken a generated config.h file and committed it to git 2018-05-15 14:16:51 but there are comments in various of those related files that says "generated! dont edit" 2018-05-15 14:17:29 so i sort of figured that it was easier to just comment out sys/sysctl.h which is non-standard anyways 2018-05-15 14:17:37 corect header i unistd.h 2018-05-15 14:25:44 qtwebengine builds but has textrels, so yeah, would be so much better if we could use the system ffmpeg instead of the bundled 2018-05-15 14:49:42 ncopa: you're right 2018-05-15 14:49:44 https://github.com/qt/qtwebengine-chromium/tree/3fa04d22883e42bd987e4f83d394a1040b410024/chromium/third_party/ffmpeg/chromium/config/Chromium 2018-05-15 14:49:46 how hideous 2018-05-15 15:25:18 kaniini: could you please update ca-certificates and add README with instructions how to update it? 2018-05-15 15:44:21 so there is a src/3rdparty/chromium/third_party dir 2018-05-15 15:44:27 nested third parties 2018-05-15 15:44:46 does that mean that it actually is 6th party? 2018-05-15 15:44:54 or 9th party? 2018-05-15 15:46:17 i dont think its possible to build chromium with system ffmpeg 2018-05-15 15:51:04 <_ikke_> jirutka: Probably someting like updating https://git.alpinelinux.org/cgit/ca-certificates/tree/ with https://hg.mozilla.org/mozilla-central/raw-file/tip/security/nss/lib/ckfw/builtins/certdata.txt, release a new version, update the package? 2018-05-15 15:59:10 ncopa: their commit log seems to indicate so 2018-05-15 15:59:27 https://github.com/qt/qtwebengine-chromium/commit/774a269df5bd7f0fc78d043c63edd4f9ddfc168f 2018-05-15 15:59:48 need to set use_system_ffmpeg in chromium/third_party/ffmpeg/ffmpeg_options.gni 2018-05-15 16:01:20 is there no option i can give to qmake? 2018-05-15 16:04:06 -webengine-ffmpeg .............. Use system FFmpeg libraries [system/qt] 2018-05-15 16:04:06 (Linux only) 2018-05-15 16:06:53 we likely aso want -system-icu 2018-05-15 16:07:03 er, -webengine-icu 2018-05-15 16:07:18 i saw that too 2018-05-15 16:07:28 noq, how do i pass those? 2018-05-15 16:07:55 now* 2018-05-15 16:09:40 pass them to qmake 2018-05-15 16:10:12 Natanael Copa: please review https://github.com/alpinelinux/aports/pull/4079 2018-05-15 16:10:46 qmake-qt5 -webengine-ffmpeg -webengine-icu 2018-05-15 16:10:50 gies an error 2018-05-15 16:11:19 what is the error 2018-05-15 16:36:09 Hey! Ive been trying to switch my docker image to alpine, and it uses "tesseract-ocr". I cant seem to find the traineddata that supposedly comes with the package, I see that https://pkgs.alpinelinux.org/contents?branch=v3.7&name=tesseract-ocr&arch=x86_64&repo=community shows /usr/share/eng.traineddata but in my docker image /usr/share/tessdata/ does not. I ran apk add tesseract-ocr, so I dont see why these files are 2018-05-15 16:36:09 missing. 2018-05-15 16:37:44 I realize now the problem was that I was looking at the package list for 3.7 while running 3.6 2018-05-15 16:37:56 Bye everyone 2018-05-15 18:01:49 ***Unknown option -webengine-ffmpeg 2018-05-15 18:01:49 Usage: qmake-qt5 [mode] [options] [files] 2018-05-15 18:05:49 QMAKE_EXTRA_ARGS+="-system-webengine-icu ..." 2018-05-15 18:08:42 ERROR: Feature 'webengine-system-ffmpeg' was enabled, but the pre-condition 'libs.webengine-ffmpeg && features.webengine-system-opus && features.webengine-system-libwebp' failed. 2018-05-15 20:31:56 ncopa: the trick seems to be to pass the -webengine* options after supplying "--" to qmake-qt5, i.e., "qmake-qt5 -- -webengine-icu -webengine-ffmpeg" works for me. The second problem is that "opus-dev" is missing from makedepends as far as I can see. After installing opus-dev, the -webengine-ffmpeg option works for me. 2018-05-15 20:48:30 ncopa: note also that you need to remove config.cache if you have executed qmake-qt5 before installing opus-dev, otherwise qmake won't find opus. 2018-05-15 21:25:10 Michitux: thanks for the tips :) 2018-05-16 05:51:20 bravo for killing those discourse forums. well done friends. 2018-05-16 06:48:06 btw: qtwebengine with -webengine-icu does not compile for me. i have not looked into the particular c++ error though, so i don't know if it is easily fixable. 2018-05-16 07:37:27 Michitux: i also noticed that it does not compile with system icu 2018-05-16 10:50:00 bleb: what discourse forums? 2018-05-16 12:22:59 i made a "small" program that checks if there are any open PRs for the aport you are in (eg the directory) 2018-05-16 12:23:24 ncopa-edge-x86_64:~/aports/community/mongodb$ aports-ghpr | tpaste 2018-05-16 12:23:24 http://tpaste.us/6DpZ 2018-05-16 12:23:54 <_ikke_> ncopa: nice 2018-05-16 12:24:34 ncopa: what does “you are in” mean? that you’re maintainer of the aport? 2018-05-16 12:24:50 if you are in a directory with an APKBUILD 2018-05-16 12:25:01 aaha 2018-05-16 12:25:05 and run aports-ghpr, it will search the PRs 2018-05-16 12:25:10 nice! 2018-05-16 12:25:31 ncopa, that's very nice 2018-05-16 12:25:34 its only nice because you dont know what language I have implemented it it ;) 2018-05-16 12:25:41 <_ikke_> whatabout patches submited on the mailing list :P 2018-05-16 12:25:47 not yet implemented 2018-05-16 12:25:50 but yes 2018-05-16 12:26:06 uh, don’t tell me… :( 2018-05-16 12:27:16 :D 2018-05-16 12:55:51 ncopa: will you share it with us? :) 2018-05-16 13:32:30 Hi was hoping someone could help me, im trying to create a new Alpine Linux package and I seem to be missing a few steps, how do I go about generating the .apk file for the package so I can include it in a new repository 2018-05-16 13:33:59 <_ikke_> nsh_: abuild -r does everything in one go (if all steps succeeded) 2018-05-16 13:34:09 the wiki "creating and alpine package" says about creating an APKBUILD file which I've done but nothing about .apk's 2018-05-16 13:37:30 ncopa, finally you switch to use javascript? 2018-05-16 13:51:19 clandmeter: I afraid that that would be the better option… 2018-05-16 15:53:52 argh 2018-05-16 15:54:30 i merge a PR which adds qt dependecies to gst-plugin-good 2018-05-16 15:54:45 i apparently trust people too much 2018-05-16 15:55:22 ncopa: about code-quality and generally competence? yes, you do ;) 2018-05-16 15:55:36 would be great if someone could come up with a tool that check if packages in main has any dependency in community or testing 2018-05-16 15:55:54 and if packages in community has dependencies in testing 2018-05-16 15:56:00 and integrate that in the travis 2018-05-16 15:56:08 ncopa: this is already checked by Travis… 2018-05-16 15:56:23 when was that introduced? 2018-05-16 15:56:24 ncopa: if pkg has dependency in lower repo, then it simply fails to build 2018-05-16 15:56:30 ncopa: eh, like since ever? 2018-05-16 15:57:11 so why did travis give me green light on this one? 2018-05-16 15:57:17 53a2ede7c4814fc1d6bcf1307cf88dd1a48a016d 2018-05-16 15:57:21 ncopa: https://github.com/alpinelinux/aports/blob/master/.travis/build-pkgs#L34-L50 2018-05-16 15:59:07 oh 2018-05-16 15:59:14 it was not submitted via travis 2018-05-16 15:59:49 yeah, must ben submitted via aports 2018-05-16 15:59:49 I can’t find PR for this 2018-05-16 15:59:55 obviously… 2018-05-16 16:00:06 most of worst patches comes from ML 2018-05-16 16:00:36 so ask yourself why did you merged it… beside this problem, it mixes multiple changes across multiple aports in single commit 2018-05-16 16:01:06 ncopa, clandmeter: on the question if other distros do the ssh + password (instead of ssh key) on root user for the s390x installer: search for sg248354 (page 32/188) for Debian/Ubuntu, or sg248890 (page 31/202) for SUSE, or sg248303 (page 35/108) for Redhat. 2018-05-16 16:01:11 I think we should support both ssh_key="https://dev.alpinelinux.org/~ncopa/keys/authorized_keys" and ssh_pass=secret (or sshd_pass), at least on s390x. 2018-05-16 16:01:17 I thought about apkovl initially but it requires a little bit of touch for the installer for everyone/every password/ssh key, so I think the kernel parameter serves better. 2018-05-16 16:01:21 Sorry was busy yesterday, I will try to make a pr today on. 2018-05-16 16:02:45 so if user provide ssh_key, installer will pick up ssh key, else it will pick up the password. 2018-05-16 16:02:46 jirutka: you are right. then only answer I can come up with is that I completely suck at this and would do the alpine community a favor and quit, so the better people can do the work properly 2018-05-16 16:02:54 ncopa: no tool can help when you allow people bypass them (via ML) 2018-05-16 16:03:04 ncopa: what?! 2018-05-16 16:03:41 ncopa: why this conclusion? 2018-05-16 16:04:10 i dont have better answer than "I suck at this" to why I committed it 2018-05-16 16:05:18 i think i will stop look at patches people send and try focus on fixing the mess i created for now 2018-05-16 16:05:36 ncopa: look, you’ve asked for tool that checks this situation, on Travis, I answered that Travis already checks this; the problem is that you’ve merged bad patch sent via ML, so it bypassed this check; so what can I say? 2018-05-16 16:08:58 guys, please 2018-05-16 16:09:14 :( 2018-05-16 16:09:30 ncopa: you're really good at what you do, don't let yourself be beaten up over it 2018-05-16 16:09:34 everyone makes mistake and that's fine 2018-05-16 16:09:42 alpine needs you 2018-05-16 16:09:48 Shiz: +1 2018-05-16 16:09:49 sorry, im tired 2018-05-16 16:09:53 Shiz: +1 2018-05-16 16:10:00 im not planning to go anywhere 2018-05-16 16:10:09 but i do really suck at reviewing patches 2018-05-16 16:10:26 and no tool can fix that 2018-05-16 16:10:31 if you really feel that way i'd be happy to see what we can do to make that better 2018-05-16 16:10:33 ;p 2018-05-16 16:10:51 nobody's good at everything from the out-set 2018-05-16 16:10:59 although i do feel you've been doing mostly absolutely fine 2018-05-16 16:11:26 feature request: tool that does the same repositry dependency check as the travis tool 2018-05-16 16:11:43 eg check if dependenies are in wrong repo 2018-05-16 16:11:49 that seems nice 2018-05-16 16:12:05 ideally travis would just invoke that 2018-05-16 16:12:05 that works from cli, regarding what you have in your system /etc/apk/repositories 2018-05-16 16:12:06 that might be built-in into abuild, as a warning 2018-05-16 16:12:06 ncopa: don't feel bad about yourself. you are doing great things 2018-05-16 16:12:14 instead of building in functionality into travis 2018-05-16 16:12:33 i think what travis does is good 2018-05-16 16:12:35 and simple 2018-05-16 16:12:51 I don’t think this is the case; when aport depends on dependency in lower repo, it’s quite easy to detect this; and Travis already do this; this is job for computer, no human to check it; the real problem is that we still support Patchwork that has zero automation and its API is unusable for any automation 2018-05-16 16:13:07 and i think we can do a super simple tool that does the same 2018-05-16 16:13:53 ncopa: that “check” in Travis script is basically just a side-effect of setting correct repositories 2018-05-16 16:14:07 i realize that 2018-05-16 16:14:31 ncopa: you can do the same with that chroot feature in abuild 2018-05-16 16:14:37 ncopa: and IIRC it already do it 2018-05-16 16:14:49 there is a .rootbld-repositoies file that shows the proper repos 2018-05-16 16:16:01 abuild should probably simply ignore the /etc/apk/repositories and use the repos from .rootbld-repositories 2018-05-16 16:16:32 Shiz: we’re really not building any extra functionality into Travis… as I said, this is just a side effect of setting correct repositories, all the hard work do lua-aports and apk-tools 2018-05-16 16:17:01 right 2018-05-16 16:20:33 ncopa: and for you, the only way how to improve is to do it more; practice makes perfect ;) 2018-05-16 16:22:09 10 years of practice didnt help... 2018-05-16 16:23:45 problem is the high volume. makes me sloppy when i only want get done with it as soon as possible 2018-05-16 16:23:58 yeah, that’s *the* problem 2018-05-16 16:24:38 just relax on the length of PRs queue, it will not destroy the world when it goes up ;) 2018-05-16 16:25:44 i am afraid of miss the really good ones 2018-05-16 16:25:51 and demotivate the really good contributors 2018-05-16 16:26:11 then cherry-pick just the good/interesting ones instead of handling all of them 2018-05-16 16:26:54 yes, demotivating good contributors is a risk here 2018-05-16 16:46:41 abuild rootbld is a way to do better build checking 2018-05-16 16:46:50 rootbld is gold 2018-05-16 17:07:38 Silver but with some fixed could be gold :) 2018-05-16 17:10:27 ncopa, I wonder if we could get check status in apkindex? 2018-05-16 17:10:50 clandmeter: ?? o.O 2018-05-16 17:12:40 We could show verified packages in pkgs. 2018-05-16 17:12:59 what would that mean? what package is “verified”? 2018-05-16 17:13:22 It they have proper test passed 2018-05-16 17:13:25 all packages in Alpine aports should be verified, this is not like Arch AUR 2018-05-16 17:13:31 what is proper test? 2018-05-16 17:13:43 Testsuites 2018-05-16 17:14:01 how can you decide what testsuite is proper? 2018-05-16 17:14:31 We cannot, we can say they have passed 2018-05-16 17:15:22 just one or two weeks ago I’ve fixed aport with check() function calling `make check` … it passed… that’s good, isn’t it? no, it’s not, it actually didn’t execute any tests 2018-05-16 17:15:43 because of missing deps or something, so it just skipped all the tests 2018-05-16 17:16:14 I don't want to discuss the quality of tests. That's another subject. 2018-05-16 17:16:20 I remember cases when upstream’s test suite passed, but the software actually didn’t work at all 2018-05-16 17:16:54 I just worry about information value of such indicator 2018-05-16 17:18:05 why did linux-hardened get removed entirely, ncopa 2018-05-16 17:18:17 couldn't we have replaced it with https://github.com/copperhead/linux-hardened ? 2018-05-16 17:18:42 You can define the indicator 2018-05-16 17:18:49 Shiz: what’s that? https://github.com/copperhead/linux-hardened 2018-05-16 17:19:19 a somewhat more hardened version of linux than mainline 2018-05-16 17:19:29 by the copperhead guys/former arch linux grsec maintainer 2018-05-16 17:19:32 hmm, what does it offer? 2018-05-16 17:19:41 in comparison with Grsecurity 2018-05-16 17:19:45 i thought the plam had been to replace linux-hardened by this + some custom W^X modules 2018-05-16 17:19:47 does it have PaX? 2018-05-16 17:19:48 if i recall kaniini's plan 2018-05-16 17:19:51 no, it doesn't 2018-05-16 17:20:36 where’s some documentation or info webpage? 2018-05-16 17:21:28 Shiz: yes, replacing it with copperhead is an option. the current linux-hardened was out of date and I had no time to work on it 2018-05-16 17:22:06 ncopa: maybe this can provide better migration for currently linux-hardened users? 2018-05-16 17:22:37 i also thought that copperhead was a "pre" thing, or testing things before it made it to mainline 2018-05-16 17:22:47 not solely 2018-05-16 17:22:50 they have their lts branch 2018-05-16 17:22:55 and they carry patches that upstream won't accept 2018-05-16 17:22:58 (as they dooo.) 2018-05-16 17:23:29 they do actively work with upstream to get stuff in there, doesn't mean it's enabled by default though 2018-05-16 17:24:00 but where is any information about it? 2018-05-16 17:24:34 ha, probably here https://copperhead.co/android/docs/technical_overview#kernel-hardening 2018-05-16 17:26:59 hum 2018-05-16 17:27:06 yeah, it may be worth it 2018-05-16 17:27:42 improved ASLR etc 2018-05-16 17:29:02 reminds me 2018-05-16 17:29:31 i think it would be nice with another kernel flavor, for headless 2018-05-16 17:30:02 for datacenter installs 2018-05-16 17:30:16 eg, without any sound drivers, nor wifi, bluetooth etc 2018-05-16 17:33:10 +1 2018-05-16 17:34:15 but we need some sane way how to manage kernel configs first, currently it’s quite a mess :/ 2018-05-16 17:34:36 so, who know how other distros handle this? 2018-05-16 17:35:36 agree 2018-05-16 17:35:56 i think fedora has some tools and scripts to manage kernel configs 2018-05-16 17:37:08 i havent digged too deep into them, but but i was not that impressed iirc 2018-05-16 17:38:12 there are some tools in the linuxj source tree 2018-05-16 17:38:18 script to merge configs 2018-05-16 17:38:43 and a tool to manipulate the .config from command line 2018-05-16 17:39:07 i wonder if we should run a diff against the default config 2018-05-16 17:39:21 pavlix started https://github.com/crossdistro/kernel-tools some time ago, but I don’t know what is the current state 2018-05-16 17:41:29 ncopa: friendly reminder, do you think you will have time to look at this change https://github.com/alpinelinux/aports/pull/4057/files during this week? 2018-05-16 17:42:06 HRio: Have you tested it? 2018-05-16 17:43:09 no, but William has, I have no hardware unused to run an @edge hypervisor on. 2018-05-16 17:43:35 but hoping to upgrade some hypervisors to 3.8 2018-05-16 17:43:52 we should merge that before 3.8 release 2018-05-16 17:44:00 and would like to avoid gummiboot... 2018-05-16 17:44:04 +1 2018-05-16 17:45:05 jirutka: can you investigate what options we have to do the kernel configs properly? 2018-05-16 17:45:30 ncopa: yes, I’ll look at it 2018-05-16 17:45:40 it would be great if we could use the scripts provided with linux sources 2018-05-16 17:50:45 jirutka: the state hasn't changed but it works and can be improved easily 2018-05-16 17:51:17 jirutka: especially if there's a use case in a distribution 2018-05-16 18:01:04 ncopa: ^ 2018-05-16 18:01:22 jirutka: i saw 2018-05-16 18:01:45 HRio: what do you think about this: http://tpaste.us/m5jd 2018-05-16 18:05:15 pavlix: do you know what SUSE use for managing kernel configs? 2018-05-16 18:06:58 jirutka: not really but my project is based on original work by Vlastimil Babka and I'm pretty sure he knows 2018-05-16 18:07:38 pavlix: Vlasta works at Prague’s SUSE office, right? 2018-05-16 18:08:06 jirutka: yep 2018-05-16 18:08:22 jirutka: and there will be openSUSE summit in Prague soon 2018-05-16 18:08:33 jirutka: s/summit/conference/ 2018-05-16 18:08:45 jirutka: https://events.opensuse.org/conference/oSC18 2018-05-16 18:09:11 interesting, Hody never mentioned it (or I just wasn’t listening…) 2018-05-16 18:09:15 any reason for removing mesa wayland support? 2018-05-16 18:11:08 https://github.com/alpinelinux/aports/commit/257a236f57bd5db6fc51ae9f9b52c4e24e236596 2018-05-16 18:11:17 this breaks anything using wayland and mesa 2018-05-16 18:12:23 opendata: the commit message refers to https://github.com/alpinelinux/aports/commit/4f8b36b3d0a8bf9034f433465a276b5658292b76 2018-05-16 18:12:34 pavlix: okay, added to my calendar; will you attend? 2018-05-16 18:12:47 jirutka: I'm registered and going to attend 2018-05-16 18:12:59 opendata: i thought the library moved from mesa sources to wayland 2018-05-16 18:13:20 wayland-libs-egl 2018-05-16 18:15:14 ncopa: well mesa still needs to be compiled with wayland support 2018-05-16 18:16:26 i thought it was a module or plugin 2018-05-16 18:17:20 nope, still need the platform enabled 2018-05-16 18:17:25 lib shouldn be needed though 2018-05-16 18:17:45 opendata: can you please create a PR which reverts it and explain why it is wrong. with links to documentation preferable 2018-05-16 18:18:00 also, we need make sure we dont introduce circualr deps 2018-05-16 18:18:15 eg: you need wayland to build mesa and mesa to build wayland 2018-05-16 18:18:39 opendata: i have no clue how it is supposed to work 2018-05-16 18:19:48 people send patches and I assume they know what they are doing :-( 2018-05-16 18:19:58 https://github.com/mesa3d/mesa/search?utf8=%E2%9C%93&q=+with_platform_wayland&type= 2018-05-16 18:20:05 this enough 2018-05-16 18:20:58 opendata: care to make a PR? 2018-05-16 18:21:05 ncopa: updated, tested, and worked. https://github.com/alpinelinux/mkinitfs/pull/27/. 2018-05-16 18:22:50 yeah, 10min, just wanna clean up bms driver first 2018-05-16 18:23:19 ncopa: "people send patches and I assume they know what they are doing :-(" … well, as you said few hours ago, "i apparently trust people too much" :( 2018-05-16 18:24:28 ncopa: Thanks for merging EFI. Got your link forwarded by HRio, I think it looks good. I just joined via web here so might have missed some history. 2018-05-16 18:26:40 ncopa: that’s why it’s needed to ask contributors to clarify everything you’re not sure about 2018-05-16 18:27:41 please let this one go, lessons learned. let's move on. 2018-05-16 18:28:13 have a cup of tea and a couple of biscuits :D 2018-05-16 18:28:16 radhus_: thanks for the contribution! 2018-05-16 18:28:39 tmh1999: its actually a beer on the balcony :) 2018-05-16 18:28:59 ncopa: even better haha 2018-05-16 18:29:39 opendata: sorry for breaking it 2018-05-16 18:34:00 ncopa: basically Wayland provides libwayland-egl.so and mesa provides libEGL.so with Wayland extension support 2018-05-16 18:35:02 So mesa should depend on Wayland and not other way around 2018-05-16 18:35:55 what is libwayland-egl.so? 2018-05-16 18:36:07 does it link to mesa? 2018-05-16 18:47:26 ncopa: libwayland-egl.so is frontend library which deals with clients basically 2018-05-16 18:47:32 https://github.com/wayland-project/wayland/commit/549a5ea710f4da1a5749587176d39fef1ded4077 2018-05-16 18:47:44 It doesn't link to mesa 2018-05-16 18:49:12 ncopa: basically if I understand correctly.. confusion that happened here is driver/platform v/s the client library 2018-05-16 18:50:46 but enabling the wayland platform also enable build of client lib? 2018-05-16 18:50:51 in mesa 2018-05-16 18:54:14 ncopa: I am not sure.. but if it does I think you can just dump binary file and not package it 2018-05-16 18:57:32 so to recap, wayland should be built first, mesa depends on wayland, wayland should provide the egl client library 2018-05-16 18:58:36 Right 2018-05-16 19:00:33 can you make a PR with it? 2018-05-16 19:01:31 I can tomorrow 2018-05-16 19:02:05 https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/mesa#n187 see e.g archlinux does this 2018-05-16 19:04:08 bshah[m]: thank you 2018-05-16 19:10:05 bshah[m]: im building it here. do you have suggestion for a good commit message? 2018-05-16 19:13:14 ncopa: for mesa, re-enable drm platform and prefer libwayland-egl from wayland 2018-05-16 19:18:37 bshah[m], opendata: pushed 2018-05-16 19:19:07 Yay, thanks 2018-05-16 19:24:22 any python/django experts know what this is about? http://build.alpinelinux.org/buildlogs/build-3-8-x86_64/main/py-django-phonenumber-field/py-django-phonenumber-field-1.3.0-r0.log 2018-05-16 19:39:46 <_ikke_> other than the obvious fact that some initilization is missing, no idea 2018-05-16 21:11:00 jirutka: this might be helpful to manage configs: https://github.com/torvalds/linux/blob/master/scripts/kconfig/merge_config.sh 2018-05-16 21:18:03 ncopa: seems that some builds are not correct. see https://pkgs.alpinelinux.org/packages?name=py2-pip&branch=edge 2018-05-16 21:18:03 it is in version "9.0.3-r0" in ppc64le, maybe it built the correct version but did not upload it properly? 2018-05-16 21:19:36 ncopa: I also saw this same problem in geth package (https://pkgs.alpinelinux.org/packages?name=geth&branch=edge) it is still in version 1.8.3-r0 on ppc64le 2018-05-16 21:21:04 rdutra: are you sure its build correctly? 2018-05-16 21:22:10 clandmeter: well I just built py2-pi in my ppc64le container and it build fine 2018-05-16 21:22:37 clandmeter: and I guess if it failed it should be reported at: http://build.alpinelinux.org/ , right? 2018-05-16 21:24:00 http://build.alpinelinux.org/buildlogs/build-edge-ppc64le/main/py2-pip/py2-pip-10.0.1-r0.log 2018-05-16 21:24:43 clandmeter: so yes, build correct 2018-05-16 21:24:58 clandmeter: maybe did not upload correctly? 2018-05-16 21:25:01 i guess it means the builder is not happy 2018-05-16 21:25:14 something is blocking 2018-05-16 21:25:24 could also be a config issue 2018-05-16 21:25:29 recently we updated something 2018-05-16 21:25:33 i can take a look 2018-05-16 21:26:51 clandmeter: umm but ithe new version was build on 11 May 2018-05-16 21:27:05 clandmeter and I guess clang in failing to build on ppc64le edge some days ago 2018-05-16 21:27:20 maybe thats why it did not build the new version of py2-pi yet :-/ 2018-05-16 21:27:34 you have access to the builder? 2018-05-16 21:28:05 clandmeter: yes I have and it build the version 10.0.1-r0 2018-05-16 21:28:20 to the edge builder? 2018-05-16 21:28:32 guess it is what I said, as main/clang is failing to build it did not upload community packages yet 2018-05-16 21:28:39 yes, edge builder for ppc64le 2018-05-16 21:29:59 i think this one is not updated to upload to new host. 2018-05-16 21:30:43 I see 2018-05-16 21:30:54 guess it is ok, my mistake 2018-05-16 21:32:31 clandmeter: thanks 2018-05-16 21:33:20 ok edge is updated 2018-05-16 21:33:30 maybe need to take a look at stable builders 2018-05-16 21:34:19 clandmeter guess when all packages from main in edge build successfully it will upload packages from community 2018-05-16 21:35:52 rdutra: in confd of mqtt-exex... you need to change the upload host 2018-05-16 21:36:17 well not change but add upload_host=dl-master.alpinelinux.org 2018-05-16 21:36:32 make sure buildozer can ssh to it and restart mqtt-exec. 2018-05-16 21:37:50 upload_host=dl-master.alpinelinux.org 2018-05-16 21:37:56 clandmeter it is already there 2018-05-16 21:38:06 yes for edge 2018-05-16 21:38:11 but all builders need it 2018-05-16 21:40:01 clandmeter ok I just did for 3.8 and restarted the mqtt-exec 2018-05-16 21:40:36 I will do for the others too 2018-05-16 21:40:42 thx! 2018-05-17 06:50:32 gst-plugins-base is broken on edge https://dpaste.de/WBxd/raw 2018-05-17 08:22:47 rdutra: problem is that build fails on ppc64le. it will not upload anything til the full repo is built 2018-05-17 08:23:49 fcolista: it may be a plugin? 2018-05-17 08:23:56 if its not, then it is an underlinking problem 2018-05-17 08:24:07 ncopa, how can I figure? 2018-05-17 08:24:54 readelf will tell if libgstaudio-1.0.so.0 is directly linked 2018-05-17 08:25:31 maybe with apk search too 2018-05-17 08:25:47 apk search so:libgstautio-1.0.so.0 2018-05-17 08:26:59 returns nothing 2018-05-17 08:27:03 apk search so:libgstautio-1.0.so.0 2018-05-17 08:27:17 ops 2018-05-17 08:27:18 sorry 2018-05-17 08:27:19 apk search so:libgstaudio-1.0.so.0 2018-05-17 08:27:19 gst-plugins-base-1.14.0-r1 2018-05-17 08:28:26 apk search -r 2018-05-17 08:28:37 will tell if something needs the lib 2018-05-17 08:28:47 if nothing needs the lib, then it is dlopened 2018-05-17 08:29:26 https://dpaste.de/Uy5H/raw 2018-05-17 08:29:51 several packages requires gst-plugin-base 2018-05-17 08:29:56 hum 2018-05-17 08:30:19 doesnt make sense with the 0.10 2018-05-17 09:07:43 ncopa, should I bump gst-plugins-base and trigger the rebuild? 2018-05-17 09:21:56 ncopa: I see, thanks 2018-05-17 09:59:01 fcolista: i doubt it helps 2018-05-17 09:59:41 umh 2018-05-17 09:59:47 I can't understand the problem 2018-05-17 10:01:48 when do you get error? 2018-05-17 10:02:03 when I run subtitleeditor 2018-05-17 10:02:16 which has, as dependecy, gst-plugins-base 2018-05-17 10:03:50 so I checked who owned libgstaudio-1.0.so.0 2018-05-17 10:04:09 tried ldd /usr/lib/ and got the errors of symbols missing 2018-05-17 10:04:19 *ldd /usr/lib/libgstaudio-1.0.so.0 2018-05-17 10:07:44 what does apk version say? 2018-05-17 10:08:05 $ ldd /usr/lib/libgstaudio-1.0.so.0 | tpaste 2018-05-17 10:08:05 http://tpaste.us/9KqK 2018-05-17 10:09:36 apk version gst-plugins-base 2018-05-17 10:09:36 Installed: Available: 2018-05-17 10:09:36 gst-plugins-base-1.14.0-r1 = 1.14.0-r1 2018-05-17 10:10:16 http://tpaste.us/nqDM 2018-05-17 10:10:16 and apk policy gst-plugins-base 2018-05-17 10:10:47 apk policy gst-plugins-base 2018-05-17 10:10:47 gst-plugins-base policy: 2018-05-17 10:10:47 http://nl.alpinelinux.org/alpine/edge/main 2018-05-17 10:10:47 1.14.0-r1: 2018-05-17 10:10:47 lib/apk/db/installed 2018-05-17 10:10:48 i got mine from main 2018-05-17 10:11:26 so ldd works now? 2018-05-17 10:11:33 i cannot reproduce it 2018-05-17 10:11:49 ncopa, no tpaste does not paste the error 2018-05-17 10:12:01 sorry, didn't checked it 2018-05-17 10:12:27 https://dpaste.de/rxTf 2018-05-17 10:13:09 $ md5sum /usr/lib/libgstaudio-1.0.so.0 2018-05-17 10:13:09 922982bec22567e905704229ab2334b7 /usr/lib/libgstaudio-1.0.so.0 2018-05-17 10:13:13 what arch is it? 2018-05-17 10:13:18 x86_64 2018-05-17 10:13:31 md5sum /usr/lib/libgstaudio-1.0.so.0 2018-05-17 10:13:31 922982bec22567e905704229ab2334b7 /usr/lib/libgstaudio-1.0.so.0 2018-05-17 10:13:50 that's strange.. 2018-05-17 10:14:09 its not /usr/lib/libgstaudio-1.0.so.0 that is linked wrong 2018-05-17 10:16:15 huh 2018-05-17 10:17:14 nm -D /usr/lib/libgstaudio-1.0.so.0 | grep gst_aggregator_pad_peek_buffer 2018-05-17 10:17:43 shows that libgstaudio-1.0.so.0 uses gst_aggregator_pad_peek_buffer 2018-05-17 10:17:49 wow..is there 2018-05-17 10:17:49 $ nm -D /usr/lib/libgstaudio-1.0.so.0 | grep gst_aggregator_pad_peek_buffer 2018-05-17 10:17:49 U gst_aggregator_pad_peek_buffer 2018-05-17 10:18:09 nm -D /usr/lib/libgstbase-1.0.so.0 | grep gst_aggregator_pad_peek_buffer 2018-05-17 10:18:30 U means symbol is undefined 2018-05-17 10:18:40 ih 2018-05-17 10:18:44 oh 2018-05-17 10:18:45 which means you need link to a library that provides it 2018-05-17 10:19:20 gstreamer1.0 2018-05-17 10:19:27 https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer-libs/html/GstAggregatorPad.html 2018-05-17 10:19:30 apparently it is libgstbase-1.0.so.0 that provides it 2018-05-17 10:19:54 $ nm -D /usr/lib/libgstbase-1.0.so.0 | grep gst_aggregator_pad_peek_buffer 2018-05-17 10:19:54 0000000000017b44 T gst_aggregator_pad_peek_buffer 2018-05-17 10:20:11 so..it's missing something that provides itself? 2018-05-17 10:20:25 the T means: The symbol is in the text (code) section. 2018-05-17 10:20:58 libgstaudio-1.0.so.0 needs to link to libgstbase-1.0.so.0 2018-05-17 10:21:35 which it does: 2018-05-17 10:21:37 $ readelf -d /usr/lib/libgstaudio-1.0.so.0 | grep libgstbase 2018-05-17 10:21:37 0x0000000000000001 (NEEDED) Shared library: [libgstbase-1.0.so.0] 2018-05-17 10:22:02 scanelf -l -s /usr/lib/libgstaudio-1.0.so.0 | grep gstba 2018-05-17 10:22:02 ET_DYN - /usr/lib/libgstbase-0.10.so.0.30.0 2018-05-17 10:22:02 ET_DYN - /usr/lib/libgstbase-1.0.so.0.1200.0 2018-05-17 10:22:28 fcolista: can you verify that your /usr/lib/libgstbase-1.0.so.0 provides gst_aggregator_pad_peek_buffer? 2018-05-17 10:22:29 ls -l /usr/lib/libgstaudio-1.0.so.0 2018-05-17 10:22:29 lrwxrwxrwx 1 root root 27 Apr 10 14:30 /usr/lib/libgstaudio-1.0.so.0 -> libgstaudio-1.0.so.0.1400.0 2018-05-17 10:22:45 $ nm -D /usr/lib/libgstbase-1.0.so.0 | grep gst_aggregator_pad_peek_buffer 2018-05-17 10:23:02 seems that it tried sto load 1200 while the file is symlink to 1400 2018-05-17 10:23:03 ok 2018-05-17 10:23:31 nm -D /usr/lib/libgstbase-1.0.so.0 | grep gst_aggregator_pad_peek_buffer 2018-05-17 10:23:31 2ua4020qdl:~$ 2018-05-17 10:23:33 nothing 2018-05-17 10:23:44 thats the problem 2018-05-17 10:23:57 lrwxrwxrwx 1 root root 26 Apr 9 13:01 /usr/lib/libgstbase-1.0.so.0 -> libgstbase-1.0.so.0.1400.0 2018-05-17 10:24:05 yes 2018-05-17 10:24:06 if you do: apk version 2018-05-17 10:24:09 1400 against 1200 2018-05-17 10:24:17 no args more than that 2018-05-17 10:24:24 shoudl show you which packages are outdated 2018-05-17 10:24:33 oh 2018-05-17 10:24:37 gstreamermm 2018-05-17 10:24:41 Installed: Available: 2018-05-17 10:24:41 freerdp-libs-2.0.0_rc1-r1 < 2.0.0_rc2-r0 2018-05-17 10:24:41 py2-gobject3-3.24.1-r2 < 3.28.2-r0 2018-05-17 10:24:41 freerdp-plugins-2.0.0_rc1-r1 < 2.0.0_rc2-r0 2018-05-17 10:24:41 wayland-1.14.0-r2 < 1.15.0-r0 2018-05-17 10:24:42 dynamips-0.2.16-r3 < 0.2.18-r0 2018-05-17 10:24:44 gstreamermm-1.8.0-r0 < 1.8.0-r1 2018-05-17 10:24:46 barman-2.2-r0 < 2.3-r0 2018-05-17 10:24:48 byobu-5.123-r1 < 5.125-r0 2018-05-17 10:24:50 freerdp-2.0.0_rc1-r1 < 2.0.0_rc2-r0 2018-05-17 10:24:52 ops 2018-05-17 10:24:54 sorry 2018-05-17 10:25:56 $ apk info --who-owns /usr/lib/libgstbase-1.0.so.0.1400.0 2018-05-17 10:25:56 /usr/lib/libgstbase-1.0.so.0.1400.0 is owned by gstreamer-1.14.0-r0 2018-05-17 10:26:22 apk info --who-owns /usr/lib/libgstbase-1.0.so.0.1400.0 2018-05-17 10:26:22 ERROR: /usr/lib/libgstbase-1.0.so.0.1400.0: Could not find owner package 2018-05-17 10:26:33 use the .1200.0 2018-05-17 10:26:46 apk info --who-owns /usr/lib/libgstbase-1.0.so.0.1400.0 2018-05-17 10:26:46 ERROR: /usr/lib/libgstbase-1.0.so.0.1400.0: Could not find owner package 2018-05-17 10:26:49 ops 2018-05-17 10:26:53 # apk info --who-owns /usr/lib/libgstbase-1.0.so.0.1200.0 2018-05-17 10:27:11 apk info --who-owns /usr/lib/libgstbase-1.0.so.0.1200.0 2018-05-17 10:27:13 ok 2018-05-17 10:27:24 put a space in front of / so irc client does not eat it 2018-05-17 10:27:28 /usr/lib/libgstbase-1.0.so.0.1200.0 is owned by gstreamer1-1.12.0-r0 2018-05-17 10:27:30 yes right 2018-05-17 10:27:37 aha 2018-05-17 10:27:41 gstreamer1 2018-05-17 10:27:54 can you apk del gstreamer1 2018-05-17 10:28:09 hehe 2018-05-17 10:28:11 yse 2018-05-17 10:28:12 yes 2018-05-17 10:28:17 that's weird; hasn't it been 'gstreamer' without the '1' for some time? and I thought it had replaces... 2018-05-17 10:28:46 i think its pulled in by depends=so:libgstbase.so.0 2018-05-17 10:28:56 so apk didnt find any reason to replace it 2018-05-17 10:29:28 interesting 2018-05-17 10:29:52 i guess `apk version -l '?'` can give you more packages it doesnt know who to upgrade 2018-05-17 10:30:27 https://dpaste.de/oow3/raw 2018-05-17 10:38:07 ncopa, so what does it mean that packages doesn't know who to upgrade? 2018-05-17 11:15:15 yes, it means that apk does not find any of those in the index 2018-05-17 11:15:32 so apk does not know what to do with them 2018-05-17 11:18:04 i need to remove them then 2018-05-17 11:18:11 and reinstall 2018-05-17 11:18:19 maybe apk fix 2018-05-17 12:44:19 ncopa: any comment for the latest mkinitfs stuff when you have a chance ? 2018-05-17 13:30:13 ncopa: community/secure-delete is failing to build because the project url is off (maybe the project was removed). should we use the source from another location like launchpad.net or maybe remove the project? 2018-05-17 13:30:54 tmh1999: im looking at it now 2018-05-17 13:32:20 rdutra1: i guess that depends if secure-delete is completely dead upstream and nothing else depends on it or if project moved to launchpad 2018-05-17 13:32:35 if its dead upstream and nothing uses it, then im ok to delete it 2018-05-17 13:34:29 ncopa: nothing depends on it but I'm not sure yet if it is completely dead upstream, didnt find any info about that 2018-05-17 13:40:40 oh kernel parameter in initramfs-init are parsed with prefix KOPT_ 'dasd' will be KOPT_dasd. Strange thing I just use $dasd without any problem. 2018-05-17 13:41:47 just find out this now 2018-05-17 13:42:03 testing again with KOPT_ ... 2018-05-17 13:42:44 tmh1999: this is done by the kernel 2018-05-17 13:43:04 the kernel puts any bootparams it doesn't know into the environment of PID 1 2018-05-17 13:43:17 liwaura: interesting 2018-05-17 13:43:25 why does the initramfs still parse it then, you might ask? 2018-05-17 13:43:42 because parameters like root= are known by the kernel, but we still need it in the initramfs 2018-05-17 13:44:31 liwakura: even more interesting. thanks ! 2018-05-17 13:45:11 just thinking if we want an unified form for KOPT_dasd KOPT_s390x_net, just in case 2018-05-17 14:23:36 ncopa: I think there is a convention/standard somewhere about the parm list for configure_ip(). I wanted to put dns in there at first be was skeptical. 2018-05-17 14:27:42 nfsroot, right 2018-05-17 14:28:19 thanks for the link. that's interesting. 2018-05-17 16:07:19 ncopa: ping again as I updated according to your comments :D 2018-05-17 16:53:03 I'm playing with building Alpine for armel 2018-05-17 16:54:02 I understand that the start is to run "bootstrap.sh armel" in aports' scripts/ directory. 2018-05-17 16:55:21 It works for other architectures not built upstream, but I get the following output: https://paste.debian.net/hidden/75d7484e/ 2018-05-17 16:56:56 (I tried it for "armv7" as an example, which did start to build binutils, suggesting something else is the problem here.) 2018-05-17 17:08:39 Should be noted I'm in the abuild group, have passwordless sudo enabled for the user that will build packages, etc 2018-05-17 17:09:01 with full access to distfile cache etc 2018-05-17 17:47:00 dancan^: maybe passing set -x to abuild to see more fine-grained debug log 2018-05-17 17:48:06 duncan^: ^ 2018-05-17 18:19:38 Sorry, I'm not sure how to do that - abuild doesn't have a -x option (but I think that's not what you meant, sorry) 2018-05-17 18:45:17 duncan^: its a shell script you can run it with sh -x scriptname 2018-05-17 18:45:35 duncan^: but you can do the same by adding -v 2018-05-17 19:17:34 OK... https://paste.debian.net/hidden/ce57d3cf/ 2018-05-17 19:17:44 I guess it is showing a little bit more information. 2018-05-17 19:17:59 Not really sure how to proceed 2018-05-17 19:20:26 clandmeter: how are named Alpine’s rooms in Matrix? 2018-05-17 19:29:03 duncan^: we need to passing 'set -x' to whatever script/code printing this : ">>> binutils-armel: Analyzing dependencies..." 2018-05-17 19:29:16 maybe passing 'set -x' inside binutils's APKBUILD file too 2018-05-17 19:29:26 let me check again to refresh my memory on this 2018-05-17 19:30:48 I'm not an arm guy but are you sure 'armel' is the right target/toolchains name ? 2018-05-17 19:31:48 'armv5' ? 2018-05-17 19:32:04 fabled knows this better than anyone else 2018-05-17 19:33:58 yeah 'armel' seems to be correct 2018-05-17 19:34:05 https://git.alpinelinux.org/cgit/abuild/tree/functions.sh.in 2018-05-17 19:37:28 firing the bootstrap.sh armel to see if I have your problems 2018-05-17 19:39:47 I think your problem either relates to your ~/packages/ directory or your Alpine host's apk database is corrupted 2018-05-17 19:40:13 ./boostrap.sh armel is flying on my x86_64 qemu just fine 2018-05-17 20:23:51 Ah, OK 2018-05-17 20:33:46 re: idea for having more modular modules/firmware files (though not very neat) 2018-05-17 20:33:49 1. have meta .modloop (with basic/core files) 2018-05-17 20:33:50 2. rest files that presently are in .modloop will be a symlink 2018-05-17 20:33:50 eg. 3com -> _3com (_3com directory needs to be present in .modloop) 2018-05-17 20:33:54 3. once installer does smart detection it gets 3com.apk (having 3com.sfs) 2018-05-17 20:33:54 and mounts it in /.modloop/_3com. 2018-05-17 20:33:59 Likewise can be done with other brand/company folders, finer filewise 2018-05-17 20:33:59 control also possible. 2018-05-17 20:34:04 ncopa,clandmeter1 ^^ 2018-05-17 20:35:59 tmh1999: It is working now. How odd. Anyway, thank you for your help! 2018-05-17 20:45:08 eg, all iwlwifi-*.ucode in firmware/ can be but in one squashfs file 2018-05-17 20:45:24 can be put* 2018-05-17 20:47:28 ncopa: update on clang build break for ppc64le. gdb shows stack corruption on clang-5.0 call to llvm5 MutexImpl. Its detected by stack protector code and a musl abort() is issued. It appears to have been introduced by using the binutils upgrade from 2.28 to 2.30. I'm planning to do a git bisect of binutils to see if I can isolate the specific patch. It will take a while since for each binutils git bisect I'll have to rebuild clang 2018-05-17 20:47:29 with the new binutils to test :-( 2018-05-17 22:10:36 I've been running the bootstrap script for armel. 2018-05-17 22:10:48 It fails on go-bootstrap, with the error "unsupported arch". 2018-05-17 22:11:08 It has the following set for arch: "all !aarch64 !ppc64le !s390x" 2018-05-17 22:11:25 Now, I thought I could append either "armel" or "!armel" to it. 2018-05-17 22:11:25 is it abuild or go that is complaining? 2018-05-17 22:11:52 abuild's complaining looks like this: 2018-05-17 22:11:54 I think it's abuild. 2018-05-17 22:11:54 Package not available for the target architecture (ppc64). Aborting. 2018-05-17 22:12:04 Hmm, maybe not then.. One second 2018-05-17 22:12:19 then that is a problem with go and you should go yell at google for being absolutely impossible to work with 2018-05-17 22:12:34 i.e. https://github.com/golang/go/issues/19074 2018-05-17 22:12:44 awilfox: +1 ^_^ 2018-05-17 22:13:09 duncan^: did you set GOARM=5? 2018-05-17 22:13:25 Should abuild at least not just ignore the package if I append !armel there? 2018-05-17 22:13:41 duncan^: "!armel" is telling it "this package does not work on armel, so skip it" 2018-05-17 22:14:10 duncan^: it already has "all", which means "any architecture you specify"; then it has the three ! which means "these three architectures are not supported, so don't build it for them" 2018-05-17 22:14:54 Well, I added !armel and it is still attempting to build it. 2018-05-17 22:15:04 I guess something could be pulling it in as a dependency? 2018-05-17 22:15:40 bootstrap.sh specifically has go-bootstrap in the list of packages to build 2018-05-17 22:15:48 just remove it from bootstrap.sh I guess, if you don't care about go 2018-05-17 22:16:13 oh I see. 2018-05-17 22:16:38 /usr/src/aports/community/go/APKBUILD:62:*) die "Unsupported arch" ;; 2018-05-17 22:17:24 so you will need to add something like 2018-05-17 22:17:39 armel) export GOARCH="arm" GOARM="5";; 2018-05-17 22:17:41 to that case statement 2018-05-17 22:17:46 I've added that... one sec 2018-05-17 22:17:48 but then it will require a 'go' package, which you won't have 2018-05-17 22:19:10 It says >>> ERROR: go-bootstrap: provides must not contain go-bootstrap 2018-05-17 22:19:21 stupid thing 2018-05-17 22:19:22 yeah 2018-05-17 22:19:36 what is going on is you don't have an older 'go' package to put in there 2018-05-17 22:19:43 so it can't make the bootstrap package properly 2018-05-17 22:19:58 I'd have to bootstrap that from a version I can build, I guess. 2018-05-17 22:20:10 Which is... problematic 2018-05-17 22:20:16 go 1.4.x can build go 1.x where x > 1.5 2018-05-17 22:20:22 you can bootstrap it from another architecture that supports go, but you need to be able to manually build apk files 2018-05-17 22:21:52 I have put !armel in go's arch. I will look at this when my experiment is over. 2018-05-17 22:22:21 I had written 'apkkit' for such a thing, but it's a nasty hack 2018-05-17 22:30:22 It also fails here: /usr/bin/abuild: cd: line 2609: can't cd to /home/pmos/aports/main/linux-vanilla/src/build-vanilla: No such file or directory 2018-05-17 22:31:04 I've looked at abuild line 2609, and it's not clear why it's saying that, since line 2609 just says "done" 2018-05-17 22:31:32 above it, it references runpart. but this has nothing to do with that. 2018-05-17 22:33:37 oh, you're doing a pmos build? 2018-05-17 22:33:46 also, that's an issue in the linux-vanilla APKBUILD I'd guess 2018-05-17 22:33:49 not the abuild itself 2018-05-17 22:51:05 I may be mixing repos... 2018-05-17 22:51:14 (not doing a pmos build per se) 2018-05-17 22:51:27 yeah, makes sense 2018-05-17 22:52:03 last time I bootstrap go on s390x, I need go 1.4 2018-05-17 22:52:32 the current community/go-boostrap does not work 2018-05-17 22:53:15 it might need a little bit of human touch 2018-05-17 22:57:40 the issue is I had not created the config-vanilla.armel file. which of course makes sense and I have been terribly silly in that respect 2018-05-17 22:59:47 anyway, off-topic, I really enjoy bootstrap-ing and compiling Alpine from source. The current state is (has always been) very simple to pick up for newbies. Never be able to wrap my mind on Debian/RHEL/SUSE build infrastructure. 2018-05-17 23:01:22 a hack is you install go from Alpine, use it to build your go, if you don't mind doing that. 2018-05-17 23:03:55 another way as Xe mentioned, build go 1.4 by hand, uses it to build your go. 2018-05-17 23:04:03 we (adelie, fork of alpine) are actually writing a guide on brining alpine/adelie to a new architecture actually: early draft at http://support.adelielinux.org/html/porting/bootstrapping.html 2018-05-17 23:06:11 +1 2018-05-17 23:07:45 Nice. 2018-05-17 23:20:14 Not sure how to get my kernel config to work... I've copied the kernel config from the kernel's multi_v5_defconfig. However, the build process wants me to add a load of other options. What's the best way to go about that? 2018-05-17 23:21:15 compile the kernel with your config by hand first then copy the config to build with APKBUILD ? 2018-05-17 23:24:47 I guess... that will take some time though 2018-05-17 23:25:11 duncan^: make oldconfig 2018-05-18 08:13:05 mksully22: have you tested to build clang with binutils-2.28? 2018-05-18 08:29:49 i have tested now 2018-05-18 08:29:52 you are right 2018-05-18 08:50:59 mksully22: \o/ i found it 2018-05-18 08:51:06 https://sourceware.org/ml/binutils/2018-03/msg00183.html 2018-05-18 08:51:55 and this: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=d66deb71f1537e2e30dccdfda22eed5d46ec47eb 2018-05-18 09:09:25 mksully22: i pushed fix for binutils 2018-05-18 09:31:48 re: finding deps issues 2018-05-18 09:31:48 would suggest new addition to abuild, like 2018-05-18 09:31:48 abuild deps --simulate --checkfor=testing,community --checkerrorlog=/tmp/packagename.deps.log 2018-05-18 09:33:33 ncopa, jirutka ^^ 2018-05-18 09:35:46 vkrishn: my problem is that i dont have time to do it, so it woudl be nice if someone else could do it 2018-05-18 09:35:59 i have have various ideas on how it could be implemented 2018-05-18 09:36:05 but will such method solve the issue ? 2018-05-18 09:36:47 it will not solve the issue with not having time 2018-05-18 09:37:02 abuild rootbld should fix it though 2018-05-18 09:41:16 ok 2018-05-18 09:42:34 idk what this is all about, but what I do is just have a chroot that I use for building all the time... rootbld never worked right for me, idk why, but having a chroot used just for building avoids having any of my normal stuff 'hidden' as a dep 2018-05-18 09:43:57 awilfox: in chroot, do you build as root or 'normal' user 2018-05-18 09:46:13 re: howto make a new apkovl 2018-05-18 09:46:13 I usually do in virtual(qemu) environment. It solves for most of my setups. 2018-05-18 09:46:16 qemu-system-x86_64 -cdrom alpine-standard-3.7.0-x86_64.iso -hda /tmp/temp.ext4.img -boot d 2018-05-18 09:46:56 mps: /etc, /home, and /usr/src are bind-mounted 2018-05-18 09:46:59 as are /dev and /dev/pts 2018-05-18 09:47:02 then i extract apkovl from temp.ext4.img 2018-05-18 09:47:12 so it is still 'me' 2018-05-18 09:47:18 (not /etc/apk though) 2018-05-18 09:47:33 :) 2018-05-18 09:48:10 chroot syscall requires root permissions 2018-05-18 09:48:38 awilfox: I had similar chroot setup, but I chroot as root then 'su - mps' and run abuild as mps 2018-05-18 09:49:14 tried to 'chroot -u mps' but that doesn't work 2018-05-18 09:49:36 I'm missing Debian schroot on Alpine 2018-05-18 09:50:29 and setting lxc container for build looks like overkill 2018-05-18 09:51:12 abuild rootbld is a light container 2018-05-18 09:51:33 wow... v3.8/main is built for x86_64 2018-05-18 09:51:47 especially because I have build env for four arch-es 2018-05-18 09:53:14 ncopa: nice! 2018-05-18 09:53:15 ncopa: ah, didn't know for abuild-rootbld package. Any guide about it 2018-05-18 09:53:57 basically, run: abuild rootbld 2018-05-18 09:54:15 and it will use bubblewrap to create a container during build 2018-05-18 09:54:18 ok, will look at it 2018-05-18 09:54:35 i think there are cornercases where it does not work 2018-05-18 09:54:45 schroot looks nice 2018-05-18 09:54:47 mps, I did somewhat naughty thing maybe. I have a little script that is setuid that chroots to /opt/build 2018-05-18 09:54:49 ooh 3.8 is out soon? 2018-05-18 09:54:58 I have seen 'rootbld' option for abuild but didn't know how it works 2018-05-18 09:56:10 awilfox: I also have script to start chroot with some tweaks but was not satisfied with it 2018-05-18 11:14:26 ncopa: guess v3.8/main is also build for ppc64le 2018-05-18 11:14:47 yes! 2018-05-18 11:18:42 seems like haveged need some privileges to run the testsuite in container 2018-05-18 11:18:55 i dunno if we should disable havegd testsuite? 2018-05-18 12:06:13 seems like haveged is broken on armhf and aarch64 2018-05-18 12:06:18 dunno why 2018-05-18 12:07:48 i think its the same as this: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866306 2018-05-18 12:54:29 ncopa: good find on binutils patch to get clang build working again for ppc64le...saved me a lot of git bisecting :) 2018-05-18 15:03:24 ncopa: updated the pr again 2018-05-18 15:04:27 nice! 2018-05-18 15:05:12 tmh1999: have you tested that it works? 2018-05-18 15:06:16 ncopa: Have not tested the last change (remove passing --silent to apkflags), but have tested before that change 2018-05-18 15:06:31 last change was like non functional so it won't affect anything, I think 2018-05-18 15:06:31 ok 2018-05-18 15:06:56 i think this is a really nice feature 2018-05-18 15:07:04 I hope it would be :D 2018-05-18 15:07:34 tbh never thought about it before until you mentioned it would be nice for other archs in general 2018-05-18 15:08:06 clandmeter: are you able to test the ssh_key/ssk_pass boot option with ipxe? https://github.com/alpinelinux/mkinitfs/pull/27 2018-05-18 15:09:38 Yes sir 2018-05-18 15:10:38 wonderful 2018-05-18 15:10:49 clandmeter: Thank you sir 2018-05-18 15:11:24 i think this should be mentioned in release notes 2018-05-18 15:11:32 o/ 2018-05-18 15:12:23 when you write it please let me know as I also want to note that it's bootable in z/VM hypervisor 2018-05-18 15:13:15 yes! 2018-05-18 15:23:41 clandmeter: sir, would you mind a minute to approve ? https://github.com/alpinelinux/mkinitfs/pull/27 2018-05-18 15:36:28 tmh1999: you mention you tried this setup right? 2018-05-18 15:36:44 clandmeter: Yes sir 2018-05-18 15:37:01 using kernel + initramfs 2018-05-18 15:37:08 with ssh key over https? 2018-05-18 15:37:30 somethign is broken with perl-date-manip on 32 bit systems 2018-05-18 15:37:34 no clue why 2018-05-18 15:37:44 Oh I just test http since my server does not have https. Let me try again with https github 2018-05-18 15:37:58 1 sec 2018-05-18 15:38:10 i think we have an issue with bb wget 2018-05-18 15:38:11 i think we also need the /usr/bin/openssl binary in the initramfs 2018-05-18 15:38:34 yes we should have it included. 2018-05-18 15:38:42 okay. working on it. 2018-05-18 15:38:58 that is for the net boots 2018-05-18 15:41:37 do we want to allow fetching key from ftp? 2018-05-18 15:45:54 clandmeter: ssl binary is pulled since openssh is pulled in, and fetching https://github.com/tmh1999.keys works 2018-05-18 15:46:12 am I right on that ssl part ? 2018-05-18 15:46:18 guess I'm right 2018-05-18 15:46:37 tmh1999: why is this included in the initramfs instead of openrc like modloop fetching? 2018-05-18 15:47:31 clandmeter: because s390x works that way (kernel + initramfs as boot media) and my intention is to support s390x using this method. but since ncopa mentioned it could be generalized. 2018-05-18 15:47:49 openssh pulls in openssl? 2018-05-18 15:47:57 or libressl i mean 2018-05-18 15:48:10 clandmeter: only the libs i think 2018-05-18 15:48:19 libressl 2018-05-18 15:48:21 not openssl 2018-05-18 15:48:22 yes 2018-05-18 15:48:26 tmh1999: ok im just wondering if the initramfs is the right place to do it. 2018-05-18 15:49:14 clandmeter has a point 2018-05-18 15:49:38 the benefit wit this is that we dont need to add another /etc/init.d/* service 2018-05-18 15:51:10 https://imgur.com/a/Inyd99K 2018-05-18 15:51:47 output from dumb terminal 2018-05-18 15:51:56 libressl libs 2018-05-18 15:52:58 hum, interesting. I never thought about initramfs is not the right place ... but I have no choice. If you want me to make this s390x-specific thing instead of ssh-thing, I will revert. 2018-05-18 15:53:30 this is not s390x specific i think? 2018-05-18 15:53:49 moving it to a service like modloop would work also for x390x right? 2018-05-18 15:54:12 im not saying we should, just questioning it. 2018-05-18 15:54:15 I don't know if other distros do this kind of installation on other archs 2018-05-18 15:54:26 but if moving to modloop, we might need a modloop image 2018-05-18 15:54:36 no forget about modloop 2018-05-18 15:54:40 its just an example 2018-05-18 15:55:28 So, during my implementation, I wrote a service s390x-installer.init. 2018-05-18 15:55:32 That works 2018-05-18 15:55:45 I think that's what you mean 2018-05-18 15:56:29 but it seems ncopa doesn't want this /etc/init.d/s390x-installer service 2018-05-18 15:56:35 what i mean is, we can keep it out of initramfs and move it to something called ssh_install.initd 2018-05-18 15:56:42 yeah right 2018-05-18 15:57:00 that's what I'm saying 2018-05-18 15:57:04 i wonde if we should make it more general 2018-05-18 15:57:11 anc call it "first-boot" 2018-05-18 15:57:27 its not supposed to the way you start sshd 2018-05-18 15:57:42 crap my system keeps crashing. 2018-05-18 15:57:44 its just a first-boot thing so you can install remotely 2018-05-18 15:57:44 we can call it anything, but are you in favor of it or not ncopa ? because you mentioned you didn't want it that way 2018-05-18 15:58:11 im gonna go out for a run 2018-05-18 15:58:15 its nice weather 2018-05-18 15:58:19 agreed 2018-05-18 15:58:40 okay I will come up with another PR for this so ncopa and clandmeter could decide which one you like more 2018-05-18 15:58:52 and (annoyingly) ping you 2018-05-18 15:58:53 :D 2018-05-18 15:58:56 it woudl be awesome if someone could help me with perl-date-manip on 32bit systems 2018-05-18 15:59:06 im sort of ok with the way you do it now 2018-05-18 15:59:08 its simple 2018-05-18 15:59:34 if the boss is ok im also ok ;-) 2018-05-18 15:59:41 clandmeter: :P 2018-05-18 15:59:49 lets push it then 2018-05-18 15:59:57 im going out 2018-05-18 15:59:59 well does it have openssl? 2018-05-18 16:00:26 tmh1999: can you verify that when you are booted openssl is available? 2018-05-18 16:00:30 clandmeter: i was thinking of adding /usr/bin/openssl to /etc/mkinitfs/features/files.netboot 2018-05-18 16:00:35 or what the feature is 2018-05-18 16:00:39 ncopa: just go out we can do it later. I need to backport to aports/mkinitfs anyway. 2018-05-18 16:00:47 ncopa: ok thats possible 2018-05-18 16:00:53 clandmeter: no openssl sir 2018-05-18 16:00:53 i didnt need it for netboot 2018-05-18 16:01:09 i need it for modloop fetching 2018-05-18 16:01:15 so i could add it to pkgs 2018-05-18 16:01:32 thats why i question the implementation 2018-05-18 16:01:36 clandmeter: new system (with curl just installed for tpaste.us) http://tpaste.us/05Oz 2018-05-18 16:02:19 tmh1999: bb wget has no ssl support, except if openssl is available (the executable). 2018-05-18 16:02:34 it does work for ssl, but its fake. 2018-05-18 16:02:38 okay 2018-05-18 16:02:41 damn 2018-05-18 16:02:46 it ignorers certs 2018-05-18 16:02:52 gotcha 2018-05-18 16:03:01 so we should prevent that. 2018-05-18 16:03:09 we should actually fix wget 2018-05-18 16:03:13 in bb 2018-05-18 16:03:36 to not allow this mode except explicit requested. 2018-05-18 16:04:00 but thats another issue :) 2018-05-18 16:04:04 clandmeter: so patch in aports/busybox ? 2018-05-18 16:04:22 I can't fix that in this commit :( 2018-05-18 16:04:31 you can i think 2018-05-18 16:05:03 how so ? 2018-05-18 16:05:05 for this setup, do you need an initramfs with netboot support? 2018-05-18 16:05:16 as a feature i mean 2018-05-18 16:05:49 i guess you need networking modules? 2018-05-18 16:05:51 yes, initramfs fetches initial packages 2018-05-18 16:06:26 those initial packages are in normal ISO (irrc) 2018-05-18 16:07:12 i guess we can add openssl to features 2018-05-18 16:07:17 like ncopa suggested 2018-05-18 16:07:20 okay 2018-05-18 16:07:37 you will need that if you push this. 2018-05-18 16:07:56 thanks I will make it 2018-05-18 16:08:32 clandmeter: for the record I agree with you on the point making a new initd service to do these things :) 2018-05-18 16:08:52 that service just has to live for this purpose only 2018-05-18 16:09:32 i think the goal is to keep the init as small as possible. 2018-05-18 16:09:50 agreed 2018-05-18 16:10:43 the nice thing is, netboot will need to fetch less and will be faster on initial boot. 2018-05-18 16:11:12 but it will have to fetch the rest with apk. 2018-05-18 16:14:11 clandmeter: guess I need to add 'netboot' as a kernel parm option then ? 2018-05-18 16:14:34 kernel parm? 2018-05-18 16:15:05 you need to add openssl to https://github.com/alpinelinux/mkinitfs/blob/master/features.d/network.files 2018-05-18 16:15:46 if you want openssl binary to be available in initramfs. 2018-05-18 16:19:33 I thought it would be new kenrel parm https://git.alpinelinux.org/cgit/mkinitfs/tree/initramfs-init.in#n269 since ncopa mentioned : mkinitfs/features/files.netboot 2018-05-18 16:20:02 features.d/network.files seems fine though 2018-05-18 16:20:16 yes but i wonder if that works 2018-05-18 16:20:32 cause we have multiple packages which provides openssl. 2018-05-18 16:20:53 what works ? netboot.files or network.files ? 2018-05-18 16:21:13 forget about files.netboot, it was a typo from ncopa 2018-05-18 16:21:24 its network.files 2018-05-18 16:21:32 okay 2018-05-18 16:21:34 lol 2018-05-18 16:21:47 you add specific files to it 2018-05-18 16:21:59 and mkinitfs will auto add deps i believe. 2018-05-18 16:22:25 let me see when I build the image (using aports/scripts) with debug info, what it will pull in as /usr/bin/openssl 2018-05-18 16:22:51 but i wonder how that works if multiple packages provides /usr/bin/openssl 2018-05-18 16:23:14 could be we need to set provides_priority 2018-05-18 16:31:20 i wonder if there are ppl here who are using alpine without openrc on baremetal? 2018-05-18 16:32:10 clandmeter: how wget package itself rather than bb's wget. it does work with https here without openssl. 2018-05-18 16:32:18 *how about 2018-05-18 16:32:33 it also ignores certs ? 2018-05-18 16:32:46 you mean regular wget? 2018-05-18 16:32:49 yeah 2018-05-18 16:32:52 apk add wget 2018-05-18 16:32:56 regular wget should work 2018-05-18 16:33:15 but i think its even bigger to include into initramfs 2018-05-18 16:33:27 interesting 2018-05-18 16:34:05 for netboot i include libressl with pkgs kernel ops 2018-05-18 16:34:24 but i could also use wget instead. 2018-05-18 16:38:13 clandmeter: http://tpaste.us/qo75 openssl is heavier 2018-05-18 16:38:42 maybe adding wget initramfs is not a bad idea 2018-05-18 16:39:06 did you calculate the deps? 2018-05-18 16:39:33 openssl and deps are 4MiB 2018-05-18 16:39:40 wget less than 1 MiB 2018-05-18 16:39:46 the paste shows it 2018-05-18 16:40:22 but having regular wget means, we will have it all the time :) not sure it's acceptable :) 2018-05-18 16:41:18 maybe it's good thing since bb's wget is broken anyway 2018-05-18 16:43:08 let me check locally 2018-05-18 16:43:28 sure 2018-05-18 16:45:29 easier to see : http://tpaste.us/N7yZ 2018-05-18 16:46:44 http://tpaste.us/xeOr 2018-05-18 16:47:46 yeah I just pulled libressl instead of openssl. the sizes are not different so much 2018-05-18 16:47:50 okay let me see 2018-05-18 16:47:59 thanks 2018-05-18 16:56:12 Found a package conflict: https://gist.github.com/trinitronx/846a2561871c6ec3f1e7e16330c00588 2018-05-18 16:57:19 TrinitronX: we use libressl 2018-05-18 16:57:26 so make it lbressl-dev 2018-05-18 16:58:45 libressl-dev... 2018-05-18 17:02:12 tmh1999: i think we should create an issue for wget on bugs.a.o 2018-05-18 17:02:25 clandmeter: roger that. will do 2018-05-18 17:02:29 today 2018-05-18 17:02:39 i can create it and tag ncopa on it. 2018-05-18 17:02:47 Seems that fixes the package conflict... will try rebuild 2018-05-18 17:02:49 thanks 2018-05-18 17:03:07 wget without https support is useless 2018-05-18 17:03:13 +1 2018-05-18 17:03:23 how did you find out btw ? 2018-05-18 17:03:26 wget without proper https support is insecure 2018-05-18 17:03:35 when testing with netboot 2018-05-18 17:03:42 my man 2018-05-18 17:04:07 without libressl its also kind of broken 2018-05-18 17:04:15 i dont remember the real behaviour anymore 2018-05-18 17:05:27 from what understand now it would make sense to just drop wget https support completely from busybox. 2018-05-18 17:11:14 clandmeter: I added /usr/bin/openssl to features.d/network.files, add 'network' to initramfs in aports/scripts. Here is log building and still no openssl in the initramfs though. http://tpaste.us/ykwn 2018-05-18 17:11:19 any idea ? 2018-05-18 17:12:15 oh I think I knows 2018-05-18 17:12:55 need to add 'libressl' package to apks= in mkimg.standard.sh too 2018-05-18 17:13:19 no that shouldnt be 2018-05-18 17:14:23 yeah still no openssl... wonder how 2018-05-18 17:14:26 have a guest brb 2018-05-18 17:14:39 https://bugs.alpinelinux.org/issues/8917 2018-05-18 17:14:52 seems algitbot doesnt like to announce anymore. 2018-05-18 17:14:57 algitbot: hi 2018-05-18 17:32:56 right apks= are for initial packages in ISO 2018-05-18 17:33:33 now need to make mkinitfs to pull in /usr/bin/openssl 2018-05-18 17:35:32 so your take is to use regular wget as default ? Okay 2018-05-18 17:36:12 we need ncopa back to approve bugs.a.o #8917 so I can proceed with my current github pr... 2018-05-18 17:36:26 <_ikke_> wut? 2018-05-18 17:36:31 :D 2018-05-18 17:36:40 <_ikke_> ah ok 2018-05-18 17:38:55 with this weather you can wait all day long :p 2018-05-18 17:39:22 im getting hungry, i need some sushi 2018-05-18 17:40:28 sushi sounds good 2018-05-18 17:44:36 I was in Japan, sushi so good and pretty cheap. I ate so so much and next morning I smell like a mobile piece of sashimi :D 2018-05-18 17:44:42 <_ikke_> Now I'm hungry :/ 2018-05-18 17:49:15 tmh1999: im looking at mkinitfs, I dont know how its supposed to find and include openssl automatically. 2018-05-18 17:50:02 yep I'm working on it. but if #8917 is approved and we use regular wget, then no need to worry about this openssl anyway 2018-05-18 17:50:32 it's friday again ... 2018-05-18 17:51:25 already saturday somewhere 2018-05-18 17:52:52 #8917 2018-05-18 17:52:58 thats better :) 2018-05-18 17:53:03 :D 2018-05-18 19:37:21 i'm available this weekend so if you want to work on this i'd be here,just ping me 2018-05-18 20:55:30 I've been trying to compile & test nginx + ldap module support most of the day, and am finding that it compiles but with warning that may be causing breakage when actually using HTTPS 2018-05-18 20:56:05 Compile log warns of OpenSSL version... which was the same one I can't install due to libressl conflict 2018-05-18 20:56:08 https://gist.github.com/trinitronx/846a2561871c6ec3f1e7e16330c00588#file-nginx-compile-openldap-openssl-md 2018-05-18 20:57:33 @clandmeter: Any way to force install & ignore conflicts just for the compile stage? 2018-05-18 21:00:53 hmm... nevermind... maybe this will work: `apk add --force-broken-world openldap-dev openssl-dev` 2018-05-18 21:26:38 ok, still broken: `/usr/src/nginx-auth-ldap-42d195d7a7575ebab1c369ad3fc5d78dc2c2669c/ngx_http_auth_ldap_module.c:33:18: fatal error: ldap.h: No such file or directory` 2018-05-18 21:28:32 <_ikke_> TrinitronX: and openldap-dev is being installed? 2018-05-18 21:30:00 Not sure... looks from output that things end up getting purged... I'll try without the --virtual flag to apk 2018-05-18 21:30:38 This time looks like it complains of missing OpenSSL: `./configure: error: SSL modules require the OpenSSL library.` 2018-05-18 21:33:02 Ok, so when I try to install them with --force-broken-world, it looks like it skips the conflicting ones? 2018-05-18 21:33:06 `apk add --no-cache --force-broken-world gcc libc-dev make openssl-dev openldap-dev pcre-dev zlib-dev linux-headers curl gnupg` 2018-05-18 21:33:17 output does not have openssl-dev or openldap-dev as installed 2018-05-18 21:43:25 How can I list what files are owned by an apk package? 2018-05-18 21:47:27 apparently it's: `apk info -L openldap-dev` 2018-05-18 21:47:55 based on observations, `apk info -L` only returns files if the package is installed 2018-05-18 21:48:55 However, it returns no files for either openldap-dev or openss-dev after running: `apk add --force-broken-world openssl-dev openldap-dev` 2018-05-18 21:49:04 so apparently it silently purges both? 2018-05-18 21:49:38 Which means `--force-broken-world` does not do what it sounds like, and installs nothing when packages conflict 2018-05-18 22:23:37 TrinitronX: try use libressl-dev instead of openssl-dev. system openldap is built with libressl, so mixing that with openssl is problem 2018-05-19 01:09:42 Right, let's say I've got a package that builds requisite libraries from its source code, but requires them to be installed already. 2018-05-19 01:09:59 In order to build the subpackages, I guess one has to build the main package, then the subpackage. 2018-05-19 01:10:20 I guess in this situation, it makes most sense to create a separate package for the requisite package? 2018-05-19 01:24:43 ncopa: ping on bind port (2 remote vulnerabilities) - sent PR (https://github.com/alpinelinux/aports/pull/4314) 2018-05-19 19:07:51 The xfs_scrub_all program from xfsprogs-4.16.1 needs python3. How should I handle that dependency? 2018-05-19 19:18:42 azarus: is it a subpkg? 2018-05-19 20:09:09 tmh1999: around? 2018-05-19 20:22:55 clandmeter: yes 2018-05-19 20:23:00 clandmeter: xfsprogs-extra 2018-05-19 20:23:46 which progs does it have? 2018-05-19 20:24:18 if it has more useful things, its probably better to split the one which deps on python. 2018-05-19 20:24:55 clandmeter: only xfs_scrub_all has the dependency on python, all others are fine 2018-05-19 20:26:00 azarus: did you read what i said? 2018-05-19 20:26:36 yes. I do not see the point in seperating them more. 2018-05-19 20:27:16 right then ill leave you at it. 2018-05-19 20:28:00 sure. since -extra is suppposed to be *extra*, i don't see how adding python3 to its deps hurts that much 2018-05-19 20:28:48 because it sounds crazy to pull in python to do fs related tasks. 2018-05-19 20:29:29 the -extra package contains all programs not necessary for most operations 2018-05-19 20:30:29 in fact, you don't even need xfsprogs to mount xfs filesystems at all. 2018-05-19 20:32:49 standard fsck is also handled by the kernel, so xfs_repair is only really needed if you *really* mess up your xfs 2018-05-20 20:49:37 I'd like to package diod, a 9p file server. It builds and it runs. One question: the test suite the server has an extensive test suite, what sort of checks should be done in check()? 2018-05-20 20:50:11 <_ikke_> usually the provided test suite 2018-05-20 20:50:14 Also, some checks depend on mounting a 9p filesystem and/or having valgrind installed. 2018-05-20 20:50:18 <_ikke_> azarus: how long does it take? 2018-05-20 20:50:27 _ikke_: haven't run the checks yet. 2018-05-20 20:50:36 <_ikke_> ok 2018-05-20 20:50:44 There's a userspace suite of checks. 2018-05-20 20:50:53 which doesn't require root or 9p kernel support. 2018-05-20 20:50:56 <_ikke_> I'm not sure how you'd handle such system dependencies 2018-05-20 20:51:14 <_ikke_> those are more integration tests 2018-05-20 20:52:12 I'll try running the userspace suite of checks -- a second 2018-05-20 20:53:59 Some fail, some work. 2018-05-20 21:07:45 Yay, writing a init.d file for diod now ;) 2018-05-20 21:22:00 Strange. In package() i `mv` the init.d and conf.d file to their appropriate places, but they're symlinks, and they have mode 777? 2018-05-20 21:22:07 Is this normal? 2018-05-20 21:22:19 <_ikke_> no 2018-05-20 21:22:29 <_ikke_> where are they symlinks 2018-05-20 21:23:24 _ikke_: http://tpaste.us/kWK4 2018-05-20 21:24:05 <_ikke_> azarus: did you copy te files in src? 2018-05-20 21:24:15 I did: 2018-05-20 21:24:23 <_ikke_> well, those *are* symlinks 2018-05-20 21:24:31 ah, I should cp, not mv 2018-05-20 21:24:33 <_ikke_> abuild symlinks files from the rootdir to src 2018-05-20 21:24:38 <_ikke_> azarus: right 2018-05-20 21:24:47 ACTION goofed 2018-05-20 21:25:47 Yup, now they're not symlinks and they have the correct mode. 2018-05-21 05:55:00 clandmeter: I had a discon yesterday, didn't see your message till not. Working on your comment on github pr. 2018-05-21 06:28:06 I want add a raspberry pi 3 bluetooth package, can I just create a PR in main? Or should create it in testing? 2018-05-21 06:35:35 yangxuan8282[m]: I think testing is the right place 2018-05-21 07:00:08 tmh1999 (IRC): what the requirements of move into main? 2018-05-21 07:01:08 yangxuan8282[m]: it's kind of vague. depends on urgency, necessity, importance of the package/maintainer/submitter, etc. 2018-05-21 07:02:04 I'm not the one who could make the decision to move to main but you could always ask here during UTC office hours time 2018-05-21 07:02:49 tmh1999 (IRC): thanks 2018-05-21 07:02:59 +1 2018-05-21 07:04:24 tmh1999: hi 2018-05-21 07:04:46 clandmeter: hello 2018-05-21 07:05:24 working on a draft will send in a couple of hours 2018-05-21 07:06:47 nice 2018-05-21 07:07:49 did you move it to an openrc service? 2018-05-21 07:07:57 clandmeter: yes 2018-05-21 07:08:13 isn't that what you wanted ? 2018-05-21 07:08:18 even ncopa doesn't lol 2018-05-21 07:08:31 I'm fine with both since I've implemented both earlier 2018-05-21 07:08:44 i played a bit with an initd. 2018-05-21 07:09:17 ncopa didnt? 2018-05-21 07:10:44 clandmeter: check irc log #alpine-dev at : 2018-05-18 15:49:38 2018-05-21 07:11:33 which tz? 2018-05-21 07:12:02 tbh, as I mentioned earlier, I like the initd approach, even thought it requires me more work atm as current commit is prety reeady 2018-05-21 07:12:04 http://dev.alpinelinux.org/irclogs/%23alpine-devel-2018-05.log 2018-05-21 07:14:52 yes but afterwards he mentioned first-boot. 2018-05-21 07:15:09 yeah, I guess he's 50-50 on this. 2018-05-21 07:15:24 we're to decide then :) 2018-05-21 07:15:37 as long as you dont bother him too much :) 2018-05-21 07:15:52 I have done that already lol 2018-05-21 07:16:22 well i like the idea, so i dont mind spending some time on it. 2018-05-21 07:16:53 agreed 2018-05-21 07:29:08 clandmeter: re: removing password login in sshd_config. Currently I do it in setup-disk.in. But maybe we can do it in stop() in first-boot.initd, and in setup-disk.in where we remove modloop, we can # rc-service first-boot stop, and remove first-boot like modloop. Is it good ? 2018-05-21 07:32:50 didnt look into setup-disk, does it keep the disk mounted after setup? 2018-05-21 07:34:01 no, it won't keep dist mounted. I will stop first-boot and remove it at here : setup-disk, does it keep the disk mounted after setup? 2018-05-21 07:34:11 no, it won't keep dist mounted. I will stop first-boot and remove it at here : https://git.alpinelinux.org/cgit/alpine-conf/tree/setup-disk.in#n419 2018-05-21 07:34:58 how does initd know how to remove the password? 2018-05-21 07:34:59 current implementation: https://github.com/alpinelinux/alpine-conf/pull/14/commits/22528eb0c2c8508f795c317c15dfb27f0a70fa08#diff-b2f524e6db4cdd2452eee320c2386e3bR492 2018-05-21 07:36:42 i mean stop will run after setup-disk right? so you need to know which disk to remove the password from? 2018-05-21 07:37:24 clandmeter: not after setup-disk. to be exact, during final steps of setup-disk 2018-05-21 07:38:19 in setup-disk, not after setup-disk 2018-05-21 07:39:22 does it make sense ? 2018-05-21 07:43:07 it makes sense in setup-disk :) 2018-05-21 07:43:20 :D 2018-05-21 07:46:41 tmh1999: i guess you use ssh_pass? 2018-05-21 07:46:48 yes 2018-05-21 07:47:08 i'm testing 2018-05-21 07:47:17 let's see if this thing works 2018-05-21 07:50:15 tmh1999: i did this to pull in wget http://tpaste.us/6DmZ 2018-05-21 07:54:53 that's nice. do you want to add openssh package in init or in first-boot.initd 2018-05-21 07:55:11 init 2018-05-21 07:55:16 okay 2018-05-21 07:55:48 im thinking about alpine_repo. 2018-05-21 07:56:26 not sure yet how to do that properly. 2018-05-21 07:57:42 does my current setup of ALPINE_REPO affect netboot ? 2018-05-21 07:58:04 it would affect anything using ssh feature. 2018-05-21 08:00:03 on other arch, does using ssh feature mean that they need initial packages pulled from remote ? Because on s390x it is. If this is also true on other arch, I see no problem here. 2018-05-21 08:00:26 what if i want to boot an iso with ssh feature? 2018-05-21 08:00:30 correct 2018-05-21 08:00:34 that's what I'm thinking 2018-05-21 08:00:42 so let's make it s390x thing, you think ? 2018-05-21 08:00:59 instead of checking ssh_key/ssh_pass to set ALPINE_REPO, let's make it s390x check 2018-05-21 08:01:05 not sure ncopa is happy with this 2018-05-21 08:01:29 you wan this to limit your cmdline i guess? 2018-05-21 08:02:01 how do you mean ? 2018-05-21 08:02:07 sorry 2018-05-21 08:02:22 i mean you can specify this as a boot option. 2018-05-21 08:02:49 so you are setting it as default so you dont need to. 2018-05-21 08:02:50 well I could. At first I did s390x_installer=yes in cmdline, and it was not accepted 2018-05-21 08:03:27 I also dont like it :). but 2018-05-21 08:03:44 if we need some things to make you happy we can discus it. 2018-05-21 08:04:01 $(apk --print-arch) ? 2018-05-21 08:05:19 during normal boot (not installation) from disk, setting ALPINE_REPO is harmless right ? so let's do if [ "$(apk --print-arch)" = "s390x" ]; then ALPINE_REPO=xxx; fi 2018-05-21 08:07:02 that's 2 options. 2018-05-21 08:07:24 what im saying is, you can do this already by setting this as a boot arg. so you are doing this only for a specific arch just to leave it out of the boot arg? 2018-05-21 08:08:51 last time I check boot arg on s390x is limited to 256 char... not sure if it fits. let me check again. 2018-05-21 08:09:02 ah 2018-05-21 08:09:10 then it makes sense :) 2018-05-21 08:09:37 there's method to allow more than 256 chars but I don't know if I could dig in that archaic stuff atm since I need this to get done asap 2018-05-21 08:09:49 let me check and test and come back to you 2018-05-21 08:11:33 i guess that makes the ssh_key also kind of useless for you 2018-05-21 08:12:13 let me guess, all of this info was already in the PR :) 2018-05-21 08:12:26 not really. it depends. last time it worked 2018-05-21 08:14:05 so what we want is some minimal boot option to set the default repo? 2018-05-21 08:14:41 give a couple of min, I'm testing :D 2018-05-21 08:15:23 im just thinking out loud :) 2018-05-21 08:15:30 you can put me on ignore. 2018-05-21 08:15:54 :P 2018-05-21 08:19:04 i think we could make this better 2018-05-21 08:19:33 detect it we have network, cannot find local repo and use default http. 2018-05-21 08:46:05 clandmeter: which is the option to force override world ? I did # ap add package.apk before, now wwanted to install from official remote repo 2018-05-21 08:46:25 aka override by official repo 2018-05-21 08:51:16 okay 2018-05-21 09:41:05 tmh1999: ? 2018-05-21 09:41:28 no nothing, I'm fixing some PEBKAC 2018-05-21 10:16:49 Might it be a good idea to split the linux man-pages from the POSIX man pages also shipped with it? 2018-05-21 10:16:52 maybe a subpackage? 2018-05-21 10:21:35 I'd find it neat to have a "man-pages", which contains the linux man pages and a "man-pages-posix" which contains the POSIX man pages. 2018-05-21 10:29:25 azarus: as we discus on #alpine-linux, I think there is a bug 'man' 2018-05-21 10:29:41 it should handle 'man 3p printf' 2018-05-21 10:29:52 mps: are you experiencing the bug too? 2018-05-21 10:30:03 of course 2018-05-21 10:30:18 Oh, interesting. 2018-05-21 10:30:26 But not quite the same as me, right? 2018-05-21 10:30:47 like you, actually 2018-05-21 10:31:01 Great, reproducible issue. 2018-05-21 10:31:54 heh, not great, but issue is there :) 2018-05-21 10:32:00 We can bother ncopa about it then, as he's the maintainer for main/man-pages and main/mdocml 2018-05-21 10:32:44 better if could resolve issue, and then bother maintainer 2018-05-21 10:33:12 Sure. I don't have any more ideas tough :/ 2018-05-21 10:33:18 bah, s/if could/if we could/ 2018-05-21 10:34:13 I'll look at mdocml to see if could do something about issue 2018-05-21 10:34:38 mps: I tried bothering the guys in #openbsd, they didn't know further. 2018-05-21 10:35:26 can't tell anything till I try to see if I can find cause of the issue 2018-05-21 10:35:50 Sure, let me know if you find anything. 2018-05-21 10:37:18 ok 2018-05-21 10:37:35 just reading configure file 2018-05-21 10:58:16 azarus: 3p section is reserved for Perl Library Manual 2018-05-21 10:58:26 clandmeter: I have it working, would you mind merging your patch at http://tpaste.us/6DmZ ? 2018-05-21 10:58:28 mps: yes, on OpenBSD 2018-05-21 10:58:38 we don't have that on Alpine afaik 2018-05-21 10:58:44 don't know why in AL posix man have 3p in names 2018-05-21 10:58:57 mps: 'p' for POSIX 2018-05-21 10:59:08 tmh1999: can you add it to yours? 2018-05-21 10:59:16 i wnat my stuff reviewed :) 2018-05-21 10:59:26 clandmeter: okay :D 2018-05-21 10:59:36 azarus: I know, but mdocml man thinks it should be perl 2018-05-21 11:00:09 clandmeter: one correction, I would propose to remove ssh_key ssh_pass in init, move them all to the first-boot, since I have get them in there anyway 2018-05-21 11:00:49 mps: the precedence for mandoc is: 1, 8, 6, 2, 3, 5, 7, 4, 9, 3p 2018-05-21 11:00:51 in init just install wget 2018-05-21 11:00:59 like http://tpaste.us/m5ld ? 2018-05-21 11:01:04 also, we should rename mdocml -> mandoc 2018-05-21 11:01:10 mdocml is the historical name 2018-05-21 11:01:21 probably 2018-05-21 11:01:38 clandmeter: kind of 2018-05-21 11:01:43 I kind of do the same 2018-05-21 11:02:25 azarus: without patching source it couldn't be fixed, at least it looks so for me 2018-05-21 11:02:38 (messed up the last Alpine installation, took so long to restore...) 2018-05-21 11:02:46 I will push now and ping you 2018-05-21 11:03:07 mps: it doesn't make sense for me. why is this behaviour seen? 3p is the *last* section, and yet it comes in front?! 2018-05-21 11:03:12 so illogical. 2018-05-21 11:04:21 just because it is last, and there is printf in 1 section 2018-05-21 11:04:42 but man should find 3p if we tell to do it 2018-05-21 11:05:16 yeah, man! 2018-05-21 11:05:17 :P 2018-05-21 11:05:17 if i tell to show 3p printf it must do that 2018-05-21 11:05:46 to me, that is bug 2018-05-21 11:07:23 but, i prefer to leave this to someone more experienced with man pages handling 2018-05-21 11:07:42 Agreed. 2018-05-21 11:07:51 clandmeter: http://tpaste.us/9KaK ? 2018-05-21 11:08:35 if I find some time tomorrow I will look at Arch Linux package to see if there is a solution 2018-05-21 11:08:59 tmh1999: why not depend on ssh? 2018-05-21 11:09:19 clandmeter: because ssh is not yet installed 2018-05-21 11:09:20 because I would like to have 'man 3avr printf' on AL 2018-05-21 11:09:49 why not add openssh to pkgs in initramfs? 2018-05-21 11:10:02 clandmeter: I thought you wanted to make it simpler :P 2018-05-21 11:10:08 mps: arch uses man-db 2018-05-21 11:10:08 make init simpler 2018-05-21 11:10:32 well, we should use the interfaces it provides 2018-05-21 11:10:38 ah, so. meh 2018-05-21 11:12:09 clandmeter: well then I'll do it. I just thought double adding and checking ssh_* in init and first-boot is just ... 2018-05-21 11:12:28 maybe, we can ask ncopa his pref 2018-05-21 11:12:36 add it as y ou like to the pr 2018-05-21 11:12:44 okay 2018-05-21 11:13:00 i think mine was more simple :p 2018-05-21 11:13:09 now you need to add more logic to the initd 2018-05-21 11:13:30 clandmeter: I want this merged asap so I'll follow the boss :P 2018-05-21 11:14:10 im not sure i like rc-x functions in an initd file. 2018-05-21 11:14:14 clandmeter: nope. I removed everything ssh_* in initd, add your wget in my commit. that's it. 2018-05-21 11:14:17 it should fragile. 2018-05-21 11:14:21 err sounds. 2018-05-21 11:14:50 oh initd 2018-05-21 11:15:08 hum right 2018-05-21 11:16:43 we have the pkgs option just for that. 2018-05-21 11:17:12 tmh1999: did you do something with the alpine_repo part? 2018-05-21 11:17:35 clandmeter: nope. it works in the boot arg. thankfully. 2018-05-21 11:17:44 i think i have something :) 2018-05-21 11:17:51 not sure its 100% though 2018-05-21 11:17:58 i can make a pr for it 2018-05-21 11:18:12 ping me here please :D 2018-05-21 11:20:05 be careful you're messing tab + space together 2018-05-21 11:20:41 init_KOPT uses space 2018-05-21 11:26:31 clandmeter: you still need to rc-service restart sshd anyway in first-boot 2018-05-21 11:27:37 for the config change? 2018-05-21 11:27:42 yes 2018-05-21 11:27:47 h mm 2018-05-21 11:27:51 :D 2018-05-21 11:27:56 remove t he pw option :p 2018-05-21 11:28:02 :)))) 2018-05-21 11:28:08 I can't :))) 2018-05-21 11:28:25 its 2018 we use keys now ;-) 2018-05-21 11:28:47 make it restart only on ssh_pass 2018-05-21 11:29:08 okay 2018-05-21 11:29:13 lol 2018-05-21 11:30:37 the stop() is ugly I know. you want me to do it there or in setup-disk. 2018-05-21 11:31:16 what do you have now? 2018-05-21 11:32:15 sed -i '/PermitRootLogin yes/d' "$mnt"/etc/ssh/sshd_config lol 2018-05-21 11:32:21 sed -i '/PermitRootLogin yes/d' /etc/ssh/sshd_config 2018-05-21 11:35:27 tmh1999: i was thinking of something like this for repo http://tpaste.us/nqlM 2018-05-21 11:37:31 tmh1999: can we do something to make sshd allow password login without config mod? 2018-05-21 11:37:31 that's nice 2018-05-21 11:37:48 how ? 2018-05-21 11:37:57 apkovl ? 2018-05-21 11:37:57 maybe adjust the initd of sshd? dunno 2018-05-21 11:38:11 aw you want to touch that ? 2018-05-21 11:38:28 I don't think that's a good idea 2018-05-21 11:38:52 ok i need to hit the shower. 2018-05-21 11:39:11 ill submit that patch later. 2018-05-21 11:39:24 Yeah I will ping you here when I submit :P 2018-05-21 11:41:13 tmh1999: you could also start sshd yourself with the correct options. it would allow password if you tell it to. 2018-05-21 11:46:57 maybe copy /etc/ssh/sshd_config to /tmp, adding the line allowing password, then # SSHD_CONFIG=/tmp/new_config /etc/init.d/sshd restart 2018-05-21 11:47:12 seems right 2018-05-21 11:56:32 what about SSHD_OPTS='-o PermitRootLogin=yes' ? to avoid mucking with temp files 2018-05-21 11:57:05 is it possible ? Nice let me try tstearns 2018-05-21 12:10:03 tstearns: Thank you ! I should've read /etc/init.d/sshd ... 2018-05-21 12:10:12 it's much cleaner now 2018-05-21 12:10:21 :) 2018-05-21 12:11:36 well actually I read it since I saw SSHD_CONFIG. But never thought/cared about SSHD_OPTS. bummer ... 2018-05-21 12:28:26 azarus: bug about man in mdocml is directory structure 2018-05-21 12:28:43 I created /usr/share/man/man3p dir 2018-05-21 12:28:58 mps: oh? does it work like that? 2018-05-21 12:29:05 and put printf.3p there 2018-05-21 12:29:26 we could fix that in the APKBUILD to man-pages 2018-05-21 12:29:41 then 'man 3p printf' gives 'PRINTF(3P) POSIX Programmer's Manual PRINTF(3P)' 2018-05-21 12:30:20 that would be fix, but I'm not sure if it right solution 2018-05-21 12:30:36 let's ask ncopa? 2018-05-21 12:30:54 (also, does that also work with man-db?) 2018-05-21 12:31:42 man-db doesn't have 'man' command 2018-05-21 12:32:23 ... can't be right 2018-05-21 12:33:00 mps: https://pkgs.alpinelinux.org/contents?branch=edge&name=man-db&arch=x86_64&repo=testing 2018-05-21 12:33:03 yes it does 2018-05-21 12:33:32 I'm not versed in mdocml so I don't know is the right solution to have different dirs for every section under /usr/share/man 2018-05-21 12:33:50 man3p, man3ssl, man3avr, and so on 2018-05-21 12:34:05 it would make sense for me, but I'm not experienced either 2018-05-21 12:34:46 also I don't have any strong opinion about that 2018-05-21 12:35:14 as long as it works... :) 2018-05-21 12:35:54 we should ask someone with a better understanding how man (generic) should work 2018-05-21 12:38:45 strange, I installed man-db and 'apk info -L man-db' doesn't show /usr/bin/man 2018-05-21 12:40:45 mps: have you deleted mdocml first? 2018-05-21 12:41:37 no 2018-05-21 12:41:43 there you have it 2018-05-21 12:41:58 I just thougt about it 2018-05-21 12:42:34 tstearns: do you know how could jump out of opence cyclic dependencies ? service A need sshd. service A wants to restart sshd and it require 60second waiting... 2018-05-21 12:43:11 I tried : rc_parallel="NO" SSHD_OPTS="-O PermitRootLogin=yes" rc-service sshd restart but didnt work 2018-05-21 12:43:55 azarus: now it works without problem with other problem 'man 3p sprintf' show posix version and 'man 3 sprintf' linux 2018-05-21 12:44:37 azarus: little confusing msg 2018-05-21 12:44:50 mps: so both mdocml and man-db work with that directory structure? 2018-05-21 12:45:03 it works, so removing mdocml is 'solution' 2018-05-21 12:45:30 no, man-db works with structure as it is 2018-05-21 12:45:34 tmh1999: afraid you're well beyond my level of knowledge at this point :/ 2018-05-21 12:45:45 :D 2018-05-21 12:45:52 mps: yes, but does man-db also work with man3p/ ? 2018-05-21 12:46:18 for mdocml man only by creating dirs with section names e.g. man3p 2018-05-21 12:46:38 maybe 'use' is better than 'need' 2018-05-21 12:46:47 yes, 'man 3p sprintf' as I just wrote above 2018-05-21 12:47:00 mps: I understood. But does man-db also work with your proposed directory structure? 2018-05-21 12:47:19 didn't tried 2018-05-21 12:47:40 and I didn't proposed it, just found quick solution 2018-05-21 12:47:53 hackish, I have to say 2018-05-21 12:48:19 and I don't know what is right solution for mdocml 2018-05-21 12:48:35 it is just quick hack, nothing more 2018-05-21 12:48:55 tstearns: yes. fyi in depend() instead of 'need sshd', use 'use sshd' instead. 2018-05-21 12:48:57 :D 2018-05-21 12:49:09 :P 2018-05-21 12:49:33 if the AL want to have mdocml as standard 'man' then the 'my propose' could be fix 2018-05-21 12:50:10 yes, mandoc (mdocml) is the standard man page formatter for alpine linux. 2018-05-21 12:50:14 or, patch mdocml to follow man-db 2018-05-21 12:50:16 man-db is in testing/ 2018-05-21 12:50:19 and not in main/ 2018-05-21 12:50:25 I see 2018-05-21 12:51:45 anyway, AL is Linux and I can't see why the BSD man system is default 2018-05-21 12:52:30 I don't want to say anything against BSD, of course 2018-05-21 12:58:56 because mandoc is simpler and fits a bit better to the AL philosophy perhaps 2018-05-21 12:59:16 clandmeter: that PR works now with : https://github.com/alpinelinux/aports/pull/4340. Please have a look when you're back. I'm taking a nap, haven't sleept since last night... brb in 3-4 hours. 2018-05-21 14:20:54 tmh1999, i dont think you can pass env to openrc initd scripts. 2018-05-21 14:39:18 does anyone has a clue why perl-date-manip fails on 32bit? 2018-05-21 14:39:26 the tests 2018-05-21 16:20:50 clandmeter: It works. I tested. If you prefer setting in openssh init, I'm submitting another pr for it. 2018-05-21 16:21:47 strange, i think i tried it local and i couldnt get the var. 2018-05-21 16:36:21 tmh1999, i tried it again but doesnt seem to work for me. 2018-05-21 16:36:42 don't worry I'm testing in openssh initd 2018-05-21 16:54:08 urg 2018-05-21 16:56:28 right it needs start_pre ... 2018-05-21 16:56:35 1 sec 2018-05-21 17:01:48 clandmeter: just updated again : https://github.com/alpinelinux/aports/pull/4342 2018-05-21 17:01:59 and 4340 2018-05-21 17:10:28 start_permit_root don't play nice with stop/restart/start 2018-05-21 17:25:01 clandmeter: have you tested start_permit_root to be working ? I can't stop sshd when it's started by start_permit_root 2018-05-21 17:29:37 i did now :I 2018-05-21 17:31:31 openrc doesnt see it as started 2018-05-21 17:31:40 would you mind pasting your (updated?) change? I had to either add start_pre or checkconfig 2018-05-21 17:31:53 yeah, that's why it can't be stopped 2018-05-21 17:32:16 and when it do restart/start, it checked the pid file, and that exists, then can't start/restart 2018-05-21 17:33:24 i guess the only way is to start it manually 2018-05-21 17:33:51 so no start_permit_root ? lol 2018-05-21 17:34:24 I prefert to stick with SSHD_OPTS 2018-05-21 17:35:45 are you sure that works? 2018-05-21 17:37:01 it does. well for double sure let me test again 2018-05-21 17:39:33 i i create my own test service and try to pass a variable i cannot access it. 2018-05-21 17:39:52 there are some references on the net which states this behaviour 2018-05-21 17:48:09 clandmeter: it works 2018-05-21 17:50:50 you run SSHD_OPTS="-o PermitRootLogin=yes" rc-service sshd start? 2018-05-21 17:50:58 yes sir 2018-05-21 17:51:31 adding --quiet to be exact 2018-05-21 17:51:54 if i run that i dont see the -o in ps 2018-05-21 17:52:15 i got to run. 2018-05-21 17:52:41 okay thanks. I will update in the pr comment. 2018-05-21 17:53:33 clandmeter: 910 root 0:00 /usr/sbin/sshd -o PermitRootLogin=yes 2018-05-21 19:57:52 ageis: you use Yubikey on Alpine? could you please test https://pkgs.alpinelinux.org/package/edge/testing/x86_64/yubico-piv-tool, https://pkgs.alpinelinux.org/package/edge/community/x86_64/ykpers, https://pkgs.alpinelinux.org/package/edge/testing/x86_64/libu2f-server, https://pkgs.alpinelinux.org/package/edge/testing/x86_64/libu2f-host ? 2018-05-22 03:36:13 clandmeter: I'll be back in a couple of hours in the morning at your tz. The openrc and mkinitfs are working for me now. SSHD_OPTS works : http://tpaste.us/056z. If you have some time to look, I'd appreciate it :D 2018-05-22 03:39:07 tmh1999, are you sure that's not an older process? Seems the same pid as last time. 2018-05-22 03:39:42 clandmeter: I just boot a fresh instance 2018-05-22 03:40:04 911 and 910 2018-05-22 03:40:08 different processes :P 2018-05-22 03:40:20 Ok 2018-05-22 03:41:33 o/ 2018-05-22 03:41:40 What about when those are removed from initd? 2018-05-22 03:42:20 remove in the same place where modloop.initd is removed in setup-disk.in 2018-05-22 03:43:40 I mean deprecated vars 2018-05-22 03:44:38 I don't have a plan for it yet. Still thinking. 2018-05-22 03:51:29 There are many more broken packages I need to fix, I see this SSHD_OPTS thing is not *that* critical as it's not removed yet. So let's spend time wisely 2018-05-22 03:53:32 reading man .. 2018-05-22 04:06:49 tmh1999: it doesnt start sshd when using keys 2018-05-22 04:09:32 clandmeter: I know why. ssh_key option requires "need sshd", while ssh_pass only need "use sshd" 2018-05-22 04:09:43 due to cyclic deps 2018-05-22 04:09:53 repairing 2018-05-22 04:12:26 ok i looks like permitrootlogin does work when i try it in qemu 2018-05-22 04:12:51 :D :D :D 2018-05-22 04:13:07 its probably sudo that gets in the way when i try it. 2018-05-22 04:15:37 clandmeter: just pushed the fix for using keys. 2018-05-22 04:16:15 i wonder if what jirutka did with the confd vars is correct. 2018-05-22 04:22:57 I'll (annoyingly) ping you in a couple of hours. need some sleep. 2018-05-22 04:23:02 :D 2018-05-22 04:23:04 morning 2018-05-22 04:23:49 ok ill hit the show :) 2018-05-22 04:23:55 shower 2018-05-22 08:47:21 if it's possible to convert a debian package to alpine pkg? 2018-05-22 08:50:52 in theory, it's just files in a folder structure 2018-05-22 08:51:06 in practice, you'd have little use for such a converted package 2018-05-22 09:00:18 TBB: how about compile them on alpine, but still use debian source? I'm not sure how to fill alpine APKBUILD source. 2018-05-22 09:41:31 Hi im trying to build the alpine-build package from source, during the process it complains about baselayout trying to overwrite some files, what is the correct way to build this package? 2018-05-22 10:09:10 clandmeter: what I did with confd vars? 2018-05-22 10:09:29 jirutka, yes for sshd 2018-05-22 10:09:41 clandmeter: ?? 2018-05-22 10:09:55 you removed all of the SSHD_X 2018-05-22 10:10:01 whats the reason for that? 2018-05-22 10:10:24 you also used command_arg in confd. 2018-05-22 10:10:51 what *all* SSHD_X? just SSHD_OPT 2018-05-22 10:11:09 command_args is standard variable defined by OpenRC that should by used for passing options to the program 2018-05-22 10:11:40 from initd yes, i dont think for confd. 2018-05-22 10:11:57 init script sources confd file 2018-05-22 10:12:00 i would like to know where you read this? 2018-05-22 10:12:26 all examples of openrc show service named variables in confd 2018-05-22 10:13:21 it’s about unification, to use the same variable for one thing in all services instead of inventing unnecessary custom variables 2018-05-22 10:16:49 I dont see it in any of their examples. i will ask openrc what the policy is regarding those variable names. 2018-05-22 10:17:00 I don’t see it either, just looked for it 2018-05-22 10:18:27 however, there’s no reason why this cannot be used and I don’t know about any reason for adding custom vars duplicating standard vars (I read OpenRC source code) 2018-05-22 10:19:10 if i get a reply i will let you know. 2018-05-22 10:19:29 thanks! 2018-05-22 10:19:53 I’m curious what may be the reason for adding custom vars instead of using standard ones 2018-05-22 10:20:20 IMO it’s just yet another legacy from SysV init scripts 2018-05-22 10:22:02 yangxuan8282[m]: APKBUILD is quite easy, at least the basics. I'm no expert with Debian packaging, but Debian sources should be usable 2018-05-22 10:22:55 clandmeter: you can always set e.g. command_user or any other standard variable in confd script, don’t need any special support in the initd script 2018-05-22 10:23:51 clandmeter: however, you cannot override variables defined in initd from confd, that’s why it’s reasonable to append command_args 2018-05-22 10:28:57 clandmeter: btw this not new, we already do this in many other packages for years 2018-05-22 10:30:47 jirutka, if you look at the firstrun initd pr. this is one of my concerns. 2018-05-22 10:31:23 clandmeter: my concern is that what firstrun initd do is a hack 2018-05-22 10:31:46 if you have a better suggestion please do. 2018-05-22 10:32:05 clandmeter: ask OpenRC team about this, I think that they will not approve it 2018-05-22 10:32:51 yes i also dont like it, but im not sure what a better alternative is. 2018-05-22 10:33:30 we should avoid such hacks if we’d like to move to another init/rc system someday… that’s why I’m gradually updating init scripts to avoid letting programs daemonize itself etc. 2018-05-22 10:34:31 as I said few hours ago, I will think about it; unfortunately I don’t know how to hack my mind to think about useful things in dreams instead of non-sense dreaming :) 2018-05-22 10:35:17 ha, that reminds me that today I had a nightmare about someone pushed broken abuild into aports XD 2018-05-22 10:36:10 omg 2018-05-22 10:36:13 thats serious 2018-05-22 10:36:24 you should go see a linux doctor. 2018-05-22 10:36:39 XD 2018-05-22 10:37:02 as I said, I usually have non-sense dreams :/ 2018-05-22 10:52:02 clandmeter: in shower i found two reasons why the approach used in the firstart init script is broken… I’ll write more after lunch 2018-05-22 10:53:01 on the floor together with the soap? 2018-05-22 10:53:14 XD 2018-05-22 10:53:33 ok please share :) 2018-05-22 10:53:38 the issues i mean 2018-05-22 10:53:43 going to lunch now… 2018-05-22 11:21:20 packaging question for the apk gurus: packages come with default configs if needed. now if I were to provide an extra package that needs to overwrite those configs, this won't work because of file ownership belonging to the default package. what's the correct way of transferring those config files, and those config files only, to the new package? 2018-05-22 11:25:48 <_ikke_> I don't think that's possible 2018-05-22 11:26:22 we use an ugly replaces="" hack for that, but it's just not right 2018-05-22 11:27:01 <_ikke_> It's not possible to have a conf.d like directory where you can add new configuration files? 2018-05-22 11:37:12 possibly, but not everything is in there 2018-05-22 11:37:21 but I've got a bit of an update regarding this 2018-05-22 11:37:56 if I use replaces, only those files that actually get replaced transfer over to the ownership of the new package 2018-05-22 11:38:53 which makes perfect sense, it's just not exactly how one would think about it when one notices the directive for it is called replaces :) 2018-05-22 12:53:45 jirutka: do you have any recommendation to pass arguments to sshd init scripts instead of SSHD_* ? 2018-05-22 13:09:15 clandmeter: this just work: command_args="-o PermitRootLogin=yes" rc-service sshd start --quiet. No idea why it failed yesterday. I'm updating the commit 2018-05-22 13:09:38 ofc it should work 2018-05-22 13:09:45 had to set pass rc_env_allow="command_args" command_args="-o PermitRootLogin=yes" rc-service sshd start --quiet first 2018-05-22 13:09:50 its the same as the other setting 2018-05-22 13:09:55 but withyou rc_env_allow it stills works 2018-05-22 13:09:56 irght 2018-05-22 13:10:00 so it's solved right ? 2018-05-22 13:10:03 this whole vars thing 2018-05-22 13:10:53 uhm 2018-05-22 13:11:01 you modified that setting? 2018-05-22 13:11:03 rc_env_allow 2018-05-22 13:11:45 i like to hear jirutka input. 2018-05-22 13:12:08 he has amazing ideas in the shower 2018-05-22 13:12:25 no need rc_env_allow any more 2018-05-22 13:12:37 i didnt hear you mention it before. 2018-05-22 13:12:45 oh bathroom, sacred place 2018-05-22 13:12:53 I just tried now 2018-05-22 13:12:56 try 2018-05-22 13:13:21 i didnt modify that setting at all and it works. 2018-05-22 13:13:45 yeah might be PEBKAC 2018-05-22 13:13:55 i didnt know about that setting. 2018-05-22 13:14:07 is it in the pr somewhere 2018-05-22 13:14:09 ? 2018-05-22 13:14:31 I just pushed, would you mind merging if no other problem? https://github.com/alpinelinux/aports/pull/4340 2018-05-22 13:14:45 forget rc_env_allow and SSHD_* 2018-05-22 13:15:47 rc_env_allow is in /etc/rc.conf 2018-05-22 13:15:53 yes i found it. 2018-05-22 13:15:55 *to answer your question 2018-05-22 13:16:00 but i didnt year you mention it before. 2018-05-22 13:16:05 hear... 2018-05-22 13:16:29 because I just find out 1 min ago to try command_args, yesterday I couldn't make command_args works, that's why SSHD_OPTS 2018-05-22 13:16:37 now command_args works 2018-05-22 13:16:41 ah ok 2018-05-22 13:16:56 :D 2018-05-22 13:17:25 I think if jirutka has no good alternative we can try this. 2018-05-22 13:18:57 agreed 2018-05-22 13:24:32 ncopa: wow look at the last commit https://git.alpinelinux.org/cgit/mkinitfs, I'm the committer ? 2018-05-22 13:54:36 clandmeter: we're good to go ? 2018-05-22 13:55:48 did jirutka already check it? 2018-05-22 13:56:35 I thought we go with command_args as what he wanted already 2018-05-22 13:57:01 jirutka just opposed SSHD_* stuffs 2018-05-22 13:57:07 tbh i dont really have much against this as it doesnt affect anything. 2018-05-22 13:57:17 i think jirutka has something againt the approach 2018-05-22 13:57:31 but he didnt really mention yet. 2018-05-22 13:58:21 tmh1999: can you refer the other commit with this one? 2018-05-22 13:58:26 clandmeter: well I have not heard him saying anything about this, if he wants he should've . 2018-05-22 13:58:27 sure 2018-05-22 13:59:31 err i mean other PR, 2018-05-22 13:59:52 yes nice 2018-05-22 14:02:02 also mentioned in git commit 2018-05-22 14:04:13 ok i first go home and look at it. 2018-05-22 14:04:32 ttyl. 2018-05-22 14:07:34 clandmeter: sure thanks. I also have to run some errands be back in 2-3 hours 2018-05-22 14:07:38 1-2 2018-05-23 02:42:19 What's the difference between Alpine kernel and other distros (like archlinux) kernel? 2018-05-23 02:59:51 https://github.com/alpinelinux/abuild/pull/39 this is pretty important 2018-05-23 04:17:38 jirutka: Hi, this PR https://github.com/alpinelinux/aports/pull/4340 now uses 'command_args' as you advised. Would you mind if clandmeter merge it ? Thanks 2018-05-23 09:46:43 yangxuan8282[m]: older alpine had unofficial grsecurity port. recent alpine (current edge and the upcoming v3.8) does not have any big difference 2018-05-23 10:07:52 ncopa (IRC): so we should able to use other distros kernel config to compile kernel for alpine? For example, can we use raspberry pi downstream config file to make new kernel for rpi alpine? 2018-05-23 10:08:50 just drop it in as the config file in linux-vanilla/ and run `abuild checksum`, it should work (but you may need to run `make oldconfig` first if any options have changed between versions) 2018-05-23 11:26:52 clandmeter: let's merge so I can leave you in peace 2018-05-23 12:52:17 looks like ncurses' mirror is down 2018-05-23 12:52:40 the package won't build from the aports tree due to this 2018-05-23 12:56:37 or rather... maybe it's up now 2018-05-23 13:03:16 Nope 2018-05-23 13:03:31 the package has been removed from there, because it's no longer current. or something. 2018-05-23 13:04:40 the bad string is http://invisible-mirror.net/archives/ncurses/current/ncurses-6.0-20180121.tgz 2018-05-23 13:04:51 but http://invisible-mirror.net/archives/ncurses/current/ doesn't have the package there any more. 2018-05-23 13:05:29 there's now ncurses 6.1-20180408 2018-05-23 13:06:30 in any case, past releases are stored in http://invisible-mirror.net/archives/ncurses/ and it seems unlikely they'd be removed unlike the releases in http://invisible-mirror.net/archives/ncurses/current/ 2018-05-23 13:08:47 they;re then moved to http://invisible-mirror.net/archives/ncurses/6.0/ and so on 2018-05-23 13:09:02 (at least once they are removed from current) 2018-05-23 13:09:24 I feel like changing 'current' to '6.0' is a quick fix, but that switching to 6.1 would be better. 2018-05-23 13:11:03 Ah, no, it isn't, since these are patches for the original base... 2018-05-23 13:22:31 ncopa: since the current mkinitfs PR is on hold, I'm leaving it out and only backport the previous commit to aports/mkinitfs : https://github.com/alpinelinux/aports/pull/4062. I think it's no-brainer. Please help me to merge when you have a sec. 2018-05-23 14:26:46 duncan^: that mirror is very very flakey traditionally 2018-05-24 06:14:19 hi 2018-05-24 06:16:10 ive got some problems with docker image of alpine linux. It seeems slower than other images for instance when i use there PHP symfony framework. Is apline linux made for these kind of projects or should i use other distros ? 2018-05-24 06:17:48 is alpine linux intended for speed or just for security and tiny things? 2018-05-24 06:45:31 anyone that can explain why alpine linux distro in docker image is slower than others or Alpine linux is not intended to be made for large projects and speeds? 2018-05-24 06:45:41 Symfoner, ideally it shouldnt matter. 2018-05-24 06:45:50 how did you test? 2018-05-24 06:59:53 Symfoner: exactly what operations are slower and what are the bottlenecks? Exactly how much slower is your app when you run on Alpine? 2018-05-24 07:02:53 duncan^: I have built chromium 66 on alpine but it fail with "Aw, snap!". Did you test that it runs on void linux musl? 2018-05-24 08:38:26 ncopa: examine dmesg? chrome might have its threads terminated by the kernel 2018-05-24 08:38:47 (asking because i've had the same experience but with firefox) 2018-05-24 08:48:24 from 50% to 100% 2018-05-24 08:49:24 ncopa: based on operational system but it is slower for 1.5x - 2x 2018-05-24 08:49:41 worst speed is for windows docker 2018-05-24 08:50:04 in the middle is osX and then Linux 2018-05-24 09:03:14 Symfoner: if i understand you correctly, symfony docker image based on alpine on windows runs 2x slower than symfony docker image based on debian on windows? 2018-05-24 09:05:34 there may be various reasons why it happens but without any analyze i can only guess 2018-05-24 09:05:45 you'll need to analyze where time is spent 2018-05-24 09:06:40 you are also not saying anything about what kind of load it is. is it much IO? is it cpu intensive? network related? 2018-05-24 09:06:49 you need to identify what the bottleneck is 2018-05-24 09:07:33 hi ncopa, would you mind a quick PM? 2018-05-24 09:07:34 ncopa: ok i will check it 2018-05-24 09:07:46 awilfox: sure 2018-05-24 11:11:47 ncopa: I think you meant to ping duncaen :D 2018-05-24 11:13:10 oh i wasnt aware of the diff 2018-05-24 11:21:49 :D 2018-05-24 11:22:05 ncopa: 66 runs fine for me, even with the small default stack 2018-05-24 11:28:27 did you build it with clang too? 2018-05-24 11:29:02 yes 2018-05-24 11:32:35 [262291.417149] do_trap: 6 callbacks suppressed 2018-05-24 11:32:35 [262291.417152] traps: chrome[5300] trap invalid opcode ip:55c081668e8d sp:7ffdb0e4c0e8 error:0 in chrome[55c07d69c000+781d000] 2018-05-24 11:32:35 [262291.417182] audit: kauditd hold queue overflow 2018-05-24 11:32:35 [262291.417179] audit: type=1701 audit(1527161508.769:108): auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=5300 comm="chrome" exe="/usr/lib/chromium/chrome" sig=4 res=1 2018-05-24 11:32:35 [262291.417181] audit: audit_lost=251 audit_rate_limit=0 audit_backlog_limit=64 2018-05-24 11:33:28 it is version 66.0.3359.181 2018-05-24 11:35:18 hm I did not try .181 yet 2018-05-24 11:35:54 Im going to update and start a build, I can test it in a few hours 2018-05-24 11:36:46 this is on stderr: http://tpaste.us/DeQd 2018-05-24 11:37:39 i needed this in addition to patches from void: http://tpaste.us/B65b 2018-05-24 11:39:58 ncopa: hi this is just simply backport from mkinitfs to aports ? would you mind https://github.com/alpinelinux/aports/pull/4062 ? it 2018-05-24 11:40:06 it would be very quick 2018-05-24 11:41:21 they have all been upstreamed to mkinitfs git repo right? 2018-05-24 11:41:27 ncopa: yes 2018-05-24 11:44:33 done 2018-05-24 11:45:00 i tested it in qemu first 2018-05-24 11:45:24 great! I will bring up the builder today and ping you later for moving data. 2018-05-24 11:45:27 thanks 2018-05-24 19:42:15 Does anyone know if alpine has a privacy policy for the os itself? And where to find it? 2018-05-24 19:45:50 jirutka: Do we have such a privacy policy? 2018-05-24 19:47:06 agowa338: unfortunately I don’t know about such thing /cc kaniini ncopa 2018-05-24 20:06:02 agowa338: why would a distro need a privacy policy? 2018-05-24 20:06:40 does alpine collect any personal data? does alpine process any personal data? i would not expect so. 2018-05-24 20:07:22 <_ikke_> zNVxxliww5gP: I guess the idea is that alpine states that in the privacy policy 2018-05-24 20:07:28 zNVxxliww5gP: I'm publishing alpine for wsl to the windows store. And Microsoft responded with missing privacy policy, because User Credentials are processed... 2018-05-24 20:08:23 <_ikke_> 'processed' 2018-05-24 20:08:23 user credentials? what do you mean? 2018-05-24 20:08:38 liek /etc/passwd and /etc/shadow? 2018-05-24 20:08:54 Alpine is a distribution 2018-05-24 20:08:56 not a company 2018-05-24 20:09:06 (in the context of the gdpr) the data processor would be the one operating the installed instance 2018-05-24 20:09:09 Here is the relevant part from the response: https://pastebin.com/raw/wTPzRW2G 2018-05-24 20:10:15 I think I've to get into contact with them about that, as like skarnet said, it's the user that processes that information and not us... 2018-05-24 20:10:16 this makes no sense 2018-05-24 20:10:20 yeah 2018-05-24 20:10:55 i mean the response makes no sense in the pastebin. 2018-05-24 20:11:56 actually, we do process personal data – according to GDPR, even IP address is a personal data 2018-05-24 20:12:16 and we do have logs on web page, mirror servers etc. 2018-05-24 20:12:40 <_ikke_> RIght, but that has nothing to do with the distribution itself, does it? 2018-05-24 20:13:11 I dunno… there’s preconfigured mirror for downloading packages 2018-05-24 20:13:32 are logs PII? 2018-05-24 20:13:38 ip addresses are 2018-05-24 20:13:40 sadly 2018-05-24 20:13:40 jirutka: Than this page https://alpinelinux.org/privacy-policy.html should be updated, until tomorrow??? 2018-05-24 20:13:43 <_ikke_> ip adresses can be 2018-05-24 20:13:47 hm 2018-05-24 20:14:02 <_ikke_> https://www.whitecase.com/publications/alert/court-confirms-ip-addresses-are-personal-data-some-cases 2018-05-24 20:14:02 yes, privacy-policy must be updated 2018-05-24 20:14:47 <_ikke_> I've heard that you are allowed to store IPs in logs for a limited amount of time to prevent abuse 2018-05-24 20:14:51 <_ikke_> but that's all rumors 2018-05-24 20:14:54 yes 2018-05-24 20:15:07 actually GDPR protects everything that could identify someone, so a dynamic ip is not, but a static one or a long lasting one could be... 2018-05-24 20:15:39 <_ikke_> agowa338: dynamic ip + timestamp could identify someone 2018-05-24 20:15:41 but also if you combine a dynamic ip with some other information it could be 2018-05-24 20:16:18 agowa338: when you're unsure it's better to treat things as no 2018-05-24 20:16:26 <_ikke_> https://law.stackexchange.com/questions/28603/gdpr-and-ip-address-logging 2018-05-24 20:16:36 I can ask one guy from CESNET (academic network) who is dealing with GDPR here 2018-05-24 20:16:59 or maybe someone from SUSE, we host openSUSE conference starting tomorrow 2018-05-24 20:17:23 <_ikke_> Though, I think you do need to disclose *that* you are logging ip addresses 2018-05-24 20:17:31 jirutka: Couldn't hurt, I guess? 2018-05-24 20:18:24 please remind me it tomorrow 2018-05-24 20:19:36 I think that _ikke_ is right, we can log IP addresses, ew don’t need any approval from users, but we have to disclose that we are doing it 2018-05-24 20:20:30 and explicitly state that we do not sell or anything the logs and we remove them after x months according to y policy 2018-05-24 20:20:39 correct 2018-05-24 20:20:43 s/remove/delete/ 2018-05-24 20:21:03 Do you get any additional data from sources like google search console? 2018-05-24 20:21:12 that needs to be included too 2018-05-24 20:21:30 no, we don’t use any Google services 2018-05-24 20:21:36 no tracking bullshits etc. 2018-05-24 20:21:50 some of us are very sensitive to this :) 2018-05-24 20:22:18 jirutka: Google Search Console is not analytics. It is the service that tells you what happened before the user got to your page. But it was mainly an example. 2018-05-24 20:22:31 aha 2018-05-24 20:22:38 agowa338: do not mix up what the installed distro does with what the infrastructure does for distributing the distro. 2018-05-24 20:22:42 <_ikke_> agowa338: But isn't it google responsibility then? 2018-05-24 20:22:50 hm, then I dunno, but I doubt that clandmeter use this 2018-05-24 20:23:50 <_ikke_> agowa338: ie, if users want this data to be removed, they should go to google, not Alpine 2018-05-24 20:23:51 hm, we use Fastly for CDN (above the mirrors), not sure if it changes something 2018-05-24 20:24:15 <_ikke_> and other mirrors as well, right? 2018-05-24 20:24:35 <_ikke_> they are I guess data processors 2018-05-24 20:24:42 _ikke_: google has to state that they share that information. You have to state that you get additional information from them. But anyway I'm not an expert at GDPR. Just wrote a privacy policy for my personal blog. Better we ask someone who has better insight. 2018-05-24 20:25:05 <_ikke_> agowa338: only if you actually use the service 2018-05-24 20:25:12 ACTION worked with the european parliament on the gdpr... 2018-05-24 20:25:31 wow, so we have expert here! 2018-05-24 20:25:46 yes, but i'm reluctant to disclose this private info ;) 2018-05-24 20:25:52 XD 2018-05-24 20:26:11 zNVxxliww5gP: could I ask you to write privacy policy for us? :) 2018-05-24 20:27:46 well the most important question is that if alpine infrastructure delegates services to 3rd parties like the cdn, then the ones doing the delegation are clients of those services and need to know their privacy policy, and this needs to be disclosed to alpine infrastructure users 2018-05-24 20:28:28 as long as alpine infrastructure does only collect httpd logs and those are deleted regularly, and no other data is collected there's not much to do 2018-05-24 20:29:24 i can help writing this policy, but i need help figuring out what is collected, how is it processed, and what is delegated to 3rd parties. 2018-05-24 20:29:52 but alpine is not really in the business of profiting from personal data, so there's really not much to do 2018-05-24 20:30:19 just resisting the currenty hysteria, misunderstandings and tl;dring of the gdpr itself 2018-05-24 20:31:07 clandmeter: _ikke_: could you please provide the needed information to zNVxxliww5gP? 2018-05-24 20:31:54 btw if anyone is interested, it is quite long, but the relevant parts are only chapters 2-5, quite manageable, the rest can mostly be ignored: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679 2018-05-24 20:32:34 I guess that we don’t have to worry about bugs.a.o and other services with registration now, because these are not necessary for using Alpine and users have to explicitly register here… (however, we probably need specific Privacy policy for these too) 2018-05-24 20:33:09 yes, and the people can also remove their registration, and edit their profiles. 2018-05-24 20:33:41 <_ikke_> what if they want all their comments / issues to be removed? 2018-05-24 20:34:06 _ikke_: then we’re fucked up :) 2018-05-24 20:34:06 there's a reasonability barrier 2018-05-24 20:35:49 article 17 is the relevant here 2018-05-24 20:40:29 exception to deletion is in article 17 paragraph 3: 3. Paragraphs 1 and 2 shall not apply to the extent that processing is necessary: (a) for exercising the right of freedom of expression and information; 2018-05-24 20:40:59 Hi zNVxxliww5gP 2018-05-24 20:41:16 there's possibly other arguments, like: 2. Where the controller has made the personal data public and is obliged pursuant to paragraph 1 to erase the personal data, the controller, taking account of available technology and the cost of implementation, shall take reasonable steps, including technical measures, to inform controllers which are processing the personal data that the data subject has 2018-05-24 20:41:19 requested the erasure by such controllers of any links to, or copy or replication of, those personal data. 2018-05-24 20:41:32 hi clandmeter ;) 2018-05-24 20:41:33 You are who I think you are? 2018-05-24 20:41:39 affirmative ;) 2018-05-24 20:41:45 :p 2018-05-24 20:42:15 We don't collect data 2018-05-24 20:43:19 then the privacy policy should say so, we do not collect data. all hail the dataminimization principle (article 5, paragraph c) 2018-05-24 20:43:31 At least this is my goal 2018-05-24 20:43:41 <3 2018-05-24 20:44:21 Didn't we have this written down? 2018-05-24 20:44:38 <_ikke_> yes 2018-05-24 20:44:48 <_ikke_> https://alpinelinux.org/privacy-policy.html 2018-05-24 20:44:49 then there's nothing to do. 2018-05-24 20:45:03 https://alpinelinux.org/privacy-policy.html 2018-05-24 20:45:08 perfect! 2018-05-24 20:45:31 I think long time ago we did some ga 2018-05-24 20:45:37 <_ikke_> do we need to mention access logs? 2018-05-24 20:45:48 But it had been received afaik 2018-05-24 20:45:54 Removed... 2018-05-24 20:46:00 <_ikke_> lol, autocorrect 2018-05-24 20:46:01 do you know if the cdn fastly does data processing? like setting cookies? or other deidentification like using per-user etags? 2018-05-24 20:46:17 Not that I know 2018-05-24 20:46:52 https://www.fastly.com/privacy 2018-05-24 20:47:09 <_ikke_> it does set an e-tag 2018-05-24 20:47:16 <_ikke_> send* 2018-05-24 20:47:16 access logs might be mentioned regarding their logrotation policy 2018-05-24 20:47:17 They collect PII e.g. IP address 2018-05-24 20:47:36 ip addresses are ok, depending on how they are used 2018-05-24 20:47:45 although it is not clear if they're doing that everywhere 2018-05-24 20:48:05 if they combine this with other data and sell it is a concern. if they only collect it and then logrotate it away, it's ok. 2018-05-24 20:48:33 <_ikke_> "Fastly collects client IP address information on a limited basis to provide and improve its services." 2018-05-24 20:48:36 "In connection with operating our global caching network’s general interaction with the Internet, Fastly collects client IP address information on a limited basis to provide and improve its services. Fastly also may collect and retain for its legitimate business purposes client or Customer IP addresses associated with suspicious activity that may pose a risk to the Fastly network or our Customers, or 2018-05-24 20:48:38 that are associated with administrative connections to the Fastly service." 2018-05-24 20:48:53 but a client is not what users accessing site is 2018-05-24 20:48:59 so it's not clear 2018-05-24 20:49:37 fastly: "we collect from individuals who ... individuals who register for or authenticate to our edge cloud services (“Customers”)" - that sounds like they do not collect data about users of the cdn 2018-05-24 21:02:25 clandmeter: you can always check with /whois to make sure you are talking to who you think you're talking to btw... ;) 2018-05-25 06:41:17 i wonder who should be accountable. Lets say it turns out that alpine linux is collecting data and need to be punished. who should be punished? 2018-05-25 06:41:32 we are not a legal entitiy, just a bunch of individuals 2018-05-25 06:42:11 this may be a good reason to make sure we register a proper org, a legal person 2018-05-25 06:43:03 over at adelie we figured this out re GDPR 2018-05-25 06:43:16 what we figured out is we're in the US, and the EU wouldn't extradite for it 2018-05-25 06:43:18 :p 2018-05-25 06:43:46 the "right to be forgotten" is basically impossible with git. 2018-05-25 06:44:08 if someone wants their name and email deleted from a git repository it would corrupt the history and ruin any signatures 2018-05-25 06:44:45 <_ikke_> I think that's the reasonability clause where zNVxxliww5gP was talking about 2018-05-25 06:45:17 true 2018-05-25 06:45:31 <_ikke_> comes in* 2018-05-25 09:15:53 Natanael Copa: can I ask how the alpine rpi kernel config file generated? 2018-05-25 09:17:07 yangxuan8282[m]: if I had to guess... 2018-05-25 09:17:10 carefully 2018-05-25 09:20:33 i think it was a mix of rtfm, copy/paste and trial/error 2018-05-25 09:21:43 yangxuan8282[m]: if you're looking for the actual config, check /proc/config.gz 2018-05-25 09:21:46 on a running system 2018-05-25 09:22:53 actually 2018-05-25 09:22:56 -rw-r--r-- 0 buildozer buildozer 130384 Nov 30 13:51 ./boot/config-rpi 2018-05-25 09:23:00 it appears to be right in the tarball 2018-05-25 09:25:13 ahhhhhh 2018-05-25 09:25:14 hm ok 2018-05-25 09:26:12 yangxuan8282[m]: https://git.alpinelinux.org/cgit/aports/tree/main/linux-rpi?h=master 2018-05-25 09:26:36 if you're talking about the comment in the config: 2018-05-25 09:26:38 # Automatically generated file; DO NOT EDIT. 2018-05-25 09:26:41 # Linux/arm 4.9.63 Kernel Configuration 2018-05-25 09:27:15 extract the kernel source tree, copy arm config to .config in the root of the tree iirc, and run `make menuconfig' 2018-05-25 09:27:33 should give you a menu driven system to configure the kernel 2018-05-25 10:56:00 I think this " i think it was a mix of rtfm, copy/paste and trial/error" answer the question 2018-05-25 10:59:27 don't you love nicknames in 2018 2018-05-25 11:03:05 skarnet: don't judge :p 2018-05-25 11:03:39 I'm not judgin', I'm sassin' 2018-05-25 11:03:50 :p 2018-05-25 11:23:56 skarnet: have some random piece of sax and enjoy :p https://www.youtube.com/watch?v=MtzUPL7NNUI 2018-05-25 12:35:19 hmm hmm. seems we have a reason to believe that there's a bug in apk that can mess up ownerships of package contents when installed 2018-05-25 12:36:10 <_ikke_> reproducable? 2018-05-25 12:36:20 seems so 2018-05-25 12:37:03 there's an id cache that doesn't get re-read (I'm translating the guy sitting behind me) after running a pre-script that modifies /etc/group 2018-05-25 12:37:48 <_ikke_> 2 hard things in computer science: 1. cache invalidation 2. naming things 3. off-by-one errors 2018-05-25 12:38:04 :D 2018-05-25 12:38:36 he also says that adding a cache re-read right after running a pre-script that does modify users/groups, the behaviour changes to the expected one 2018-05-25 12:39:18 <_ikke_> But it's probably hard to know that a pre-script modifies users / groups 2018-05-25 12:39:32 <_ikke_> so you need to potentially do it always 2018-05-25 12:39:56 exactly, and currently this isn't the case 2018-05-25 16:36:33 i am changing my email address for mailinglists and in doing so i noticed that the unsubscribe does not work on the alpine mailinglist. can someone confirm that? 2018-05-25 16:38:23 <_ikke_> Never tried 2018-05-25 16:40:01 <_ikke_> leo-unglaub: list maintainer says it should owrk 2018-05-25 16:40:03 <_ikke_> work 2018-05-25 16:41:13 <_ikke_> leo-unglaub: if you pm the subscriber account to nangel, he can remove it manually 2018-05-25 16:41:32 <_ikke_> he has a suspicion on what's happening 2018-05-25 16:43:13 i just gave it another try: "Unable to unsubscribe from alpine-user@lists.alpinelinux.org" 2018-05-25 16:50:47 <_ikke_> leo-unglaub: Are you sure you used the correct e-mail address? 2018-05-25 16:51:57 yes sir 2018-05-25 16:52:39 <_ikke_> he says that e-mail address is not subscribed, but another similar one is 2018-05-25 16:52:45 again, its not that big of a deal. i can use my old address for alpine, i just wanted to bring all mailinglists onto one account 2018-05-25 16:53:07 <_ikke_> (.net) 2018-05-25 16:53:38 yes, i have both. one got unsubscribed and the other one is still active 2018-05-25 16:55:17 <_ikke_> should both be unsubscribed? 2018-05-25 17:13:04 hey 2018-05-25 17:13:10 are there plans for clang support 2018-05-25 17:13:15 or seperating armv6/armv7 2018-05-25 17:15:19 clang --version\nAlpine clang version 5.0.1 (tags/RELEASE_501/final) (based on LLVM 5.0.1) 2018-05-25 17:18:05 Perhaps they mean building the system with Clang? (I tried that once with Gentoo; it worked partially but it was pretty rough and some things broke) 2018-05-25 17:18:19 [the whole system or at least most of it] 2018-05-25 17:18:54 does the kernel build with clang? 2018-05-25 17:24:12 I am not sure. But I know Google were experimenting with building the Android kernel with Clang. 2018-05-25 17:27:37 What about seperate armv6/7? 2018-05-25 17:44:10 upstream builds with clang with minimal/no patches under certain arches 2018-05-25 17:52:04 cuz seperate armv6/armv7 packages would be help 2018-05-25 18:31:27 is blattersturm from bugs.a.o here? 2018-05-25 18:37:33 r 2018-05-25 18:41:18 _ikke_: yeah, both should 2018-05-26 02:13:20 any armhf developers around? 2018-05-26 02:17:02 need to recompile armhf kernel with more built in drivers - what is the *best* method? qemu / docker / x86_64 cross ? 2018-05-26 02:39:50 Natanael Copa: would you mind check this PR? https://github.com/alpinelinux/aports/pull/4337 2018-05-26 02:44:22 thank you - I am running nitrogen6x (iMX6Q 2GB) board and need kernel can bus support. 2018-05-26 18:22:02 jsmith_carlsbad : If you could emulate arm using qemu on x86* hardware, then do that 2018-05-26 18:22:26 cross-build on x86* is also possible but might require more work than qemu 2018-05-26 18:34:56 tmh1999: cross-build on AL or another distro? 2018-05-26 18:36:16 mps: on Alpine, cross-build on musl-x86, target is musl-arm. I'm not sure if you could cross-build on glibc-x86, target is musl-arm. Maybe you could. 2018-05-26 18:37:12 Last time I only cross-build the on glibc-x86, target musl-arm, but I never built the kernel. 2018-05-26 18:37:17 I build kernels for arm64 on Debian 2018-05-26 18:37:43 *the toolchains 2018-05-26 18:37:47 don't know how to do it on AL 2018-05-26 18:37:55 see aports/scripts 2018-05-26 18:38:26 or https://github.com/richfelker/musl-cross-make 2018-05-26 18:38:29 mkimage.arm.sh? 2018-05-26 18:39:17 and mkimage.sh 2018-05-26 18:39:19 tnx, will look 2018-05-26 18:40:31 personally I would setup a qemu/vm running Alpine on x86 to build rather than using Debian glibc-x86 2018-05-26 18:40:38 it would save time/risks 2018-05-26 18:40:48 look at /scripts/bootstrap.sh in aports 2018-05-26 18:41:03 it’s for cross-compiling 2018-05-26 18:41:12 mps: right bootstrap.sh not mkimage.sh, my mistake. Thanks jirutka :D 2018-05-26 18:41:22 unfortunately no one bothered to document it, so you have to figure it out yourself :( 2018-05-26 18:41:34 it's pretty straightforward I think 2018-05-26 18:41:44 yes, if you understand cross-compilation 2018-05-26 18:42:02 matured from fabled's old cross-scripts 2018-05-26 18:42:34 mps: those mkimage, mkig* scripts are for building boot media images. 2018-05-26 18:43:43 yes, just looked in it 2018-05-26 18:44:58 bootstrap.sh is used on musl-* host to build musl-* target. github.com/richfelker/musl-cross-make is used on glibc-* host to build musl-* target. just to clarify things. 2018-05-26 18:45:19 it would be nice to have installable cross-tools 2018-05-26 18:45:28 musl-cross-make is more general musl-oriented thing and bootstrap.sh is more Alpine-thing 2018-05-26 18:45:50 yeah :D but hey it's fun 2018-05-26 18:46:32 I'll write the wiki on this after 3.8 2018-05-26 18:47:02 it would be very useful, I think 2018-05-26 18:47:41 watching C1 game, ttyl, good luck 2018-05-27 00:39:36 alpine still dosn't have a tor package in the repos 2018-05-27 00:39:40 pathetic tbh 2018-05-27 00:40:44 You're an idiot, then. 2018-05-27 00:41:34 duncan^: literall isn't in the repos, the one in aports is """somewhat""" functional 2018-05-27 00:41:52 No idea what you're talking about, given tor is clearly packaged 2018-05-27 00:42:45 and it works fine. 2018-05-27 11:58:13 Tsutsukakushi: tor is in aports since v3.5 and I don’t see any opened bug report for it, so as duncan^ said… 2018-05-27 12:23:06 jirutka: I think they're trolling - they were banned from #alpine-linux 2018-05-27 12:23:24 and came here because the ban was not in place 2018-05-27 12:27:31 Tsutsukakushi ^ 2018-05-28 05:02:47 community/julia is a monster 2018-05-28 05:03:07 building it, ram is at 2.3GB and growing 2018-05-28 05:05:40 that seems cool 2018-05-28 11:28:41 Could someone please review https://github.com/alpinelinux/aports/pull/4382 ? It's kinda important, fixes complete breakage of borgbackup 2018-05-28 11:28:51 jirutka: ping, as you're the maintainer 2018-05-28 11:37:32 azarus: how this patch can fix it? we don’t install deps using setup.py 2018-05-28 11:38:24 jirutka: install_requires also checks at runtime 2018-05-28 11:38:35 try it, I assure you it works 2018-05-28 11:41:50 aha 2018-05-28 11:42:20 oh, see anything? 2018-05-28 11:44:09 I have no idea how it can work, but okay, merged 2018-05-28 11:44:14 don’t have time now to test it myself 2018-05-28 11:44:17 jirutka: Thank you. 2018-05-28 11:44:27 yw 2018-05-28 11:47:36 (also thanks for fixing the commit msg) 2018-05-28 11:51:30 jirutka: I can confirm with the new version (fresh from dl-cdn.a.o) the issue is resolved. Thanks again. 2018-05-28 14:17:33 wow, what happened to https://bugs.alpinelinux.org/issues/8345 ? 2018-05-28 14:17:46 I might tend to it, looks abandoned :( 2018-05-28 22:53:02 what compression does mkinitfs do by defualt, if any? 2018-05-29 00:31:49 hmm, i am looking thru all the differences between the standard and the virtual version of alpine, but i cannot find a reason why the virtual version works fine as a guest on openbsd's vmd and the standard version hands during POST 2018-05-29 00:31:56 has someone else an idea? 2018-05-29 00:40:52 leo-unglaub: They have different kernels 2018-05-29 00:41:32 It is possible there is something in standard that is making vmd choke badly 2018-05-29 00:42:03 You might want to try the vanilla variant instead because the hardened (i.e. grsec) kernel is not going to be in the next release 2018-05-29 00:42:21 so it would be more valuable debugging it against vanilla Linux variant. 2018-05-29 00:42:38 i am not sure if it even gets to the kernel, so i have not diffed the kernel config options yet 2018-05-29 00:42:56 Well, that's the main difference between the two 2018-05-29 00:43:07 virtual has a slimmed-down kernel 2018-05-29 00:44:44 maybe you are right and its not about the kernel itself but a size problem 2018-05-29 00:45:11 I don't think "size problem" is very descriptive 2018-05-29 00:45:37 I'm saying it may be to do with the kernel, which, on the virtual variant, is smaller. 2018-05-29 00:45:56 it is exactly what i meant. maybe the image itself it so big to be loaded. litherally to big to be read my vmd 2018-05-29 00:46:44 I doubt it; vmd is a virtualization program after all 2018-05-29 00:47:04 yeah, but its in very early beta and only works 100% with openbsd as its guest 2018-05-29 00:55:02 vanilla has the same problem as standard. only virtual works. WTF 2018-05-29 00:55:33 error: virtio_blk_io: device reset 2018-05-29 03:38:49 julia lang just released 0.6.3. 2018-05-29 04:15:37 Shiz, jirutka: I'm building julia-0.6.3 with openblas-0.3.0 and hitting this: http://tpaste.us/B6Vb. If you have any suggestion/exp/guidance, I'd be appreciate it :D 2018-05-29 07:48:25 <_ikke_> "time to switch away from alpine then I guess" due to libssl incompattibilities :( 2018-05-29 07:48:35 <_ikke_> (from #alpine-linux) 2018-05-29 13:08:12 _ikke_ well 2018-05-29 13:08:23 i said months ago we should switch to openssl 2018-05-29 13:08:33 but it was shot down 2018-05-29 13:09:00 i mean, i am a little grumpy about this because i keep having to "fix" things that are broken because libressl has different objectives 2018-05-29 22:27:19 It’d be better for the end user imo. 2018-05-29 22:27:22 To switch. 2018-05-29 22:47:22 having to fix things that shouldn't be broken* 2018-05-29 22:47:47 I'm also onboard with moving alpine over to openssl 2018-05-29 23:01:03 Switch to BoringSSL 2018-05-29 23:01:05 ACTION runs 2018-05-30 06:19:18 leo-unglaub: I don't know what the problem is, but I had various kernels crashing in VMD when I used the console, but when logging in using ssh it's "more" fine. There is something strange (maybe a bug?) with the clocks in VMD. Linux hangs when when there are certain kinds of disagreement between different clocks. To me it sounds like a bug in Linux, however it's only triggered on VMD. 2018-05-30 06:19:19 Linux got more stable when I forced it to use the TSC clock only. In this case I need to run ntp otherwise the time is drifting way too much. 2018-05-30 06:28:21 anServ- You are not authorized to perform this operation. 2018-05-30 06:32:03 ? 2018-05-30 06:40:45 awilfox, sorry 2018-05-30 06:40:51 wrong channel, nevermind 2018-05-30 06:44:36 ah okay 2018-05-30 07:50:10 ncopa, what are the show stoppers for v3.8? 2018-05-30 08:12:51 the builds needs to complete 2018-05-30 08:12:58 thats prio 1 2018-05-30 08:13:05 then we can do rc1 2018-05-30 08:13:15 then i need to look at the installer thing for s390x 2018-05-30 08:13:36 ncopa: I'm updating setup-disk.in. 2018-05-30 08:13:42 i would also like to fi chromium 2018-05-30 08:13:49 i spent a day on it last week 2018-05-30 08:13:53 <_ikke_> Is there a way to find out how far the builders are? 2018-05-30 08:13:54 fix* 2018-05-30 08:14:07 http://build.alpinelinux.org/ 2018-05-30 08:14:32 column to right should say how many % are totally built in that repo 2018-05-30 08:15:03 <_ikke_> it only says it currently for aarch64 and armhf 2018-05-30 08:15:30 because it is on idle 2018-05-30 08:15:33 I have a solution to not to update bootloader config (zipl) from cmdline, pushing soon 2018-05-30 08:15:42 tmh1999: great 2018-05-30 08:15:45 oh 2018-05-30 08:16:10 one more thing i need to do: move the s390x stuff to new machine that tmh1999 has provided for us 2018-05-30 08:16:20 rsync ? 2018-05-30 08:16:25 i promised to do that early this week 2018-05-30 08:16:26 yes 2018-05-30 08:16:38 but then this busybox wget issue showed up 2018-05-30 08:17:15 we can do it 2018-05-30 08:19:16 ACTION idly wonders how much time chromium wastes for alpine team, and how much time /not/ packaging it has saved adelie 2018-05-30 08:21:12 ^ 2018-05-30 08:21:48 well that's a low blow. I wonder how much time I save by not making a Linux distribution at all. :P 2018-05-30 08:22:48 also ^ 2018-05-30 08:23:16 humans still need to be something to get busy tho 2018-05-30 08:23:27 (I understand criticism of Chromium and criticism of Alpine, it's just, I won't criticize people doing the hard, ungrateful work I wouldn't do myself) 2018-05-30 08:31:21 skarnet: thanks 2018-05-30 08:31:30 its not like i dont have anything else to do 2018-05-30 08:32:21 blocker for aarch64: community/gwenhywfar 2018-05-30 08:32:42 xmltv too 2018-05-30 08:33:00 blocker for armhf: community/tinc-pre 1.1.15-r3 2018-05-30 08:33:21 i wonder if we really need tinc-pre in community? wouldnt it be enough to have it in testing? 2018-05-30 08:33:49 looks like go needs to be bootstrapped on aarch64 too 2018-05-30 08:34:25 ncopa: I guess so, I bootstrapped it on ppc64le 3.8 builder but I guess also needs in aarch64 2018-05-30 08:34:56 rdutra: thanks for taking care of the pcc64le builder 2018-05-30 08:39:24 ncopa, no we need tinc-pre in community. 2018-05-30 08:41:20 ok 2018-05-30 08:45:58 ncopa, tinc-pre has been disabled on armhf but builder still seems stuck on it? 2018-05-30 08:46:55 looks like it is hanging in the test suite 2018-05-30 08:46:59 i can kill it 2018-05-30 08:47:23 <_ikke_> Lots of test suites that seem to just hang often 2018-05-30 08:47:33 ncopa: np 2018-05-30 08:47:45 _ikke_: yes 2018-05-30 08:47:54 i wonder if it related that it runs in fakeroot 2018-05-30 08:48:43 i guess we should have a max exec time per build? 2018-05-30 08:49:10 with some exceptions. 2018-05-30 09:11:11 you could time builds and define thresholds; if the build takes considerably longer (or heck, considerably less) then there's probably a problem 2018-05-30 09:11:45 only rarely does a package change so drastically that it starts taking three times the original time to build 2018-05-30 10:03:12 skarnet: no, I'm not criticising Alpine as a distro, I just think there are way more important things to do than give google more control/money 2018-05-30 10:03:19 so chromium should be not packaged 2018-05-30 10:03:30 if it is broken, it should go in unmaintained/ 2018-05-30 10:03:42 that's what happens with *every* *other* *package* that is a constantly moving target 2018-05-30 10:03:52 that is hard to keep working, and refuses to build right, and has bunches of CVEs 2018-05-30 10:03:59 ^ 2018-05-30 10:04:04 I can get behind that 2018-05-30 10:04:20 but what of the user demand? 2018-05-30 10:04:29 i agree tho that people depend on browsers, so just removing them isn't an good option for many users 2018-05-30 10:04:39 to phrase it another way, alpine is too important to waste effort and time and possibly even slip for a non-free browser 2018-05-30 10:04:41 is there a single browser out there that's not a moving target and not full of CVEs? 2018-05-30 10:04:48 skarnet: w3m 2018-05-30 10:04:50 let alone a free one? 2018-05-30 10:04:56 firefox, otter, midori, dillo, elinks, w3m 2018-05-30 10:05:07 most of those even already have alpine packages 2018-05-30 10:05:08 liwakura: w3m, not full of CVEs? uh. 2018-05-30 10:05:17 ACTION scratches head 2018-05-30 10:05:21 i hope so 2018-05-30 10:05:29 and all of those are free browsers, free as in freedom 2018-05-30 10:05:50 not free as in "google makes people work on it for free and uses it to do terrible things and run an advertising empire" 2018-05-30 10:07:36 ideally, users should be able to decide that for their own 2018-05-30 10:08:14 user demand can be handled with container-based app solutions such as docker, flatpak and others - from the official sources 2018-05-30 10:08:20 ideally, users would be able to make informed decisions, and have every open source project that has ever been written at their disposal 2018-05-30 10:08:24 this is not an ideal world 2018-05-30 10:08:27 ye 2018-05-30 10:08:52 honestly if you want chromium, big bloated security-hole-ridden adware, then why are you using musl distro at all 2018-05-30 10:09:00 use glibc distro (or glibc chroot or glibc docker container or w/e) 2018-05-30 10:09:25 there is really no reason I can think of to waste an alpine computer on chromium 2018-05-30 10:10:08 people seem to like the speed of apk 2018-05-30 10:11:40 well I'm not saying I like chromium... I am saying it's right there where it belongs in the garbage fire that is the browser ecosystem 2018-05-30 10:12:24 and I agree that people shouldn't jump through hoops to package it, but eh. 2018-05-30 10:12:56 compiling a browser, *any* browser, is waaaaay too tight a hoop for me anyway. :P 2018-05-30 10:13:35 so take the container route and endorse a supplier of such a container 2018-05-30 10:13:54 firefox takes maybe 40 minutes on decent hardware, and the rest are sub-10 minutes even on the crappy pentium 4 builder we have for i586 2018-05-30 10:14:13 chromium is 26 hours or more on the best hardware 2018-05-30 10:14:59 you're talking machine time, and by now you should know I don't care much about machine time (although, to be fair, more building time is certainly an indication of more bloat, which I don't like) 2018-05-30 10:15:14 I'm talking ease of build from scratch for a human 2018-05-30 10:15:19 more building time means if you have to make a patch, you have to wait 26 hours to see if that patch fixed it 2018-05-30 10:15:28 and it likely won't the first time around 2018-05-30 10:15:31 and I have no doubt that chrome is hellish to build 2018-05-30 10:15:33 otherwise the bug wouldn't exist in the first place 2018-05-30 10:15:49 and that means you are holding up the whole distribution because google is an asshole 2018-05-30 10:15:56 and really, what is the point of doing that 2018-05-30 10:16:01 true, it lengthens the debug cycle 2018-05-30 10:16:51 I sure wish this crappy rack provider's ipv6 wasn't down 2018-05-30 10:17:17 then I could be more properly explaining browser builds that we do on interlinked/#adelie instead of here 2018-05-30 10:18:03 but basically, mozilla's build system (mach) is crap but it allows incremental building if you leave the object folder in-tact (so, remove 'source' or 'srcdir' or whatever it is from ABUILD_CLEANUP) 2018-05-30 10:18:15 ah, so that's why you left... you got kicked by 2018-05-30 10:18:16 chromium's doesn't do incremental building per-file, it does it per-tree 2018-05-30 10:18:59 ccache helps a loooot with such buildsystems. 2018-05-30 10:19:00 skarnet: specifically, it is either HE (which would surprise me) or that really really CRAP ISP that runs nodes in chicago (the name escapes me... but I know the person who runs it... not nice person) 2018-05-30 10:19:33 Gottox: if there is a secret to making ccache work properly with abuild, I wish someone would tell me already. right now it still blows up really really badly if I try to build anything more complicated than gnu hello with it. 2018-05-30 10:20:00 i have been using chromium for a while now. helps me get the job done 2018-05-30 10:20:05 I'm not into abuilds at all, but void uses it extensively. 2018-05-30 10:20:28 I haven't bothered to look in to it because ccache really should not be something I have to worry about 2018-05-30 10:20:38 thanks to the patches from void, it has not been an overwhelming task to keep it updated 2018-05-30 10:20:46 until now 2018-05-30 10:20:54 I'm not aware of any package we ship in adelie that doesn't support incremental builds, so ccache is a waste of time 2018-05-30 10:21:13 and adelie ships a pretty significant subset of alpine, so it wouldn't help alpine either AFAIK 2018-05-30 10:21:19 (if that is inaccurate, I can poke at it more) 2018-05-30 10:21:20 <_ikke_> awilfox: do you keep the compiled source around? 2018-05-30 10:21:31 ncopa: duncaen and chromium is a love/hate relationship :) 2018-05-30 10:21:39 _ikke_: for builds that !check, yes, until I can manually check it 2018-05-30 10:21:58 _ikke_: otherwise, I /try/ to trust that distributed test suites are good enough of a smoke test 2018-05-30 10:22:30 Gottox: i'm not surprised :) 2018-05-30 10:22:31 for example, qt5-qtwebkit doesn't have a test suite, so I have the src/ for it on each new arch's builder, until I can drive otter really hard 2018-05-30 10:23:15 of course, aarch64 has been "fun time" 2018-05-30 10:23:21 I've just brought ltrace to it 2018-05-30 10:23:36 they had some patches lying around in git but never shipped them, it seems ltrace is dead upstream 2018-05-30 10:23:47 and the git patches didn't build properly at first, so I had to integrate them properly, but it is all working now 2018-05-30 10:26:06 awilfox: there was some questions about qt 5.10 upgrade, i was not aware that it caused problems for adiele. I knew pmos wanted a heads up for qt 5.10 2018-05-30 10:26:28 tbh, i was not aware that qt 5.9 was LTS 2018-05-30 10:26:53 that was mentioned multiple times on both the ML and in here, but what's done is done 2018-05-30 10:27:08 I've already warned the adelie community that there is no more guaranteed ABI compatibility between alpine community and adelie user 2018-05-30 10:27:18 but it should work fine, as long as qt isn't involved 2018-05-30 10:27:35 tbh, over half of adelie is running on arches alpine doesn't, so it didn't matter much anyway 2018-05-30 10:27:57 we have a few dozen people on ppc and ppc64 (be), maybe 2 on ppc64le, and then a dozen or so on x86_64 2018-05-30 10:28:01 tbh I'm (from pmOS) quite glad with the Qt 5.10 upgrade, but I definitely understand wanting to stay on a LTS release 2018-05-30 10:28:31 and four on armv7 (alpine is doing armhf which is v6; we targeted v7 specifically to deliver optimised experience for those chips, and we believe alpine has v6/hf covered well) 2018-05-30 10:28:49 I think only x86_64 and aarch64 overlap 2018-05-30 10:29:27 PureTryOut[m]: it breaks a lot of stuff desktop-side, especially in the kde application suite (or whatever they call it now) 2018-05-30 10:29:54 PureTryOut[m]: it is not so bad with plasma itself, but the qtquick changes really affect some desktop plasmoids and stuff like systemsettings5 2018-05-30 10:30:01 i will pay better attention next time 2018-05-30 10:30:42 PureTryOut[m]: a lot of it is "fixed" in 5.11, but 5.11 also removes x86 support fully, and doesn't even build right on armv7 or ppc right now (32-bit) 2018-05-30 10:30:50 PureTryOut[m]: so we literally can't ship 5.11 2018-05-30 10:30:54 aw 2018-05-30 10:31:03 hoping it gets fixed soon 2018-05-30 10:31:22 it is mostly qtdeclarative which is broken 2018-05-30 10:31:24 qtbase still works 2018-05-30 10:32:06 it is still beta 2018-05-30 10:32:08 they have time to fix it 2018-05-30 10:32:27 ncopa: would you be interested in ltrace patch to make it work on aarch64? 2018-05-30 10:32:41 so far that is only aarch64 thing I have fixed from aports 2018-05-30 10:32:58 sure 2018-05-30 10:33:22 next on my list will be community/emacs, because our kernel engineer swears by emacs (and swears at vim) so I have to make him happy :p 2018-05-30 10:33:35 ha! :D 2018-05-30 10:33:44 i saw there was a new emacs release 2018-05-30 10:33:56 the dynamics of a small team :) 2018-05-30 10:34:21 lots of work to keep everyone happy :) 2018-05-30 10:35:12 > No issues: ppc, x86_64 Missing user pkgs: aarch64 (55), armv7 (170), pmmx (5) Missing system pkgs: aarch64 (32), armv7 (53), ppc64 (7) 2018-05-30 10:35:18 this is current build status for adelie 2018-05-30 10:35:41 armv7 is a problem because libevent fails test suite for some reason 2018-05-30 10:35:49 but aarch64 is looking pretty good 2018-05-30 10:37:01 ppc64 is valgrind and strace related... I've mostly ported valgrind to ppc64-musl (remember, musl uses different ABI to every other ppc64 distro), but strace is kicking my butt still 2018-05-30 10:37:43 we still hope to eventually bring ppc64 (be) support to alpine, but we want the distro to actually work on it first :p 2018-05-30 10:38:05 well, fully. ppc64 is actually my daily driver 2018-05-30 10:38:18 but missing valgrind and strace makes debugging harder, so I don't consider it complete 2018-05-30 11:21:14 I see the bridge is not passing through some messages. ncopa were you talking to awilfox? 2018-05-30 11:29:05 <_ikke_> PureTryOut[m]: last message from ncopa was "lots of work to keep everyone happy :)" 2018-05-30 14:54:50 Hello all. From what I've gathered there is no way to pin to a particular package release. What can I do to prevent my package from getting clobbered when an upstream dependency is updated? Specifically, there are several packages that were built against proj4 v4.9.3 that now fail with proj4 v5.0.1 because the .so version is no longer available. Is the only work around to bump pkgrel and rebuild against the new release, or is 2018-05-30 14:58:55 <_ikke_> chambbj: your question was truncated (around new release, or is..). 2018-05-30 14:59:35 <_ikke_> The alternative would be to maintain your own repo with the package + dependencies 2018-05-30 15:02:16 Okay, long question, sorry. Only concluded by asking if there was something more proactive we could do to prevent this. 2018-05-30 15:24:18 <_ikke_> was libressl reverted or something? Users reporting incorrect signatures on dl-cdn 2018-05-30 15:26:27 changes were updated to 3.4 3.5 3.6 3.7 branch lately 2018-05-30 15:27:02 <_ikke_> right, but normal updates should not cause incorrect signatures, but reusing a pkgver+rel does 2018-05-30 15:27:19 <_ikke_> (on dl-cdn) 2018-05-30 15:28:24 agreed 2018-05-30 15:31:02 It looks like ncopa decreased pkgrel when reverting instead of increasing 2018-05-30 15:36:53 <_ikke_> right 2018-05-30 15:55:43 <_ikke_> Someone available to bump the pkgrel of libressl? 2018-05-30 16:23:27 hi all, how is the init script used to boot alpine generated, it looks like it is from mkinitfs, ive created a a new package for my custom mkinitfs but it is never used, it always seems to default back to alpines version 2018-05-30 16:57:45 builder: it's here https://git.alpinelinux.org/cgit/mkinitfs/tree/initramfs-init.in 2018-05-30 16:58:13 it's then installed into /usr/hare/mkinitfs/initramfs-init.in : https://git.alpinelinux.org/cgit/mkinitfs/tree/Makefile#n122 2018-05-30 17:02:15 you could either modify /usr/share/mkinitfs/initramfs-init.in directly on your system or, build your own mkinitfs.apk (with bumped pkgrel) then edit /etc/apk/repositories so that your mkinitfs is picked up instead of downloading from Alpine repo 2018-05-30 17:02:19 builder: ^ 2018-05-30 17:11:57 Hey 2018-05-30 17:12:05 anyone know how to get argp_parse to work on alpine 2018-05-30 17:12:27 <_ikke_> What is argp_parse 2018-05-30 17:13:43 glibc thing i think 2018-05-30 18:30:24 <_ikke_> ncopa: we still need something to at least warn about this issue 2018-05-30 18:42:43 <_ikke_> ncopa: still working on testing buildbot btw 2018-05-30 18:45:36 sorry about the libressl revert 2018-05-30 18:46:00 i didnt commit the pkgrel bump 2018-05-30 18:46:45 are there anyone interested to run some benchmarks on alpine with different disk storages? 2018-05-30 18:47:20 on this hardware https://www.acceleratewithoptane.com/access 2018-05-30 18:50:09 hi, in gcc a manual came across 'Option that control Optimization' 2018-05-30 18:50:09 nice section with lots of option like ggc-min-expand, and ggc-min-heapsize. 2018-05-30 18:50:13 just wondering if using them may by chance improve 'chromium' build time 2018-05-30 18:50:27 and don't ask me to explain ;) 2018-05-30 18:51:21 if someone does try, pls let us know the difference 2018-05-30 18:53:27 awilfox, ^^ 2018-05-30 18:54:23 anyone know how to get argp_parse (glibc function) to work on alpine? 2018-05-30 18:56:44 steamport: i think there is a staic lib for it 2018-05-30 18:57:01 ncopa, link? 2018-05-30 18:57:12 i couldn't find one that worked 2018-05-30 18:57:48 apk add argp-standalone 2018-05-30 18:58:33 then only thing you'll need is to add -largp to linker flags 2018-05-30 18:58:44 often its: LIBS="-largp" ./configure ... 2018-05-30 19:03:21 i'm trying to compile nexmon 2018-05-30 19:03:58 you may need patch build scripts depending on the build system 2018-05-30 19:07:24 ohk 2018-05-30 19:07:28 it uses makefile 2018-05-30 19:07:31 s 2018-05-30 19:08:07 Hahaha 2018-05-30 19:08:13 it uses -largp already for macOS 2018-05-30 19:08:32 time to make it do that on linux 2018-05-30 19:27:18 ncopa, do i need to add -L...? 2018-05-30 19:27:45 i dont think you need 2018-05-30 19:27:53 and if you need then it is -L/usr/lib 2018-05-30 19:28:02 but that shoudl be standard location for libs 2018-05-30 19:28:16 fpext.c:(.text+0xa04): undefined reference to `argp_parse' 2018-05-30 19:38:01 ncopa, didn't help 2018-05-30 19:39:11 fpext.o: In function `main': 2018-05-30 19:39:11 fpext.c:(.text+0xa04): undefined reference to `argp_parse' 2018-05-30 19:58:48 was -largp added to linker? 2018-05-30 19:58:59 check your build log if it was actually aded 2018-05-30 19:59:33 i added it to gcc 2018-05-30 20:00:16 here's the patch i used, ncopa: https://pastebin.com/GKCcj9kR 2018-05-30 20:00:59 steamport: try add it to the last 2018-05-30 20:01:09 move the -largp to the end of the line 2018-05-30 20:02:53 ncopa: so, like this? "gcc -o $@ $^ -L/usr/lib -largp" 2018-05-30 20:03:01 yes 2018-05-30 20:03:10 i think you can drop the -L/usr/lib 2018-05-30 20:03:14 should not be needed 2018-05-30 20:03:48 yeah, i'm trying to get nexmon working on pmOS (alpine-based distro for mobile devices) 2018-05-30 20:03:51 mainly to patch broadpwn 2018-05-30 20:09:40 jirutka: any clue whats going on with lua-lpeg with luajit on aarch64? 2018-05-30 20:12:22 ncopa, that worked 2018-05-30 20:12:33 nice 2018-05-30 20:13:04 the reason that it needs to be at the end is because we add --as-needed by default as linker flag 2018-05-30 20:13:16 (i think) 2018-05-30 20:13:48 wtf 2018-05-30 20:13:53 ncopa, "/usr/lib/gcc/armv6-alpine-linux-musleabihf/6.4.0/../../../../armv6-alpine-linux-musleabihf/bin/ld: cannot find -ll" 2018-05-30 20:14:28 dunno 2018-05-30 20:14:42 dunno what added -ll 2018-05-30 20:14:59 sounds like some regex went wrong or similar 2018-05-30 20:15:02 it's a different makefile though 2018-05-30 20:15:08 so maybe i'm missing a dep 2018-05-30 20:15:11 could me anything 2018-05-30 20:15:19 sounds like a bug in makefile 2018-05-30 20:17:22 ncopa, https://github.com/seemoo-lab/nexmon/blob/master/buildtools/b43/assembler/Makefile#L28 2018-05-30 20:17:26 LDFLAGS += -ll 2018-05-30 20:18:06 hm 2018-05-30 20:19:14 no clue what that could be 2018-05-30 20:19:26 kunkku, an interesting feature to add to awall: 2018-05-30 20:19:27 https://www.cyberciti.biz/faq/how-to-add-comments-to-iptables-rules-on-linux/ 2018-05-30 20:19:56 (yes, we have description in the .json, but this looks cooler :) 2018-05-30 20:20:23 n8 pals, ttl 2018-05-30 20:20:31 <_ikke_> nite 2018-05-30 23:03:00 jirutka: PR for Rust 1.26.1 is coming as soon as the build finishes 2018-05-30 23:03:13 ACTION burns his AMD RYZEN to the max :) 2018-05-30 23:04:49 ryzen is nice 2018-05-30 23:04:53 i got a R5 1400 2018-05-30 23:06:27 nice, i have a 1700X and a Threadripper 1950 :) 2018-05-30 23:15:54 i also got an RX 580 2018-05-30 23:21:57 wow, that must be very nice 2018-05-30 23:22:01 do you use it for 4k? 2018-05-31 04:52:18 cool, I finished porting valgrind to ppc64 today... and strace was simple configure option :) 2018-05-31 04:52:48 <_ikke_> awilfox: \o/ 2018-05-31 07:35:45 hum, the 3-7 builders are broke due to this openssl symbol business 2018-05-31 07:35:56 build-3-7-armhf:~$ openssl 2018-05-31 07:35:56 Error relocating /usr/bin/openssl: X509_VERIFY_PARAM_set1_host: symbol not found 2018-05-31 07:35:56 Error relocating /usr/bin/openssl: X509_VERIFY_PARAM_set1_ip_asc: symbol not found 2018-05-31 07:36:17 WARNING: Ignoring /home/buildozer/packages/main/armhf/APKINDEX.tar.gz: UNTRUSTED signature 2018-05-31 07:47:26 getfattr: ./usr/libexec/git-core/stakbJAE: No such file or directory 2018-05-31 07:47:26 strip: './usr/libexec/git-core/stakbJAE': No such file 2018-05-31 07:47:26 >>> ERROR: git*: prepare_package failed 2018-05-31 07:47:26 >>> ERROR: git: all failed 2018-05-31 07:47:45 does anyone has any clue whats going on with strip? 2018-05-31 07:48:05 when abuild does prepare_package it finds some temp files 2018-05-31 07:48:09 and errors out 2018-05-31 07:48:20 i have seen it on armhf, ppc64le 2018-05-31 07:48:34 it looks like a race of some sort 2018-05-31 08:02:44 awilfox: hey I was wondering if there is any update on group maintaining of packages? in regards to KDE specifically 2018-05-31 08:14:55 damn IRC and unstable connections. did I miss an answer to my question by any chance? 2018-05-31 08:16:14 <_ikke_> nope 2018-05-31 08:59:11 PureTryOut[IRC]: not as far as I know. 2018-05-31 09:10:54 hmm, I'd really love KDE to be in Alpine. besides the benefit for pmOS, I'm thinking of switching my laptop to Alpine but I "need" KDE ;) 2018-05-31 09:11:56 what's pmOS? 2018-05-31 09:12:31 (also, ugh, Qt is a nightmare, we're currently limted to 4.X :( ) 2018-05-31 09:13:50 <_ikke_> azarus: a mobile os based on Alpine 2018-05-31 09:13:58 ah, post market os? 2018-05-31 09:14:15 I know that, just never heard of the acronym 2018-05-31 09:15:47 yeah pmOS is postmarketOS 2018-05-31 09:15:53 sorry for any confusion ;) 2018-05-31 09:19:38 tmh1999, ok so it's more about the mkinitfs that is used on the system building alpine. 2018-05-31 09:49:51 awilfox: should I post the question to a mailing list or something? just to get the discussion rolling 2018-05-31 09:58:37 PureTryOut[IRC]: honestly I don't think I would want to merge KDE in with Qt 5.10 2018-05-31 09:58:56 it's a miserable experience on the desktop, and I'm still ironing out the bugs on armv7 2018-05-31 09:59:01 with KDE Plasma, that is 2018-05-31 10:02:36 I didn't realize Alpine supported armv7? or I guess you mean armhf? 2018-05-31 10:02:41 how is it a miserable experience though? 2018-05-31 10:02:54 alpine's armhf, adelie's armv7, both are 32-bit ARM, and both need help for plasma 2018-05-31 10:03:15 ah yeah ok 2018-05-31 10:03:58 qtdeclarative is horribly broken on the desktop and it has made many things unstable 2018-05-31 10:04:24 memory leaks, segfaults, two or three actual deadlocks 2018-05-31 10:06:22 rnalrd: thanks for following up on the gnupg patch 2018-05-31 10:06:40 some of them are fixed in 5.11, most aren't yet 2018-05-31 10:06:56 it's a miserable time and I wouldn't want anyone's impression of alpine to be tainted by that 2018-05-31 10:07:14 this is the kind of experience that would make someone say "wow, musl really is broken" or "wow, alpine really is for servers only" 2018-05-31 10:07:38 and it doesn't even have anything to do with it, it's broken just as bad on glibc 2018-05-31 10:13:48 yeah I understand. we'll see what happens with Qt 5.11 then 2018-05-31 10:14:14 we did indeed notice breakage with qtdeclarative on armhf as well, but the issues seemed to dissappear on DRM 2018-05-31 10:39:04 Does anyone know if we have a g++ 7 port for alpine yet? I have some c++ 17 code that needs to be compiled with this version 2018-05-31 10:41:32 builder: need upsrteam musl merge gcc7 first 2018-05-31 10:45:31 hmm ok.. thanks by the way for the tip of bumping mkinitfs versions above alpines worked a charm!! 2018-05-31 10:46:33 builder: yep ! happy alpining ! 2018-05-31 13:34:39 i think i know whats wrong with abuild and the strip problem 2018-05-31 13:34:58 scanelf reads the directories 2018-05-31 13:35:12 i think strip or other tool creates a temp file while working on it 2018-05-31 13:35:25 scanelf runs in its own process 2018-05-31 13:35:45 so it may pick up the temp file that strip tool creates 2018-05-31 13:36:00 and then will it try to strip it 2018-05-31 13:36:28 but that will fail because the file no longer exist 2018-05-31 13:36:41 it means that we cannot pipe it 2018-05-31 13:36:52 we need to send it to a tempfile 2018-05-31 13:37:01 scanelf .... > $tmpfile 2018-05-31 13:37:15 and then: while read ...; ...; done < $tmpfile 2018-05-31 13:37:22 that way we avoid that race 2018-05-31 13:51:06 hum 2018-05-31 13:51:15 i wonder if we shoudl check if file exists instead 2018-05-31 13:51:37 this is using tempfile: http://tpaste.us/xezw 2018-05-31 15:27:16 hum 2018-05-31 15:27:25 i think we need disable luajit for aarch64 2018-05-31 15:27:44 it seems to have some serious problems 2018-05-31 15:28:04 https://github.com/LuaJIT/LuaJIT/issues/49 2018-05-31 15:54:52 ncopa: the luajit for aarch64 has some known problems 2018-05-31 15:57:45 ncopa: the main concern is the "lightuserdata" code that has a 47-bit datatype. there are ways to work around it, but they involve selective code changes 2018-05-31 15:59:06 ed-packet: i saw. i need to disable various lua modules for luajit on aarch64 now 2018-05-31 16:00:09 but it seems to only be modules that uses lightuserdata so i only disable those for now 2018-05-31 16:01:39 ok, sounds good. if you have a list of those I can reference I can put those on a hit list for review. 2018-05-31 16:03:14 I know for instance that the neovim folks did a complete workaround, and that the powerdns crew has some patches under review.