2018-06-01 01:41:54 why is valgrind !aarch64? 2018-06-01 04:27:07 awilfox: good question. it probably failed to build at some point? 2018-06-01 05:25:24 ncopa: it seems to be working locally 2018-06-01 05:44:58 i enabled it 2018-06-01 05:44:59 thanks 2018-06-01 05:51:50 np :) 2018-06-01 06:29:48 wow! looks like armhf v3.8 builder is ready! 2018-06-01 06:29:53 maybe we can do rc1 today 2018-06-01 06:30:07 <_ikke_> ncopa: \o/ 2018-06-01 06:30:20 nice 2018-06-01 06:30:25 the gnupg test suite seems to deadlock though 2018-06-01 06:30:28 i have no clue why 2018-06-01 06:31:52 what was that gzip replacement that uses threads again? 2018-06-01 06:32:36 our aarch64 builder is... pathetic in this regard; it can do -j32 so builds are super fast, and then it sits forever at "Compressing data"... clang took over an hour to gzip 2018-06-01 06:32:57 it seems to me like abuild 3.2-rc1 added support for better gzip program but I don't remember what the name was 2018-06-01 06:32:58 <_ikke_> tigz 2018-06-01 06:33:05 <_ikke_> pigz* 2018-06-01 06:33:10 aah 2018-06-01 06:33:15 thanks, _ikke_ :) 2018-06-01 06:33:28 <_ikke_> np 2018-06-01 06:33:57 <_ikke_> We use it as well to speed up backups 2018-06-01 06:57:41 awilfox, _ikke_ i think i also added it to abuild 2018-06-01 06:58:11 clandmeter: yeah that's why I said "abuild 3.2-rc1 added support" 2018-06-01 06:58:15 I just didn't remember what it was called 2018-06-01 06:58:24 we're about to see how well it works, aarch64 is building thunderbird 2018-06-01 06:59:42 yes aarch64 should work nicely :) 2018-06-01 06:59:45 lots of cores 2018-06-01 07:00:06 recent unxz also has support for it. 2018-06-01 07:00:11 not the one from b 2018-06-01 07:00:12 b 2018-06-01 07:00:14 bb 2018-06-01 07:00:29 mmm, nice 2018-06-01 07:00:49 yeah we have builder hw that is frankly silly with how many cores it has... 96 2018-06-01 07:01:04 yes same here 2018-06-01 07:01:09 <_ikke_> hehe 2018-06-01 07:01:20 made porting much easier than, say, arm32 2018-06-01 07:01:38 i also tried to add axel support, but it had some negative effect on slow ftp connections 2018-06-01 07:02:54 it is funny, we had some people join adelie that were really wanting to see ARM take off.. so we ended up with an arm32 and arm64 buildbox... the arm32 has just finished our system/ repo and is at 'a'pache-httpd in user/ (that would be kind of like main and community in alpine I guess), it was started on 14 March 2018-06-01 07:03:14 the arm64 box has 'composed'/built entire system and user repo... it was started 25 March 2018-06-01 07:03:46 which hw do you use for arm32? 2018-06-01 07:04:03 Hardware : Marvell Armada 370/XP (Device Tree) 2018-06-01 07:04:18 it is four core 2018-06-01 07:04:54 it really shouldn't be such a slouch.. the x86 builder we have is a /pentium 4/, and it composed faster 2018-06-01 07:05:27 the xgene we have is okis 2018-06-01 07:05:58 it does 32-bit too? 2018-06-01 07:06:18 but of course its slower than real aarch64 2018-06-01 07:06:21 yes it does 2018-06-01 07:06:35 the arm64 we have is a thunderx, I was told you can't do 32-bit stuff on it, so I never even considered trying it in a container 2018-06-01 07:06:47 correct it cant 2018-06-01 07:06:55 ah okay 2018-06-01 07:06:58 but xgene can? 2018-06-01 07:07:03 yes 2018-06-01 07:07:06 nice 2018-06-01 07:07:07 if you can find one 2018-06-01 07:07:31 not sure who sells them. 2018-06-01 07:07:47 i think they have some newer spec, not sure it also support 32bit mode. 2018-06-01 07:08:09 omg... abuild.conf on the arm32... JOBS=1 2018-06-01 07:08:15 I think I see why it is so slow, hahahaha 2018-06-01 07:08:19 <_ikke_> :D 2018-06-01 07:08:19 :) 2018-06-01 07:08:26 <_ikke_> That doesn't help 2018-06-01 07:10:36 the default is 2 2018-06-01 07:11:15 I think it was to debug some build issue probably 2018-06-01 07:11:20 three of us have access to this box 2018-06-01 07:11:43 I know we were having really bad issues with libevent on arm for some reason 2018-06-01 07:23:50 ncopa: re: openblas and its rdeps, do you want 1 commit or multiple commits in the PR ? 2018-06-01 07:35:02 multi commits in the PR 2018-06-01 07:35:03 can someone please merge https://github.com/alpinelinux/aports/pull/4384 - emacs seems to be segfaulting lately, and this upgrade solves it. 2018-06-01 07:35:28 gnupg test suite deadlocks 2018-06-01 07:35:34 its a blocker 2018-06-01 07:36:13 i can reproduce it locally with the commit rnalrd reverted, but even if commit is reverted, it deadlocks on builders 2018-06-01 07:36:19 so i think we need to fix it 2018-06-01 07:38:18 alternatively: we disable the test that deadlocks 2018-06-01 07:41:59 ncopa, disabling the test is a quick workaround 2018-06-01 07:42:20 i'd like the submitter to properly fix though 2018-06-01 07:42:44 i dont think its the submitters fault 2018-06-01 07:42:56 i mean, the problem happens even without his patch 2018-06-01 07:44:24 ok, sorry didn't read properly your comment 2018-06-01 07:44:29 ok 2018-06-01 07:44:49 i also tried to upgraded to 2.2.7 2018-06-01 07:45:56 commenting out the tests that deadlock makes it deadlock in next test 2018-06-01 07:47:49 yes, several needs to be disabled: http://tpaste.us/Q4el <-- just a partial list 2018-06-01 07:47:56 but more needs to be disabled 2018-06-01 07:58:54 i might have found a debian patch that could be relevant 2018-06-01 07:59:03 aha! 2018-06-01 08:00:06 * avoid testsuite delays from excess socket waiting 2018-06-01 08:09:35 yep, that fixes it 2018-06-01 08:09:48 at least for me :D 2018-06-01 08:14:19 which file is it? 2018-06-01 08:14:40 the patch is: assuan-Reorganize-waiting-for-socket.patch 2018-06-01 08:15:02 now retesting with smartcard patch 2018-06-01 08:15:30 mm 2018-06-01 08:15:52 seems that is not fixed 2018-06-01 08:16:05 ok, lets just disable the tests for now 2018-06-01 08:16:07 the smartcard patch triggers the issue for me 2018-06-01 08:16:12 you can continue work on it if you want 2018-06-01 08:16:13 yes 2018-06-01 08:16:19 k 2018-06-01 08:16:19 smartcard patch makes it easy to reproduce 2018-06-01 08:17:09 ok, testing and pushing with checks disabled for now 2018-06-01 08:17:19 upgrade to 2.2.7 too while at it 2018-06-01 08:18:06 k 2018-06-01 08:30:19 rnalrd: can you please add a comment to the !check, like: # FIXME: tests deadlocks so we disable for now 2018-06-01 09:54:15 yeah we have builder hw that is frankly silly with how many cores it has... 96 2018-06-01 09:54:16 yes same here 2018-06-01 09:54:47 who between Adélie and Alpine has the biggest d^Hbuilder? 2018-06-01 09:54:53 find out in our next episode! 2018-06-01 09:54:59 %-) 2018-06-01 09:56:58 ncopa: yes, forgot, sorry 2018-06-01 14:09:30 the migration of the s390x builder is done. it now runs on alpine host instead of ubuntu :) 2018-06-01 14:14:32 ncopa, is that error related to migration? http://build.alpinelinux.org/buildlogs/build-edge-s390x/testing/php7-phalcon/php7-phalcon-3.3.2-r0.log 2018-06-01 14:15:07 andypost, yes and it should be fixed now 2018-06-01 15:14:21 has anyone had any luck using lxc in alpine containers fail to start due to cgroups 2018-06-01 15:14:30 lxc_cgfs - cgroups/cgfs.c:cgfs_init:2363 - cgroupfs failed to detect cgroup metadata 2018-06-01 15:15:51 also the package doesnt name all the dependencies like rsync 2018-06-03 15:01:14 Hello all! I've been trying to use the Raspberry Pi alpine images: https://wiki.alpinelinux.org/wiki/Raspberry_Pi 2018-06-03 15:01:26 Turns out they don't boot at all on a RPI 3b+ 2018-06-03 15:01:40 And on the RPI 3b the brmcfmac driver is broken 2018-06-03 15:01:58 So... in typical open source fashion: I'd like to try my hand at fixing it :) 2018-06-03 15:02:02 I've found aports 2018-06-03 15:02:16 But its not at all clear to me how the RPI images are being built 2018-06-03 15:02:32 aports seems focused on building packages (which is cool) 2018-06-03 15:02:43 Could anyone give me a hint on how I build the RPI images? 2018-06-03 15:12:09 : see aports/scripts directory for rpi images are built 2018-06-03 15:12:42 I dont have rpi/rpi3 but many people reported that the image works out of the box 2018-06-03 15:13:26 tmh1999: I think its funniness with the RPI 3b+ (which is newer than the images) 2018-06-03 15:14:54 tmh1999: scripts/mkimage.sh ? 2018-06-03 15:15:19 that might be the cause if there's hardware change. you should find which addition modules you need and then modify https://git.alpinelinux.org/cgit/aports/tree/scripts/mkimg.arm.sh (and prob other .sh in the same dir) and re-run mkimage.sh 2018-06-03 15:15:56 yes mkimage.sh is the "main" script which will call different "profile" code. in your case, your profile is mkimg.arm.sh 2018-06-03 15:16:22 take a look in mkimg.base.sh too 2018-06-03 15:16:54 tmh1999: I appreciate the pointers :) 2018-06-03 15:17:18 : good luck, ping me anytime. Happy Alpine-ing! 2018-06-03 15:17:23 tmh1999: :) 2018-06-03 15:19:02 also make sure https://git.alpinelinux.org/cgit/aports/tree/main/linux-rpi fits rpi3+ needs or else recompile it, edwarnicke 2018-06-03 15:20:50 tmh1999: That just saved me a lot of grief :) Would have taken a while to figure that out :) 2018-06-03 15:33:20 tmh1999: As I'm doing this... I find myself putting together a Dockerfile... is that something you think would be useful to contribute to the community (I notice a lack of them in aports)? If so, where would be the appropriate place to contribute it? 2018-06-03 15:34:47 that would be one. another is creating pull request on github/alpinelinux/aports for your working changes. another is bugs.alpinelinux.org. another is editing the wiki page for rpi. 2018-06-03 15:35:38 wiki is free to be edited by anyone 2018-06-03 15:38:55 tmh1999: I'll definitely send a pull request for any fixes, was trying to get a sense for where to put Dockerfiles :) 2018-06-03 15:40:32 <_ikke_> edwarnicke: There is no good place for them 2018-06-03 15:40:35 your github repo with description would be nice, and ping here so people know and recommend for others 2018-06-03 15:40:45 cool :) 2018-06-03 16:23:59 Oof. GIMP 2.10.2 was a hassle, but here it is. https://github.com/alpinelinux/aports/pull/4427 2018-06-03 16:28:18 <_ikke_> azarus: \o/ 2018-06-03 16:47:26 how should I allow normal user to access /dev/net/tun ? Adding to netdev group won't work. 2018-06-03 17:13:11 Why not? 2018-06-03 17:13:26 What are the permissions 2018-06-03 17:14:18 tmh1999: I when I try to build "./scripts/mkimage.sh --arch armhf" I get the following error: 2018-06-03 17:14:23 https://www.irccloud.com/pastebin/fg0inDXS/ 2018-06-03 17:14:47 clandmeter: got it worked, another day another PEBKAC 2018-06-03 17:14:55 It looks like abuild is doing a chroot to build, and expects linux-firmware and linux-rpi to be present in the chroot 2018-06-03 17:15:02 And they aren't 2018-06-03 17:15:23 they are expected to be installed on your host 2018-06-03 17:15:52 I poked at it a bit, and realized linux-rpi only exists in the arm arch apk repos 2018-06-03 17:16:23 tmh1999: I tried installing them on my host, obviously that fails for x86_64 ( linux-rpi doesn't exist) 2018-06-03 17:16:30 hum. so you are building the image on your x86* machine ? I dont know if mkimage.sh scripts will work with cross-compiling 2018-06-03 17:16:31 tmh1999: So I spun up an armhfs container :) 2018-06-03 17:16:46 tmh1999: Yeah, I figured that might be the case 2018-06-03 17:16:59 yeah building in arm container will work 2018-06-03 17:17:00 tmh1999: Which is why I used the multiarch stuff for running multiarch docker 2018-06-03 17:17:05 +1 2018-06-03 17:17:10 tmh1999:Same error 2018-06-03 17:17:13 hum 2018-06-03 17:17:20 tmh1999: Even after I successfully installed those packages 2018-06-03 17:17:41 tmh1999: So its an arm container, with those packages successfully installed... still no dice 2018-06-03 17:17:50 adding 'set -x' to those aports/scripts and try to see more fine-grained output 2018-06-03 17:17:51 tmh1999: Thus my theory that perhaps they need to be installed in the chroot 2018-06-03 17:18:02 ACTION smacks forhead ;) 2018-06-03 17:18:10 Should have thought of that some time ago :) 2018-06-03 17:18:22 there's no change root there 2018-06-03 17:18:24 chroot 2018-06-03 17:18:46 the scripts just copy the kernel, modify initramfs with addition modules 2018-06-03 17:18:56 create the boot image with proper bootloader 2018-06-03 17:18:59 try 'set -x' 2018-06-03 17:19:18 did you try --profile ? 2018-06-03 17:19:52 also, cd to aports/scripts and run ./mkimage.sh (dont remember if they/it handle directory correctly) 2018-06-03 17:20:23 $ cd aports/scripts; $ ./mkimage.sh --arch armhf --profile i-dont-remember-which-profile-for-rpi 2018-06-03 17:21:16 I did at one point try --profile rpi 2018-06-03 17:21:35 ACTION put some energy into understanding the scripts... got far enough to know there are profiles and sections and such :) 2018-06-03 17:21:49 Ah... 2018-06-03 17:21:57 rpi2 ? 2018-06-03 17:22:03 I was running ./scripts/mkimage.sh 2018-06-03 17:23:09 tmh1999: As a side note... multiarch Docker for builds is amazing :) 2018-06-03 17:23:15 +1 2018-06-03 17:23:54 Docker layer caching isn't bad either ;) 2018-06-03 17:25:04 works now ? 2018-06-03 17:25:08 Nope 2018-06-03 17:25:15 One sec 2018-06-03 17:25:23 cd /root/git/aports/scripts && ./mkimage.sh --arch armhf 2018-06-03 17:25:25 Doesn't work 2018-06-03 17:25:38 what profile ? 2018-06-03 17:26:02 cd /root/git/aports/scripts && ./mkimage.sh --arch armhf --profile rpi 2018-06-03 17:26:10 bring this to #alpine-linux 2018-06-03 17:26:10 Note: there is no rpi2 profile (tried that too :) ) 2018-06-03 17:26:23 tmh1999: Sure, one moment 2018-06-03 19:51:08 yay, my gimp 2.10.2 builds on Travis 2018-06-03 19:51:11 :D 2018-06-03 22:08:27 if a makefile for a software package that i'm building for aports supports `make -j $(nproc)`, should i use it to speed up compiling or should i leave it as default `make`? 2018-06-03 22:09:26 <_ikke_> Fusl: Just leave it be, abuild already uses it 2018-06-03 22:09:39 k, ty 2018-06-03 22:09:52 <_ikke_> Fusl: check /etc/apk/abuild.conf 2018-06-03 22:10:28 <_ikke_> sorry, /etc/abuild.conf 2018-06-03 22:10:45 gotcha, that makes sense, thank you 2018-06-03 22:13:17 oh, one more question: if the upstream for a software uses `2016-07-R1` as version string, should i simply replace the dashes with dots and lowercase everything, like `2016.07.r1` 2018-06-03 22:13:49 (that was the entire question, forgot the question mark at the end) 2018-06-03 22:33:30 Fusl: there are some existed examples in the repo, check them out 2018-06-03 22:39:27 thanks tmh1999, looks like defining a separate _pkgver variable that substitues the pkgver variable to avoid having to define the version number twice 2018-06-03 23:52:47 does alpine use travis for continuous integration? 2018-06-03 23:53:00 yes 2018-06-04 04:08:31 clandmeter sir, what additional kernel modules that you built with the images at boot.a.o ? When you're back would you mind rebuild edge images at boot.a.o to have recent mkinitfs/initramfs-init changes. 2018-06-04 04:23:15 I'm building with aports/scripts and it looks like I'm missing some network driver/kernel modules for qemu network cards 2018-06-04 04:23:36 images at boot.a.o can detect network interface in qemu but mine can't 2018-06-04 04:25:09 looks like I'm missing af_packet.ko : https://git.alpinelinux.org/cgit/mkinitfs/tree/initramfs-init.in#n166 2018-06-04 04:28:22 tmh1999, scripts are in git.a.o 2018-06-04 04:29:11 clandmeter: what's the name ? 2018-06-04 04:29:15 ah 2018-06-04 04:29:23 I saw it before 2018-06-04 04:30:22 clandmeter: I saw it once like 'netboot' or something in git.a.o but it seems you moved it somewhere else as it's not visible anymore 2018-06-04 04:31:05 https://github.com/clandmeter/alpine-netboot 2018-06-04 04:31:29 https://github.com/alpinelinux/alpine-netboot 2018-06-04 04:31:37 not sure why its not visible on git.a.o 2018-06-04 04:32:47 I saw it once on git.a.o 2018-06-04 04:33:26 yes it was working before 2018-06-04 04:34:46 thanks 2018-06-04 04:48:02 yes 2018-06-04 04:51:35 I think at some point we may want to move boot.a.o content to like : dl-cdn.a.o/netboot or dl-cdn.a.o/boot 2018-06-04 05:14:07 10 years ago 2018-06-04 05:14:10 https://git.alpinelinux.org/cgit/aports/log/?qt=author&q=copa&ofs=29350 2018-06-04 05:14:41 https://git.alpinelinux.org/cgit/aports/log/?qt=author&q=landmeter&ofs=2750 2018-06-04 05:16:57 https://git.alpinelinux.org/cgit/aports/log/?qt=author&q=timo&ofs=2700 2018-06-04 05:18:14 2008-10-18, not quite 10 years ago, but very close 2018-06-04 05:18:36 :D 2018-06-04 05:25:32 I still remembered how paranoid I was when I sent the first few patches to the -devel list. So scared if I messed up git send-mail and the whole world could see it. And once it's sent, I can't delete the email. Now anyone can delete github PR/issues :P 2018-06-04 05:27:31 tmh1999, i think i need to fix boot.a.o when i get home. 2018-06-04 05:28:12 it currently uses the host mkinitfs-init instead of the target. 2018-06-04 05:28:41 clandmeter: +1 enjoy your vacation. I just spit-balling here as a habit ... 2018-06-04 05:29:21 I built my image and run alright with aports/scripts 2018-06-04 05:29:35 modify with some features 2018-06-04 05:30:47 ideally we would have netboot as a part of our mkimage scripts 2018-06-04 05:31:05 but we wouldnt have the latest kernel in the netboot images 2018-06-04 05:32:21 yes, exactly that's what I thought about alpine-netboot to be under mkimage scripts dir. But since I saw the LICENSE file I thought you would want it that way and didn't want to ask... 2018-06-04 05:32:55 but that's not critical, I think. we can do any time :) 2018-06-04 10:11:59 has anyone got any experience hooking alpine packages into something like jenkins to autobuild and test the APKs? 2018-06-04 10:18:27 <_ikke_> woodhouse: packages pushed to github are automatically built with travisci 2018-06-04 10:18:41 <_ikke_> woodhouse: And I'm currently investigating buildbot 2018-06-04 10:47:06 @_ikke_ thanks these are in my own repository though 2018-06-04 11:14:33 ncopa: I'm trying to upgrade xorg-server to 1.20.0 version which requires new xorgproto package 2018-06-04 11:15:14 xorgproto package is combination of all current xorg related *proto packages. 2018-06-04 11:15:39 individual *proto are now are obsolete 2018-06-04 11:17:11 ncopa: can we switch to xorgproto with just replaces="aproto bproto cproto .. .." ? 2018-06-04 11:17:35 I tried it but I got this: https://paste.ee/p/IGUZR 2018-06-04 11:23:38 cant we wait til after 3.8 release? 2018-06-04 11:24:14 you're right 2018-06-04 11:24:21 I'm just asking 2018-06-04 12:37:57 julia is hard, fails under both old and new openblas 2018-06-04 12:38:15 I should open an issue on their github repo 2018-06-04 12:38:58 I thought this was related but no work ; https://github.com/JuliaLang/julia/pull/26464 2018-06-04 14:07:36 looks like llvm3.7 on aarch64 suffers from jit 2018-06-04 14:11:24 same with llvm4 2018-06-04 15:35:27 anybody have any luck running systemd-based containers under our lxc? 2018-06-04 15:51:14 Microsoft is acquiring Github.. really? 2018-06-04 15:51:49 to undermine opensource community? 2018-06-04 15:59:30 embrace 2018-06-04 15:59:34 github already extended 2018-06-04 16:33:59 Github was never open source and you can choose other version control systems if you want 2018-06-04 16:42:17 last week I expressed my gut feeling here (or #alpine-linux, can't remember) about aversion to github, I'm sage :) 2018-06-04 16:43:20 someone told that the google will by github 2018-06-04 16:43:32 sorry for of-topic 2018-06-04 16:46:39 The person who told you Google was going to buy Github expressed a number of inane and off-topic comments 2018-06-04 16:46:57 there was no evidence then that Google was going to buy it and there certainly isn't any now. 2018-06-04 16:48:34 duncan^: I'm just joking little. earth will continue to move. 2018-06-04 16:48:36 that microsoft is buying github means i will be deleting my github account. i have expressed that to alpine's core team, and proposed that we create a new workflow to replace github + travis CI for reviews. 2018-06-04 16:48:53 lol 2018-06-04 16:48:57 what a silly overreaction 2018-06-04 16:49:21 Github wasn't open source in the first place 2018-06-04 16:49:27 Shiz it is not an overreaction based on what i saw when we discussed alpine in windows store 2018-06-04 16:49:44 microsoft's vision for alpine was an app you downloaded in windows store and that's it 2018-06-04 16:49:47 and you should know better than to think of microsoft as a single homogeneous entity 2018-06-04 16:49:51 a lot better 2018-06-04 16:50:03 not to mention github was both proprietary and controlled by a corp since its inception 2018-06-04 16:50:18 i do not consider them a single homogeneous entity, and i never supported alpine using github to begin with 2018-06-04 16:51:07 from that statement it sounds like you're applying experience from microsoft dept X to dept Y 2018-06-04 16:51:11 so sure sounds like it :p 2018-06-04 16:51:34 FTR, Github will be controlled by their AI+Cloud division 2018-06-04 16:51:39 i'm entirely expecting exactly nothing will change except they may push github enterprise on azure 2018-06-04 16:51:49 i'm applying experience from watching microsoft harass linux distributions for years with software patent litigation threats 2018-06-04 16:52:07 i'm applying experience from watching microsoft collect $$$$ on every single android phone sold because of software patents 2018-06-04 16:52:07 so you ARE treating them as a single homogeneous entity 2018-06-04 16:52:54 no, i am treating them as multiple entities which share lawyers and interests 2018-06-04 16:53:47 it isn't the guy running around screaming devops that bothers me 2018-06-04 16:53:54 it is the lawyer that stands behind that guy 2018-06-04 16:54:14 i, personally, do not want to use any platform that intersects those lawyers 2018-06-04 16:55:29 Shiz: relaz 2018-06-04 16:57:26 i was openminded and thought microsoft had changed until they sent a N-page non-disclosure agreement concerning their vision for alpine on WSL 2018-06-04 16:57:35 no fucking way 2018-06-04 16:58:05 if you want to not give a damn about software freedom, that's fine, but admit that you do so for convenience 2018-06-04 16:58:09 Well, self-hosting isn't an awful idea. For instance you already have CGIT. But you could host something like Gogs and incorporate the issue tracker into that 2018-06-04 16:58:36 duncan^ this is essentially what i propose: using something like gitea with drone, or something like pagure with drone 2018-06-04 16:59:38 Github does make it easy to contribute, though 2018-06-04 16:59:56 in my experience, people who do want to contribute will spend the 3 minutes to create an account 2018-06-04 17:01:24 when microsoft apologies for their abuse of software patents and EEE tactics (including an attempt to directly EEE alpine with their WSL moves), and satya nadella uses the phrase "free software" instead of "open source," i might be less skeptical 2018-06-04 17:01:35 well, I wanted to contribute but didn't because didn't want to create github account 2018-06-04 17:01:45 iirc the last conversation about this is not what we should choose as an implementation, but is there anyone is willing to do it. 2018-06-04 17:01:51 tmh1999 correct 2018-06-04 17:02:04 and what i am saying is 2018-06-04 17:02:09 we can wait no longer 2018-06-04 17:03:07 but seriously, when a company uses the phrase "we love open source" and not "we love free software" it is a datapoint 2018-06-04 17:03:28 so give the core team a working prototype (g9teaa, gogs, pagure whatever) and I guess ncopa will switch right away. he just doesn't have time. 2018-06-04 17:03:31 when a company does that while also litigating actively against other entities using free software, it also says a lot 2018-06-04 17:13:37 what is this drone that you refer to? 2018-06-04 17:14:53 zNVxxliww5gP CI platform like jenkins 2018-06-04 17:15:17 <_ikke_> I'm currently looking into a good CI system 2018-06-04 17:15:23 <_ikke_> for Alpine 2018-06-04 17:15:33 probably drone 2018-06-04 17:15:35 it looks nice 2018-06-04 17:15:42 <_ikke_> kaniini: Ok, will look into it 2018-06-04 17:15:42 i dont like the use of docker, but meh 2018-06-04 17:16:05 <_ikke_> I'm looking at buildbot at the moment, but it's a bit of a challenge to fit it for our usecase 2018-06-04 17:20:52 for fucks sake 2018-06-04 17:21:01 gitea doesn't support inline comments on reviews 2018-06-04 17:22:50 <_ikke_> :( 2018-06-04 17:23:08 why is it 2018-06-04 17:23:16 that every time i get sent back to gitlab 2018-06-04 17:23:39 <_ikke_> feature wise? 2018-06-04 17:23:51 yes 2018-06-04 17:23:59 gitlab literally is the only thing that has everything we need 2018-06-04 17:24:17 does that even run on alpine probably not 2018-06-04 17:24:34 <_ikke_> It's java I believe 2018-06-04 17:24:49 <_ikke_> But it eats memory 2018-06-04 17:24:56 <_ikke_> 8G min 2018-06-04 17:25:15 <_ikke_> gitlab has a nice CI system as well 2018-06-04 17:25:16 ruby 2018-06-04 17:25:19 <_ikke_> ah ok 2018-06-04 18:03:22 is it possible to run aarch64 on x86 qemu? I'm trying to setup one to test the community/bareos failure on aarch64. 2018-06-04 18:05:06 I mean, performance. 2018-06-04 18:05:19 my laptop kind of weak 2018-06-04 18:16:16 kaniini: +1 for gitlab https://www.youtube.com/watch?v=VYOXuOg9tQI 2018-06-04 18:16:59 HRio that video involves moving from github.com to gitlab.com; i want to move to a self-hosted solution so we do not have to deal with this shit ever again 2018-06-04 18:17:50 you can move to self hosted like that 2018-06-04 18:18:20 I have the import from github option (self-hosted) 2018-06-04 18:18:54 but 8GB of ram is a bit low for the Linux kernel repo (at least it used to be) 2018-06-04 18:19:35 We are mirroring the TI linux repo and 8GB was not enough when we started with that. We have 24GB RAM currently 2018-06-04 18:20:19 seems its the initial import that is a bit tough 2018-06-04 18:22:15 -1 for gitlab 2018-06-04 18:24:09 gitea is nice 2018-06-04 18:26:58 Shiz: I really like the CI/CD system and the gitlab-runners 2018-06-04 18:30:21 The issue tracker is quite nice as well (used Redmine before) 2018-06-04 18:34:33 Our gitlab runner VMs are running alpine with docker (the CI/CD jobs run in temporary containers) 2018-06-04 19:02:14 Gottox: Gitea is gogs. 2018-06-04 19:02:24 (or very similar at least) 2018-06-04 19:53:33 <_ikke_> Shiz: why -1? 2018-06-04 21:38:39 I am +1 for gitlab and adelie is running all of our stuff on a self-hosted gitlab, 2 GB RAM is all we need though 4 would probably be more comfortable 2018-06-04 21:42:56 for my thoughts on it, https://github.com/upend/IF_MS_BUYS_GITHUB_IMMA_OUT/issues/1#issuecomment-394301394 2018-06-04 21:43:06 github should have never become what it did 2018-06-04 21:43:17 and if it takes microsoft buying it for people to open their eyes, good 2018-06-04 21:52:34 i don't claim to have much sawy here but i would be delighted if alpine moved off github 2018-06-04 21:52:42 s/sawy/sway/ 2018-06-04 21:56:14 i would certainly feel a lot better donating as would many other i suspect 2018-06-05 00:57:29 Shiz, ncopa: https://github.com/JuliaLang/julia/issues/27431 2018-06-05 00:57:35 fyi 2018-06-05 00:58:18 there are some close cases in their issues tracker I'm digging 2018-06-05 00:58:38 it seems we're 2 packages away from doing rc1 2018-06-05 02:05:56 I have to say, awk is addictive. 2018-06-05 02:07:43 whoever put awk into setup-disk.in, thank you. You've shed the light of awk into my life. 2018-06-05 02:17:15 tmh1999: https://github.com/ssmccoy/awkbot 2018-06-05 02:17:58 mepholic: you mean a good resource to learn awk ? 2018-06-05 04:44:34 I'm booting Alpine in Google Cloud. It looks like I don't load correct network driver for their system : http://tpaste.us/B61k. Maybe I also need to add 'virtio_net' to modules= kernel cmdline even thought I added 'virtio'. 2018-06-05 05:09:19 not right. "ip: RTNETLINK answers: Network unreachable 2018-06-05 05:09:19 " 2018-06-05 06:00:48 Okay, using Debian image, I see that DHCP offers it /32 netmask, but it still works, don't know why. With Alpine I have to setup static IP to work. The above Network unreachable error is because of /32 mask. 2018-06-05 06:01:57 don't know if AWS and Gcloud have any differences but seeing the wiki page and other resources online, it looks so hard to setup Alpine on AWS : doing apkvol setup, etc. For Gcloud, I just setup a qemu raw disk and upload, that's it. 2018-06-05 06:02:07 creatin a wiki page soon 2018-06-05 06:07:46 our /etc/network/interfaces does not handle dns nameserver, right ? 2018-06-05 06:22:13 after a few second, or opening vim, or emacs, I got hang. Anyone knows what I might've screwed up ? 2018-06-05 06:24:06 opening htop also hang 2018-06-05 10:09:17 Does one have to be subscribed to the alpine-aports mailing list to submit patches? 2018-06-05 10:09:30 (have done it via github before) 2018-06-05 10:20:45 azarus: didn't see anything about subscribing to alpine-aports so I presume subscription isn't needed, or even possible, imo 2018-06-05 10:22:36 azarus: sorry, I'm blind. of course subscription is possible 2018-06-05 10:22:47 mps: ah, ok. Thanks :) 2018-06-05 10:23:02 I thought about something different 2018-06-05 10:23:50 patchwork.alpinelinux.org looks nice! 2018-06-05 10:23:52 but, you can try to post to the list and see what will happen 2018-06-05 10:25:57 btw, anyone looked at the pijul.com - new approach for colaborative development 2018-06-05 10:26:39 mostly patch based 2018-06-05 10:28:04 why's it better suited for aports than git? 2018-06-05 10:29:22 don't know and didn't tried, but they have some interesting ideas 2018-06-05 10:35:41 azarus: I regularly submit patches to alpine-aports, and I'm not subscribed to it :) 2018-06-05 10:36:06 skarnet: cool, thanks :) 2018-06-05 10:36:34 does one get an email if a patch is applied? 2018-06-05 10:38:50 yes, patchwork sends you e-mails. 2018-06-05 11:41:58 Great, i think i've done it right: https://patchwork.alpinelinux.org/patch/3987/ 2018-06-05 21:24:12 after a few second, or opening vim, or emacs, I got hang via ssh session. Anyone knows what I might've screwed up ? 2018-06-05 21:24:18 it's because of mtu size 2018-06-05 21:28:45 <_ikke_> d'oh 2018-06-05 21:28:53 <_ikke_> it's always mtu 2018-06-05 23:21:43 Hello all, curious as I am trying to use the bootstrap script in the aports scripts directory, is the abuild for busybox currently not working? I assume I might have left something out because it is complaining about a file tls.h. I see as part of busybox's src in the networking folder. 2018-06-05 23:52:14 brad_stemm: busybox on edge should work 2018-06-06 08:00:25 so what is the process again to get a package from testing to community (or a different repo like main)? just someone else than the original packager confirming it works? 2018-06-06 08:01:43 not just that. it needs to show that the maintainer really will maintain it, and it needs to work on all architectures (unless it has specific arch="..." instead of arch="all") 2018-06-06 08:13:54 ah damn ok, makes sense. so basically most packages won't move to the stable repos then I guess... how would a maintainer show it will really be maintained? and how would you test it on all architectures if you don't have access to architectures like s390x? 2018-06-06 08:20:45 I think s390x is the closest thing alpine has to a "Hopefully it works" arch 2018-06-06 08:20:59 only people with ssh to alpine builders really have s390x machines to test on 2018-06-06 08:22:35 who provides the s390x builders? IBM? 2018-06-06 08:22:59 I think so 2018-06-06 08:23:31 we looked in to getting a s390x builder for adelie, mainly so we could test all our changes for alpine on it 2018-06-06 08:23:37 it costs as much as a small house 2018-06-06 08:23:39 awilfox: you can always request for a lxc s390x. just ask the core team 2018-06-06 08:23:42 more than the biggest car 2018-06-06 08:23:49 (~50 K USD) 2018-06-06 08:24:08 awilfox: I doubt if anyone actually has a s390x thing in their garage 2018-06-06 08:24:17 awilfox (IRC): wait - have you looked at secondhand s390x? there's some video on youtube of a teenager who managed to find an old one 2018-06-06 08:24:32 hl: yes, but the ones that are not as much as a small house are too old to run musl 2018-06-06 08:24:36 hl: that's one in million 2018-06-06 08:24:46 some reason musl can't run on old s390x? 2018-06-06 08:24:48 hl: Connor Krukosky. He works at IBM now. 2018-06-06 08:24:50 asm 2018-06-06 08:25:01 hi everyone 2018-06-06 08:25:09 I think the generation of s390x it targets has some atomics instructions or such 2018-06-06 08:25:13 which older ones don't 2018-06-06 08:25:21 and so it can't guarantee correctness of pthreads without them 2018-06-06 08:25:41 awilfox: if you want to test Alpine s390x, please ask the core team. The core team will provide you. If you want to run Adelie s390x, I guess IBM LinuxONE Cloud people will be willing to help. Just give them a call/emal. 2018-06-06 08:25:51 re github. github has always been a "backup" solution, that has become popular. We don't depend on github and you are not and will never be required to have github account to be able to contribute 2018-06-06 08:25:54 yes musl s390x is more like modern s390x 2018-06-06 08:26:13 what year were they introduced? 2018-06-06 08:26:25 great question. let me look at it. I think 2006. 2018-06-06 08:26:32 2016, same around ppc64le 2018-06-06 08:27:02 github has provided a fairly easy way to contribute though and we have CI connected to it, but this is not something that we have a hard dependency on 2018-06-06 08:27:09 so it looks like you'd need roughly a z10 or newer 2018-06-06 08:28:21 z196 architecture 2018-06-06 08:29:03 Introduced 22 July 2010 2018-06-06 08:29:05 oh, that's 2010 according to wikipedia 2018-06-06 08:29:07 hl: tmh1999: ^ 2018-06-06 08:29:12 awilfox, hl: remember even if you get the hardware, you probably need IBM software (license fee) to run the hardware, then Linux will run on top of the software. 2018-06-06 08:29:26 tmh1999: oh, no, hl was asking when the z196 was introduced, not when added to alpine. 2018-06-06 08:29:56 that's a good point, too 2018-06-06 08:30:08 right. 2018-06-06 08:31:12 so if you need to run linux s390x just ask IBM people at IBM LinuxONE Cloud, they will talk. 2018-06-06 08:31:37 okay well, the z114, which is 2011, is £20k on ebay, yeah that's not going to work :P 2018-06-06 08:32:52 tmh1999: I totally forgot about the z/os thing 2018-06-06 08:32:55 where you need z/os to run linux inside 2018-06-06 08:33:07 or sommat like that 2018-06-06 08:33:31 yeah, it's z/VM hypervisor. 2018-06-06 08:52:35 148833, I believe you're using Matrix right? please join #alpine-devel:alpinelinux.org rather than #freenode_#alpine-devel:matrix.org 2018-06-06 08:55:04 awilfox: well s390x specifically aside, it's just quite hard for maintainers to test all the arches. I can test packages myself on x86_64, armhf and aarch64 with the pmbootstrap tool from postmarketOS, but any others will be hard. would 3 like that be enough? 2018-06-06 08:55:17 PureTryOut[m]: I'm not an official source 2018-06-06 08:55:26 ncopa is right there, and is an official source 2018-06-06 08:55:39 oh sorry 2018-06-06 08:55:46 it's okay :P 2018-06-06 08:56:34 well, ncopa then 😆 how many arches would I need to test to move a package from testing to community? and how would a maintainer proof he/she is willing to maintain the package? 2018-06-06 09:01:10 if it for sure runs on one or two arches, and builds on the other (supported) arches, and the package is verified, eg files are installed where they should not in like /usr/usr/something, or /usr/etc soemthing, and all the needed files are there (no missing init.d scripts) and the needed system users are created in pre-install, then i'm ok to move 2018-06-06 09:01:10 it to community 2018-06-06 09:01:28 normally only the maintainers word is enough 2018-06-06 09:01:59 if maintainer does not take responsability later, we may move it to unmaintained 2018-06-06 09:13:41 hrm -- i'd like to test if my APKBUILDs work on other arches, what arches are known to work with qemu? 2018-06-06 09:14:03 x86 and x86_64 for sure, but how about armhf and s390x? 2018-06-06 09:14:21 and ppc64le? 2018-06-06 09:15:07 ppc64le should work in qemu 2018-06-06 09:15:17 the only testing I do of it is in KVM on a ppc64 2018-06-06 09:15:37 since KVM uses qemu underneath, I see no reason it /shouldn't/ work 2018-06-06 09:15:59 awilfox: cool. I only have x86_64, ppc and armhf machines... 2018-06-06 09:16:11 well, qemu *can* use KVM, doesn't have to, ever 2018-06-06 09:16:56 what is the ppc machine? if it is a G5 or AmigaOne, then it should run LE in KVM 2018-06-06 09:17:10 (my ppc64le KVM machine is a G5) 2018-06-06 09:17:17 G4 2018-06-06 09:17:27 and really, really slow 2018-06-06 09:17:28 ah drat, one gen too old for 64-bit 2018-06-06 09:18:06 Could I see your qemu command line for ppc64le? :D 2018-06-06 09:19:14 it is just standard -hda diskimage -m 1024 2018-06-06 09:19:47 qemu-system-ppc? 2018-06-06 09:19:59 qemu-system-ppc64*? 2018-06-06 09:21:03 you need -M pseries and -cpu power8 2018-06-06 09:21:04 qemu can't use KVM when emulating PPC on x86, it's just plain qemu in that case 2018-06-06 09:21:11 pardis: exactly 2018-06-06 09:21:17 when you are doing it as a x86 2018-06-06 09:21:28 that should boot in LE 2018-06-06 09:21:33 thanks guys, will have a go at it later today 2018-06-06 09:21:36 rather, it should be capable of booting LE images 2018-06-06 09:21:50 note that really ppc64 and ppc64le is the same CPU, it's just a bit in a CPU register that controls endianness on ppc64 2018-06-06 09:21:55 pardis: well if cross-arch, then only qemu is used, right? 2018-06-06 09:22:07 the apple G5 and amiga machines are 'hardwired' to be BE in the firmware, but can still do LE in hypervisor mode 2018-06-06 09:22:19 (some apple 970 chips won't, and the kernel fakes it in that case) 2018-06-06 09:22:23 (but most ill) 2018-06-06 09:22:25 might be a good idea to document that in the wiki port aport devs, so they can test with qemu? 2018-06-06 09:22:30 will * 2018-06-06 09:22:51 s/wiki port/wiki so that/ 2018-06-06 09:23:00 I wouldn't really count on qemu for anything more than a smoketest 2018-06-06 09:23:02 argh, egnlish 2018-06-06 09:23:07 dammit 2018-06-06 09:23:29 for example, qemu-system-i386 (or whatever it is called now) has lots of bugs in crX code 2018-06-06 09:23:47 this let a kernel bug sneak in to linux, and a separate one to sneak into freebsd, because they were only testing 32-bit on qemu instead of real hw 2018-06-06 09:23:58 the linux one was a CVE I accidentally discovered 2018-06-06 09:24:08 hrm, you're right. that's why OpenBSD always builds and tests natively 2018-06-06 09:24:11 on real hw 2018-06-06 09:24:22 as another example, qemu-system-mips doesn't implement the FPU correctly, so some FPU-dependent tests may fail on it 2018-06-06 09:24:25 (if alpine gets mips port) 2018-06-06 09:25:45 i wonder if it's worth it to test my aports on other arches in qemu 2018-06-06 09:26:41 also, is it considered abuse to fetch from git://git.alpinelinux.org/aports every 15 minutes? 2018-06-06 09:27:07 n e ncopa 2018-06-06 09:27:28 i fixed tcsh in testing 2018-06-06 09:27:32 got it passing all tests 2018-06-06 09:27:41 i'd like to move it to community 2018-06-06 09:27:49 any chance in getting the PR merged tonight? 2018-06-06 09:28:27 ok so knowing the maintainers name, how do I find an email address then? 😛 2018-06-06 09:28:50 PureTryOut[m]: emails should be in every APKBUILD, shouldn't they? 2018-06-06 09:29:15 ah true 2018-06-06 09:29:16 I'm being dumb sorry 2018-06-06 09:57:48 azarus: you may be able to get notification via mqtt when git aports is updated. so you dont neet fetch every 15 mins. 2018-06-06 10:00:25 https://github.com/alpinelinux/aports/pull/4439/files 2018-06-06 10:00:33 ncopa: ^ :) have a C shell 2018-06-06 10:02:16 ncopa: that'd be cool, how would I go setting it up? 2018-06-06 10:14:05 Check mosquito client 2018-06-06 10:14:43 Subscribe to msg.a.o 2018-06-06 10:15:33 clandmeter: thanks. https://msg.alpinelinux.org/ seems to be a nginx landing page? 2018-06-06 10:15:58 It's not a web page 2018-06-06 10:16:03 It's a service 2018-06-06 10:16:27 OK. Found documentation for it, thanks 2018-06-06 10:17:01 If you want to run tasks you can check mqtt-exec 2018-06-06 10:17:32 That's how we do it 2018-06-06 10:19:27 what sort of messages gets published on a commit? 2018-06-06 10:19:28 is travis broken on package build tests? 2018-06-06 10:21:35 There is not much info about it. Just try it. 2018-06-06 10:26:26 Shiz: are you able to have a look at whats wrong with julia? 2018-06-06 10:26:40 its a blocker for 3.8.0_rc1 2018-06-06 10:35:33 if installing a service, should `rc-update add ` be added to the post-install hook, or should the user do this themselves? 2018-06-06 10:36:45 user should do this themselves 2018-06-06 10:36:57 ok 2018-06-06 10:37:05 i've perfected that PR 2018-06-06 10:37:16 moved the relevent comment into the patch itself 2018-06-06 10:37:19 ok thanks 2018-06-06 11:10:17 fcolista: can you look at building bareos with cmake? https://bugs.bareos.org/view.php?id=898 2018-06-06 11:10:26 it is a blocker for aarch64 as well 2018-06-06 11:15:14 ncopa, back now 2018-06-06 11:15:17 yes 2018-06-06 11:15:41 thanks 2018-06-06 11:15:56 i pushed a workaround, but i think its good to switch to cmake 2018-06-06 11:34:31 ncopa, cmake has been introduced with BareOS 18 2018-06-06 11:34:55 which has not be release yet 2018-06-06 11:35:31 " Fixed in Version => 18.1.2 " 2018-06-06 11:35:35 https://bugs.bareos.org/view.php?id=898 2018-06-06 11:36:28 ttps://bugs.bareos.org/changelog_page.php?version_id=65 2018-06-06 11:37:03 So I think that for now your fix is enough, and when 18 will be released, we will switch to cmake. 2018-06-06 11:37:08 What do you think? 2018-06-06 11:39:34 mepholic: about tcsh, did you enabled nls 2018-06-06 11:42:49 mepholic: https://bugs.alpinelinux.org/issues/8660 2018-06-06 11:46:58 fcolista: ok 2018-06-06 12:02:44 thx for the heads up! 2018-06-06 12:14:28 a package needs some folder pre-created. the Arch APKBUILD creates those in the `package()` function, but isn't it better to do it in a post-install hook so I can also give it the correct permissions (to the user made in the pre-install hook)? 2018-06-06 12:24:22 if you set it in the pkg funct it iwll copy the files to their location including the perms 2018-06-06 12:24:36 but I guess it depends on the setup Ill defer to the experts 2018-06-06 12:28:08 I'm by no means expert but on my limited experience, yes, place the mkdir in the post-install hook 2018-06-06 12:28:40 well right now (with the install in the package function) the directory is owned by root:root which is wrong 2018-06-06 12:28:57 TBB: ok thanks I'll do that then 2018-06-06 12:37:50 well, this is interesting. the directory now has the correct group owner, but the wrong user owner... how is that even possible? the chown command is correct 2018-06-06 12:51:31 ah never mind, the chown command was in fact *in*correct. `-r` vs `-R` lol 2018-06-06 12:59:10 ncopa: speaking of rc1, do you want to build boot media for s390x ? 2018-06-06 13:18:50 tmh1999: yes that would be nice. what kind of boot media makes most sense? .iso image? 2018-06-06 15:51:02 ncopa: besides my pr you just commented on, we also need this : https://github.com/alpinelinux/aports/pull/4100 2018-06-06 15:55:40 ncopa: and this : https://github.com/alpinelinux/alpine-conf/pull/16. Even though there's a bug in the comment. Even if users dont use ssh_key and ssh_pass, removing firstboot.initd from new system is eventually what we need to do 2018-06-06 16:02:52 I just looked at https://bugs.bareos.org/view.php?id=898, was it an issue on s390x ? bareos-17.2.4-r1 has been built long time ago. 2018-06-06 16:03:01 thought it was aarch64 2018-06-06 16:06:48 ncopa: also I have some patches for main/{audit, llvm5, tranmission, pllua} too https://github.com/alpinelinux/aports/pulls/tmh1999 2018-06-06 16:07:04 sorry more work for you 2018-06-06 17:22:55 wow looks like all 3.8 builders are done! 2018-06-06 17:22:58 finally 2018-06-06 17:34:10 \o/ 2018-06-06 17:35:17 yes, we only had bareos and julia holding back since last week. they are solved today ! \o/ 2018-06-06 18:25:59 \o/ 2018-06-06 19:26:28 <_ikke_> \o/ 2018-06-06 20:01:32 Whee! 2018-06-06 20:02:10 <_ikke_> so rc1 is about to happen? 2018-06-06 20:09:51 instead of making rc1 i spent time on a meaningless discussion whether it was a good idea to keep libressl for v3.8 or if we should switch back for openssl before we do v3.8 2018-06-06 20:09:58 sorry about that 2018-06-06 20:10:16 im tired now. maybe tomorrow 2018-06-06 20:10:29 <_ikke_> :( 2018-06-06 20:11:37 we're so close now, integrating/fixing/reverting patches to make openssl work now would take *quite* a while 2018-06-06 21:02:01 encfs-1.9.5 was a bigger change than expected, but I got it 2018-06-06 21:02:21 https://patchwork.alpinelinux.org/patch/3992/ 2018-06-06 21:03:11 (Should I've made separate commits for that, or is it OK like that?) 2018-06-06 22:07:01 mps: welp 2018-06-06 22:07:30 that DEFINITELY should have been noted in the APKBUILD 2018-06-06 22:52:47 mps: oh 2018-06-06 22:52:51 mps: you NEED nls? 2018-06-06 22:57:21 mepholic: yes, I filled bug report 2018-06-06 22:57:40 mps: sorry, took some deciphering for me to understand :P 2018-06-06 22:57:50 i thought that bug was justification for WHY nls was disabled 2018-06-06 22:58:10 but yes, my PR WILL re-enable NLS 2018-06-06 22:58:12 but looking in your PR looks like you already removed disable-nls line from APKBUILD 2018-06-06 22:58:26 i'm modifying it to make the bugtracker happy 2018-06-06 22:58:32 one moment 2018-06-06 22:58:37 ok 2018-06-06 23:00:04 bug report is at https://bugs.alpinelinux.org/issues/8660 2018-06-06 23:01:33 ok what 2018-06-06 23:01:40 i fucked up the url in that 2018-06-06 23:01:43 I built tcsh with disable-nls removed from APKBUILD and tcsh works without problem few months on the few machines and x86, x86_64, arm32 and arm64 2018-06-06 23:01:47 do not merge that yet ncopa 2018-06-06 23:01:49 >_< 2018-06-06 23:02:00 mps: don't worry, I understand 2018-06-06 23:03:54 mepholic: sorry if my wording in bug report are not clear, I'm not so good in English 2018-06-06 23:04:29 mps: understandable, don't worry about it :) 2018-06-06 23:04:34 we figured it out 2018-06-06 23:04:45 ok, tnx 2018-06-06 23:05:23 it is late here right now, I'm going to bed, good night :) 2018-06-06 23:08:49 HEY 2018-06-06 23:08:57 it's almost like travis is being helpful now! 2018-06-07 02:05:45 ncopa: i've fixed that pr btw: https://github.com/alpinelinux/aports/pull/4439 2018-06-07 02:13:07 azarus: why don't create github pr ? the maintainer/reviewer couldn't tell if the CI works with your patch. Somebody sent not-working patches to patchwork.a.o before and it caused some troubles. 2018-06-07 02:14:26 tmh1999: because github is non-free and corporate-centralised (and has been for years) 2018-06-07 02:14:56 alpine should set up something like jenkins with patchwork, instead of asking people to create an account on a non-free platform and give up personal info to a coproration 2018-06-07 02:15:00 corporation* 2018-06-07 02:15:29 awilfox: ... that's off the point at the moment. You/we have been doing github for the last 6-12 months, 1 patch to patchwork won't make sense... I agreed with you point on github though. 2018-06-07 02:15:59 that's because nobody ever responded to my mails when I sent patches to the list 2018-06-07 02:16:06 everyone knows Alpine need alternative to github, even the founder said so ealier this morning 2018-06-07 02:16:08 and that work was desperately needed 2018-06-07 02:17:05 everyone knows that but no one has time or capabilities to do so 2018-06-07 02:17:19 um 2018-06-07 02:17:22 at least some are doing/investigating it atm 2018-06-07 02:18:57 so please just stick with github instead of patchwork.a.o, till we can get rid of github. 2018-06-07 02:19:02 thanks 2018-06-07 02:19:34 tmh1999: that is not your call to make 2018-06-07 02:19:41 Shiz: of course 2018-06-07 02:19:41 I think contributors should be free to use whatever system they want as long as alpine can still use them, but... 2018-06-07 02:19:43 I'm just helping 2018-06-07 02:19:52 you're not making the impression of helping 2018-06-07 02:20:08 you're making the impression of "use this because i say so/or else" 2018-06-07 02:20:30 Shiz: If I did so, I sincerely apologize to you. 2018-06-07 02:20:53 don't apologize to me, but rather to the people you were talking to 2018-06-07 02:20:55 :P 2018-06-07 02:21:01 azarus is probably owed an apology more than Shiz, since you are saying the contribution was bad in some way because it wasn't on gh 2018-06-07 02:21:09 I, for one, would love to have something other than github to submit PR's 2018-06-07 02:21:21 I said this because last 1-2 week, 1 patch from patchwork.a.o came in and hit ncopa and jirutka so much headache 2018-06-07 02:21:28 i'd even be willing to work with the alpine-core team to set up and maintain such a thing 2018-06-07 02:21:38 Shiz: you're complaining, mepholic doesn't. 2018-06-07 02:22:02 tmh1999: can you keep the toxicity out please 2018-06-07 02:22:11 no need to point fingers at anyone, sheesh 2018-06-07 02:22:24 wow, relax. I'm just helping by giving advice. 2018-06-07 02:22:27 okay 2018-06-07 02:22:33 I apologize to everyone here 2018-06-07 02:22:59 Shiz, awilfox, mepholic. I sincerely apologize for what I just said. Please forgive me. 2018-06-07 02:23:06 you apologized 2 minutes ago 😒 2018-06-07 02:23:07 if alpine does need help setting up an alternative CI solution, feel free to poke me too, fi 2018-06-07 02:23:13 fyi * 2018-06-07 02:23:18 Yes my bad. I am sorry. 2018-06-07 02:23:24 I have set up jenkins in the past, and also have done gitlab ci 2018-06-07 02:23:34 it's fine tmh1999, you just came across as very aggro 2018-06-07 02:23:39 just don't do that please. 2018-06-07 02:23:40 will be happy to package or test stuff 2018-06-07 02:23:47 it's not healthy for the community at large 2018-06-07 02:24:07 mepholic: no no man, I am so relax and chill now. If I made it aggressive to you, I'm totally sorry. 2018-06-07 02:24:33 yeah I won't do that to you again. mepholic, Shiz, awilfox. 2018-06-07 02:25:35 tmh1999: plus, it looks really weird when someone without an @ begins dictating the direction of a project. have you talked to other core-team members about this? are they all in agreement? 2018-06-07 02:26:30 ... I said it. I didn't mean demanding at all. I just want to help. And I apologize, again. 2018-06-07 02:27:23 everyone just needs to take a few minutes away I think 2018-06-07 02:27:38 this whole github thing is _sort_ of an ideological problem, so i don't want anyone's feathers to get ruffled over it. but the fact of the matter, is that using an ML has distinct advantages over a closed source platform like github: https://begriffs.com/posts/2018-06-05-mailing-list-vs-github.html 2018-06-07 02:28:18 Github in mailing-list mode is great though :) 2018-06-07 02:31:41 github's a great code mirror if anything 2018-06-07 02:31:56 allows for easy discoverability 2018-06-07 02:33:07 misunderstandings happen 2018-06-07 02:33:09 :) no worries 2018-06-07 02:47:49 just wanna re-iterate: 2018-06-07 02:47:59 22:21:08 I, for one, would love to have something other than github to submit PR's 2018-06-07 02:48:08 22:21:28 i'd even be willing to work with the alpine-core team to set up and maintain such a thing 2018-06-07 02:48:18 22:23:07 if alpine does need help setting up an alternative CI solution, feel free to poke me too, fyi 2018-06-07 02:48:31 don't want it to get lost in the misunderstanding above 2018-06-07 02:48:33 yes I would be happy to package or test or such 2018-06-07 02:48:57 I would also be willing to spin up a temporary box for devs to play around with it before it is deployed 2018-06-07 02:49:04 so alpine knows exactly how it works before it is deployed 2018-06-07 02:49:06 if that would be useful 2018-06-07 02:49:28 we (Adélie) have spare capacity on one of our virthosts 2018-06-07 05:37:08 tmh1999[m]: awilfox: I don't mind sending patches to the list at all, I'd even go as far as to say that it's less hassle than GitHub. But I do agree that we need some kind of CI to test the patches sent to the list 2018-06-07 05:37:37 And I'd gladly help in any way to get CI to integrate with the mailing list 2018-06-07 05:39:05 tmh1999[m]: no apology to me needed, I understand the situation right now is not so great 2018-06-07 05:51:23 I just wanna point out that 3 people have offered to put time into Alpine infrastructure since it was mentioned that nobody has time. If the existing core team doesn't have enough time to dedicate to projects, maybe it would be a wise idea to enlist more help :) 2018-06-07 05:53:53 mepholic: but then again, let's not try the core team's trust. Trust is not to be asked for, but gained. 2018-06-07 05:54:27 "trust me!" the fact that trust is being asked for, makes the asker much less trustworthy. 2018-06-07 05:54:48 I'm not asking for anyone to trust me. I have a couple PR's into Alpine, and a bunch of work in Adelie that should speak for itself 2018-06-07 05:55:03 fair enough 2018-06-07 05:55:06 and I'm not saying ME ME ME ME! I'm saying, "someone" 2018-06-07 05:55:49 (also, might be good to get 3.8 out first before messing with infra?) 2018-06-07 05:56:10 I would also be willing to spin up a temporary box for devs to play around with it before it is deployed 2018-06-07 05:56:21 so alpine knows exactly how it works before it is deployed 2018-06-07 05:56:33 cool :) 2018-06-07 06:00:25 the only motive here is to make things better for everyone, knock some items off the core team's backlog, and give the community a better option for code/patch submission 2018-06-07 06:00:59 understood. Let's see what core thinks. 2018-06-07 07:05:37 awilfox: would be great if you could help figure out how to do CI without github 2018-06-07 07:06:21 I know rdutra has set up a jenkins vm on ppc64le which was supposed to plug into github 2018-06-07 07:06:33 there was som issues with the kernel when running the vm 2018-06-07 07:06:56 but right now my highest priority is to get v3.8 out 2018-06-07 07:12:50 ncopa: yeah understandable 2018-06-07 07:13:03 was trying to look in to maybe gitlab ci since it is separate from regular gitlab 2018-06-07 07:13:11 but it requires go and node 2018-06-07 07:13:12 <_ikke_> ncopa: I'm also working on something 2018-06-07 07:13:17 <_ikke_> (buildbot) 2018-06-07 07:13:20 go doesn't even work on my ppc64 2018-06-07 07:13:28 and node requires python2 2018-06-07 07:13:51 my next kneejerk is to look at tinderbox, but that might be overkill 2018-06-07 07:14:22 <_ikke_> ncopa: http://buildbot.alpin.pw:8010/#/ 2018-06-07 07:15:06 awilfox: seems like there are more ppl working on it. i think we need coordinate it a bit to avoid double work 2018-06-07 07:38:38 ncopa: not to pressure, but is there anything else you need me to do re: https://github.com/alpinelinux/aports/pull/4439 2018-06-07 07:38:54 tis blocking some of my efforts in adelie unfortunately 2018-06-07 07:43:26 mepholic: done. thanks! 2018-06-07 07:46:41 thank you ncopa, I really appreciate it :) 2018-06-07 07:50:21 could someone with some time review https://github.com/alpinelinux/aports/pull/4440 ? I'm wondering about something in there and would like the feedback 2018-06-07 07:59:53 Shiz: I had a look at julia today: http://tpaste.us/nqy9 and there i give up 2018-06-07 08:00:16 i made it use the bundled openblas ^^^ but tests still fails 2018-06-07 08:01:02 then i tried upgrade to julia 0.6.3 but openblas does not build 2018-06-07 08:01:18 i dont have more time to spend on it 2018-06-07 08:13:23 "9bbbf71 main/alpine-baselayout: sysctl security changes." seems to give me error messages on boot with linux-vanilla 2018-06-07 08:13:28 I'll get a log 2018-06-07 08:35:10 btw ncopa could I try to upstream this patch of yours? https://git.alpinelinux.org/cgit/aports/tree/main/consolekit2/0001-busybox-reboot-and-poweroff-support.patch?h=3.7-stable 2018-06-07 08:44:07 azarus: http://tpaste.us/ 2018-06-07 08:44:42 hum 2018-06-07 08:44:53 even with ipv6 enabled inkernel i get errors 2018-06-07 08:45:02 sysctl: error: 'net.ipv6.conf.all.secure_redirects' is an unknown key 2018-06-07 08:45:02 sysctl: error: 'net.ipv6.conf.all.accept_source-route' is an unknown key [ ok ] 2018-06-07 08:46:06 ncopa: exactly, just like me 2018-06-07 08:46:12 I had some more, I believe 2018-06-07 08:47:39 Can't reboot my machine right now, tough >_< 2018-06-07 09:26:03 hum... that is somewhat tricky to solve 2018-06-07 09:26:20 se cannot set the ipv6 sysctl keys unless the ipv6 module is loaded 2018-06-07 09:26:25 and we dont load it by default 2018-06-07 09:33:01 why is ipv6 not loaded by default o_O 2018-06-07 09:33:11 https://code.facebook.com/posts/635039943508824/how-ipv6-deployment-is-growing-in-u-s-and-other-countries/ 2018-06-07 09:33:27 over 50% of facebook traffic is over IPv6 2018-06-07 09:33:33 78% of mobile traffic 2018-06-07 09:33:47 IPv6 is very important, it should not be disabled unless you don't plan on using networking 2018-06-07 09:34:47 ^ 2018-06-07 09:35:00 disabling ipv6 by default is a bad default 2018-06-07 09:35:14 in a world that's experiencing ipv4 exhaustion 2018-06-07 09:35:19 please don't be part of the problem 2018-06-07 09:36:18 ipv6 might not be the solution that we deserve, but it's the one that we need right now 2018-06-07 09:36:46 disabling ipv6 by default? yeah, that makes no sense 2018-06-07 09:40:49 ncopa: i also want to point out that secure_redirects is set to true by default according to https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt 2018-06-07 09:40:59 so that sysctl command doesn't need to be run 2018-06-07 09:41:18 if it's being set to anything other than true by default, that's also a bad, and dangerous config 2018-06-07 09:42:20 accept_source_route also has sane defaults 2018-06-07 09:42:40 the solution here is to remove those lines and enable ipv6 by default 2018-06-07 09:43:23 https://git.alpinelinux.org/cgit/aports/commit/main/alpine-baselayout?id=27b5767a9ebe609e84659eed250365c0a9bbbf71 2018-06-07 09:43:28 this appears to be what we are talking about 2018-06-07 09:43:29 sysctl: error: 'net.ipv6.conf.all.secure_redirects' is an unknown key 2018-06-07 09:43:29 sysctl: error: 'net.ipv6.conf.all.accept_source-route' is an unknown key [ ok ] 2018-06-07 09:43:39 correct 2018-06-07 09:44:00 what known vulnerabilities? 2018-06-07 09:44:20 good question 2018-06-07 09:44:40 i tried adding ipv6 kernel module to /etc/modules: http://tpaste.us/X6oe 2018-06-07 09:44:50 i'm a little bit sketched out at that 2018-06-07 09:45:00 also 2018-06-07 09:45:01 but i still get the two errors above 2018-06-07 09:45:08 accept_source-route is wrong 2018-06-07 09:45:15 it's accept_source_route 2018-06-07 09:45:36 hold on 2018-06-07 09:45:38 which rfc1337 fix is implemented? 2018-06-07 09:46:01 f1 is just a feel-good measure 2018-06-07 09:46:19 f3 may not be backward-compatible with all/any tcp stacks 2018-06-07 09:47:45 where is the review for these changes archived? github, ml, somewhere else? 2018-06-07 09:48:02 i think it was sent to alpine-aports 2018-06-07 09:49:02 net.ipv6.conf.all.accept_source_route = 0 2018-06-07 09:49:05 in my kernel 2018-06-07 09:49:09 last one there re baselayout is 'remove avahi group' 2018-06-07 09:49:12 from 2015 2018-06-07 09:49:52 sorry. it was here: https://github.com/alpinelinux/aports/pull/4339 2018-06-07 09:50:21 also, I don't see secure_redirects implemented in my kernel 2018-06-07 09:50:35 it probably got removed because it's a dumb setting to have 2018-06-07 09:51:00 also, why disable magic-sysrq? 2018-06-07 09:51:03 if your network setup requires non-routers to send redirects, your network setup is wrong 2018-06-07 09:51:24 azarus: probably idiots worried about physical access 2018-06-07 09:51:37 that's a terrible thing to turn off 2018-06-07 09:51:47 sysrq+REISUB has saved me a couple of times 2018-06-07 09:51:50 after fixing the accept_source-route i only have the following error 2018-06-07 09:52:00 sysctl: error: 'net.ipv6.conf.all.secure_redirects' is an unknown key [ ok ] 2018-06-07 09:52:03 if someone has physical access you're already owned 2018-06-07 09:52:12 ncopa: that's not in my kernel, let me do some digging 2018-06-07 09:52:15 yeah i was a bit in doubt on the magic-sysrq 2018-06-07 09:52:48 magic-sysrq saved me all the time when i was a datacenter tech 2018-06-07 09:52:54 if the kernel panics, you can still use it 2018-06-07 09:53:01 and sync the disks safely 2018-06-07 09:53:03 ncopa: are secure_redirects valid in ipv6 2018-06-07 09:53:12 magic-sysrq saved me all the time when I still used Linux on client machines 2018-06-07 09:53:30 and yes, for when you need to get in the datacenter because things went haywire, it's invaluable 2018-06-07 09:54:07 the only place you should NOT use magic-sysrq is public access computers ^^" 2018-06-07 09:54:38 mps: apparently not 2018-06-07 09:55:09 there is accept_redirects 2018-06-07 09:55:34 ok. so i guess we revert the magic-sysrq change? i think it makes sense to do so 2018-06-07 09:56:25 yes, this is mostly security snake oil 2018-06-07 09:56:45 are there anyone who thinks magic-sysrq should be disabled by default? 2018-06-07 09:57:02 so, what introduce 'net.ipv6.conf.all.secure_redirects' in AL, i.e. which patch/package 2018-06-07 09:57:50 I believe Arch linux has sysrq disabled by default? 2018-06-07 09:57:53 dunno why tough 2018-06-07 09:58:48 mps: https://github.com/alpinelinux/aports/pull/4339 2018-06-07 09:58:54 i grepped the kernel sources 2018-06-07 09:59:03 magic-sysrq should definitely be enabled by default 2018-06-07 09:59:03 there is ipv4 secure_redirects 2018-06-07 09:59:11 but nothing for ipv6 2018-06-07 09:59:31 ncopa: yeah 2018-06-07 09:59:35 i just did the same 2018-06-07 09:59:52 and we load ipv6 kernel module by default? 2018-06-07 10:01:08 this PR is wrong, because there is no secure_redirects IPV6 key 2018-06-07 10:01:18 mps: im fixing it 2018-06-07 10:02:51 i wonder if it would make sense to move the ipv6 config to etc/sysctl.d/10-ipv6.conf 2018-06-07 10:03:04 and, yes, ipv6 is loaded by default 2018-06-07 10:03:23 ncopa: that makes sense 2018-06-07 10:03:51 and maybe even 10-ipv4.conf (or similar) name 2018-06-07 10:04:13 ncopa: if ipv6 isn't enabled by default, please, please fix that 2018-06-07 10:04:17 ncopa: thanks for the review! I made the changes, if you have some time again you could review again https://github.com/alpinelinux/aports/pull/4440 2018-06-07 10:04:54 now ipv4 sysctl conf keys are in /etc/sysctl.d/00-alpine.conf 2018-06-07 10:06:30 we should configure an ipv6 localhost in /etc/hosts too then i suppose 2018-06-07 10:06:34 ncopa: syncookies is also set to the default setting in that config 2018-06-07 10:07:53 ncopa: good idea, it is just few lines 2018-06-07 10:08:20 mps: fyi, tcsh is in community/ now, your bug report has been fixed 2018-06-07 10:08:29 it is also passing all tests 2018-06-07 10:08:52 :) 2018-06-07 10:10:00 mepholic: tnx, it passes working test on my four Alpine architectures (arm32, arm64, x86 and x86_64) for more then three months 2018-06-07 10:10:29 mps: it needed a patch to pass one of the tests, because it wasn't posix compliant 2018-06-07 10:10:37 it also needed !checkroot 2018-06-07 10:11:01 so unless you've changed the APKBUILD, it wasn't passing tests 2018-06-07 10:11:15 however, I can confirm that it does work, and the version you were running was fine 2018-06-07 10:11:24 yes, I've looked at your patch, looks good. Later today I will test new build on my boxes 2018-06-07 10:13:58 mepholic: rebuilt tcsh right now, and I see loot less warnings then with previous build 2018-06-07 10:14:44 but there are still two warns, will look later if they make problems 2018-06-07 10:15:33 the Error 1 at the bottom? 2018-06-07 10:15:48 don't worry about that, the makefile is set to ignore the exit code 2018-06-07 10:15:53 warning: "UTLINLEN" redefined 2018-06-07 10:15:58 i don't know what they were trying to do in that section 2018-06-07 10:16:12 and, warning: "UTHOSTLEN" redefined 2018-06-07 10:16:42 mps: warnings are generally just warnings. most software will emit warnings during build and run perfectly fine 2018-06-07 10:16:54 but, these warning existed before, also. And I didn't noticed any problem with them till now 2018-06-07 10:18:13 is this ok? http://tpaste.us/L6rW i enable ipv6 by default and add ipv6 address for localhost 2018-06-07 10:18:16 mepholic: yes, I know but we should be inclined to resolve even them 2018-06-07 10:18:48 mps: https://fossies.org/dox/tcsh-6.20.00/tc_8who_8c_source.html 2018-06-07 10:19:28 line 44 2018-06-07 10:19:40 the ipv6 stuff looks better thank you ncopa 2018-06-07 10:19:46 that actually broke our armv7 builder at one point 2018-06-07 10:19:59 it was failing some test because ::1 localhost wasn't in /etc/hosts 2018-06-07 10:21:22 ncopa: maybe ip6-localhost to escape 'conflicts' wth ipv4 localhost 2018-06-07 10:21:39 or 6localhost 2018-06-07 10:21:51 don't have right idea now 2018-06-07 10:22:28 what is the naming convention in other distro, maybe we should look to be unified with them 2018-06-07 10:23:51 mepholic: yes, I will look at the source and try to find why are these two redefined 2018-06-07 10:23:52 ok mps those warnings are happening because the system has HAVE_UTMPX_H in one of the header files included, but it's not using utmpx 2018-06-07 10:24:15 so it redefines those macros to be in line with utmp 2018-06-07 10:24:16 centos has: 127.0.0.1 localhost localhost.localdomain localhost4 localhost.localdomain4 2018-06-07 10:24:16 ah, thanks, you saved me some time :) 2018-06-07 10:24:32 and corresponding for ipv6, eg localhost6 2018-06-07 10:25:01 freebsd uses localhost and localhost.my.domain for both 127.0.0.1 and ::1 2018-06-07 10:25:04 Debian have: ::1 ip6-localhost ip6-loopback 2018-06-07 10:25:25 openbsd uses as i did in the pacth 2018-06-07 10:25:26 hmmm good catch mps 2018-06-07 10:25:29 > Utmpx and wtmpx are extensions to the original utmp and wtmp, originating from Sun Microsystems. Utmpx is specified in POSIX. The utmp, wtmp and btmp files were never a part of any official Unix standard, such as Single UNIX Specification, while utmpx and corresponding APIs are part of it. 2018-06-07 10:25:35 let me see 2018-06-07 10:25:47 again we have a lot of standards to chose from :D 2018-06-07 10:25:55 so basically, it seems that everybody does their own thing 2018-06-07 10:26:07 it's set in config.h 2018-06-07 10:26:18 mps: i actually want to enable that because i'd rather use the standard 2018-06-07 10:27:26 void linux uses: ::1 localhost.localdomain localhost ip6-localhost 2018-06-07 10:28:14 the ip6 stuff is rarely used these days 2018-06-07 10:28:24 and as mentioned, debian: 2018-06-07 10:28:27 127.0.0.1 localhost 2018-06-07 10:28:27 ::1 localhost ip6-localhost ip6-loopback 2018-06-07 10:28:30 that was really a workaround for when gai was buggy with AF_INET6 2018-06-07 10:29:21 so localhost localhost.localdomain for both ipv4 and ipv6 2018-06-07 10:29:24 newer Debian have: ::1 localhost ip6-localhost ip6-loopback 2018-06-07 10:29:36 no special prefix/suffix for ipv6 2018-06-07 10:30:12 + 127.0.0.1 localhost localhost.localdomain 2018-06-07 10:30:12 + ::1 localhost localhost.localdomain 2018-06-07 10:30:16 i suggest that ^^^ 2018-06-07 10:30:20 so in Debian the localhost is same for ipv4 and ipv4 2018-06-07 10:30:30 spoke too soon mps, it's using some sort of logic to determine whether or not to use UTMPX or UTMP 2018-06-07 10:30:36 either way, it's not a major issue 2018-06-07 10:30:43 and we add ip6-localhost or localhost6 if something breaks 2018-06-07 10:30:50 or really an issue at all, the code is working as designed 2018-06-07 10:31:31 ncopa: +1 re hosts 2018-06-07 10:31:43 mepholic: yes it works, I just noted these two warning to have them in mind if something will not work as should 2018-06-07 10:32:34 mps: utmpx is just extensions to utmp, the place where you'd want to look for problems is in the 'who' builtin in tcsh 2018-06-07 10:32:45 but I suspect everything will be fine 2018-06-07 10:33:19 mepholic: and musl doesn't support utmp if I'm not wrong 2018-06-07 10:33:28 i think you're correct 2018-06-07 10:33:42 $ who 2018-06-07 10:33:49 MY WHO BUILTIN IS BROKE 2018-06-07 10:33:53 WAAAAAAAAAAAH 2018-06-07 10:33:58 actually 2018-06-07 10:34:10 that's the actual who binary, not a builtin 2018-06-07 10:34:13 mepholic: so something which doesn't work probably would not made problems 2018-06-07 10:34:19 :) 2018-06-07 10:34:32 ACTION shakes fist at dalias 2018-06-07 10:34:35 or someone 2018-06-07 10:34:40 idk who that one's on :P 2018-06-07 10:34:48 entirely dalias 2018-06-07 10:34:51 he thinks utmp is 'stupid' 2018-06-07 10:34:55 wat 2018-06-07 10:34:57 it isn't, but it is his thought 2018-06-07 10:35:09 anyway that's why skarnet made utmps 2018-06-07 10:35:22 is it utmpx compliant? 2018-06-07 10:35:24 :^) 2018-06-07 10:35:47 cause that's a posix option! 2018-06-07 10:35:55 ncopa: localhost looks quite fine for both ipv4 and ipv6, but it would be nice to hear what other people thinks about naming it 2018-06-07 10:40:31 mepholic: it only does utmpx 2018-06-07 10:40:37 it doesn't do the non-standard utmp 2018-06-07 10:41:06 :D 2018-06-07 10:47:53 of course it is utmpx compliant 2018-06-07 10:47:55 what do you think :P 2018-06-07 10:49:55 there are a few GNU extensions (logwtmp and such) 2018-06-07 10:50:02 but it's mostly the POSIX thing 2018-06-07 10:51:39 do we have skarnet's utmps in alpine? 2018-06-07 10:51:58 looks like not 2018-06-07 10:52:01 sounds useful 2018-06-07 10:55:25 I'll package it. 2018-06-07 10:55:45 it was essentially waiting for more testing before I make an official release but... 2018-06-07 10:55:59 ... it's not like anyone's doing Q&A these days so 2018-06-07 10:56:06 the way it is going to be tested is being shoved into coreutils in adelie 2018-06-07 10:56:12 the quicker an APKBUILD exists, the quicker it is tested 2018-06-07 10:56:14 :p 2018-06-07 10:56:18 exactly :D 2018-06-07 10:56:30 probably in alpine too 2018-06-07 10:56:39 coreutils and openssh 2018-06-07 10:56:50 i find the `who` command useful 2018-06-07 10:57:22 as do most of us 2018-06-07 11:02:38 yeah 2018-06-07 11:23:14 ncopa: did you notice like 182+ of that sysctl PR? 2018-06-07 11:23:36 + # Users should not be able to create soft or hard links to files 2018-06-07 11:23:38 + # which they do not own. This mitigates several privilege 2018-06-07 11:23:40 + # escalation vulnerabilitie.s 2018-06-07 11:23:47 that's probably going to break some people 2018-06-07 11:23:58 it doesn't seem to do what that description says on my box 2018-06-07 11:24:22 suse docs state similar, I may be misunderstanding though. 2018-06-07 12:12:31 The entire sysctl PR seems suspect... IMO the bar should be pretty high for "I feel strongly that the Linux kernel has wrong defaults for this setting that we should override for all AL users out of the box, for reason X" 2018-06-07 12:12:42 where 'X' is unclear for most of the lines 2018-06-07 12:13:23 and the multiple errors in the PR discussed above reduce credibility that the original author is an expert on those settings 2018-06-07 12:14:49 would anybody be opposed to reverting the entire commit and then selectively adding in important changes if needed? 2018-06-07 12:37:17 tstearns: agree with your observation about that PR 2018-06-07 13:24:37 ncopa: I'm not actually sure how setting the owner to a directory from the APKBUILD would work. doing it like you said right now, and it just complains the user doesn't exist. 2018-06-07 13:30:14 ooh never mind I completely missed a part of your comment, got it 😄 2018-06-07 13:34:02 clean-slate proposal for the sysctl controversy: https://github.com/alpinelinux/aports/pull/4447 2018-06-07 14:15:34 tstearns: +1 2018-06-07 14:15:47 I'm shocked that it got merged in the first place... 2018-06-07 14:51:29 "shocked" 2018-06-07 14:51:57 mepholic i support the FS sysctl changes 2018-06-07 14:52:04 i have more shocking news 2018-06-07 14:52:04 mepholic they are the ones i want to keep 2018-06-07 14:52:15 i just pushed 3.8.0 rc1 2018-06-07 14:52:52 <_ikke_> \o/ 2018-06-07 14:52:52 kaniini: 2 of them were completely bogus, many of the others were defaults 2018-06-07 14:53:09 mepholic the fs.* ones are not bogus, i run them in production 2018-06-07 14:53:36 thats unexpected behavior for some people even if it makes sense 2018-06-07 14:53:45 Adran here is an idea then, they can turn it off 2018-06-07 14:53:49 but does it do more then -hardened? 2018-06-07 14:53:53 no 2018-06-07 14:54:05 fair enough, kaniini 2018-06-07 14:54:06 so hardened already prevented that? 2018-06-07 14:54:47 anyways, I'm not trying to talk shit, but some of those options would have been trivial to test without even merging 2018-06-07 14:54:51 Adran yes 2018-06-07 14:54:52 if thats the case then, it seems to make sense to keep it in with some comments on what it does and these were helpfully enabled 2018-06-07 14:55:59 Adran: upon further inspection, it seems that the behavior as documented in the comment isn't exactly what it does 2018-06-07 14:56:05 re: the fs. settings 2018-06-07 14:56:10 ok here's the bottom line 2018-06-07 14:56:12 shut up about it 2018-06-07 14:56:12 oh, what does it do? 2018-06-07 14:56:17 thanks 2018-06-07 14:56:56 mepholic: i'm curious, could i pm you and chat there 2018-06-07 14:57:27 I didn't fully dig into it, but I tested a case that I figured would break given the comment, and it didn't 2018-06-07 14:57:44 ie. ln -s /etc/passwd into my home dir with both of those options enabled 2018-06-07 14:58:04 put passwd is readable 2018-06-07 14:58:41 ah i see 2018-06-07 15:00:15 mepholic: strange is that the invalid sysctl keys/values proposed, what speaks about quality of that proposal 2018-06-07 15:02:35 ok 2018-06-07 15:02:39 that's great and all 2018-06-07 15:02:43 it will be fixed 2018-06-07 15:02:56 i am personally taking time right now to fix it 2018-06-07 15:03:06 thank you kaniini, I appreciate it 2018-06-07 15:03:07 even though i have a million other things to do 2018-06-07 15:05:07 i already fixed the clearly broken stuff 2018-06-07 15:05:39 oh, well, then there you go 2018-06-07 15:05:59 everyone whines about stupid shit and then wonders why i spend my time contributing to places where people don't whine about stupid shit 2018-06-07 15:12:17 hum... s390x and ppc64le didnt automatically upload the releases 2018-06-07 15:35:26 to the extent that adelie-affiliated contributors have been toxic in this space, I apologize. if I had known this was how it was going to go, the project wouldn't have ever happened. 2018-06-07 15:56:30 kaniini: you dont need to apologize or take responsibility for other peoples bad behavior 2018-06-07 15:56:47 it's not for them, it is for me 2018-06-07 16:02:06 <_ikke_> My observation is that alpine attracts opinionated people, and not always the same opinion 2018-06-07 16:11:38 it's called *diversity* 2018-06-07 16:11:39 :P 2018-06-07 16:15:05 yay 3.8.0 RC1 2018-06-07 16:15:14 thanks for all who's worked on it 2018-06-07 16:43:17 ncopa: utmps released and packaged for Alpine. Obviously I don't expect it to ship in 3.8, but after 3.8 let's work on it? 2018-06-07 16:43:47 one small problem that I had is that /usr/include/utmpx.h is owned by musl-dev 2018-06-07 16:44:08 so I removed my own /usr/include/utmpx.h from utmps-dev, the switch will need to be made synchronously 2018-06-07 16:44:54 but as is, if you replace #include with #include then it can be used to test building packages that use utmpx functionality 2018-06-07 16:46:22 to build stuff against utmps, linking needs -lutmps -lskarnet and normally that's it 2018-06-07 16:46:57 stuff should *build* np, now I'd like to check if it *works* 2018-06-07 16:47:37 anyway, mail sent, it's all on patchwork 2018-06-07 16:52:46 ncopa: The s390x.iso won't work. The {kernel + initramfs + modloop} are used instead of the iso. 2018-06-07 16:54:17 I was trying to write a wiki page explaining the process + the use of parmfile. But was not able to login the wiki yesterday. 2018-06-07 16:55:33 ncopa: This is what Debian release dir looks like : http://ftp.us.debian.org/debian/dists/stable/main/installer-s390x/current/images/generic/ 2018-06-07 17:03:11 ncopa: if you don' want to add the content of the parmfile to the release directory with the other 3 files/images, then I will explain it in the wiki, which will probably be cleaner. 2018-06-07 17:03:36 scripts/mkimg.base.sh still needs the elif to copy the 3 images though. 2018-06-07 18:03:41 <^7heo> Hi. 2018-06-07 18:04:04 <^7heo> Was there ever a packer apk? 2018-06-07 18:04:33 <^7heo> I have 0.10.2-r0 in my lib/apk/db/installed but I can't remember if I built it myself or if I apk added it. 2018-06-07 18:05:07 <^7heo> jirutka: ping 2018-06-07 18:06:23 I found https://github.com/alpinelinux/aports/pull/328 2018-06-07 18:06:32 it's your PR seemingly? 2018-06-07 18:07:21 there was nothing in Git commit history about this package, so I assume that it did not get merged. 2018-06-07 18:08:38 <^7heo> duncan^: ah so it never got merged? 2018-06-07 18:08:50 It looks like you abandoned the PR 2018-06-07 18:09:03 <^7heo> Yeah that's very likely. 2018-06-07 18:09:19 <^7heo> Thanks a bunch for finding that again :] 2018-06-07 18:11:41 <^7heo> I guess I could reopen it if someone candidates for maintaining it and maintaining the https://github.com/UpCloudLtd/upcloud-packer APKBUILD I made then too. 2018-06-07 18:13:16 <^7heo> Anyway I'll stay here a little in case someone is okay to take over maintaining it. 2018-06-07 18:13:27 <^7heo> Otherwise I'll build it for myself and leave it at this. 2018-06-07 18:13:31 I suspect that if nobody does, the onus is on the person submitting it 2018-06-07 18:14:03 <^7heo> That's why I ask if it's interesting someone; because I surely don't want that responsability. 2018-06-07 18:14:19 <^7heo> I don't even know if I still have packages to me, but I probably won't find the time to maintain them. 2018-06-07 18:22:16 Is there a list of well supported armhf boards? 2018-06-07 18:24:44 ah, found it 2018-06-07 18:27:00 <^7heo> oh damn I have some =/ 2018-06-07 18:27:38 <^7heo> ScrumpyJack: thanks for upgrading gogs. 2018-06-07 18:28:22 fabled: have you had any experiences with the Armada 388 with Alpine? 2018-06-07 18:28:30 <^7heo> I'm pretty sure your commit has the same problems when upgrading it as mine had, but at least you made it move. 2018-06-07 18:33:35 <^7heo> azarus: thanks for updating redshift 2018-06-07 18:33:58 ^7heo: you're welcome :) 2018-06-07 18:34:08 <^7heo> weird thing is that it's still flagged as outdated... 2018-06-07 18:34:37 i only updated it recently, prolly just needs some time to refresh 2018-06-07 18:34:45 <^7heo> "recently" 2018-06-07 18:34:47 <^7heo> ™ 2018-06-07 18:35:17 <^7heo> git says last month... 2018-06-07 18:35:28 https://code.azarus.ch/aports/commit/?id=84635dc60f64fbda51524070006d13639ffae775 2018-06-07 18:35:36 <^7heo> ooh ncopa lagged. 2018-06-07 18:35:36 Commited today, by ncopa 2018-06-07 18:35:40 <^7heo> yeah yeah nevermind. 2018-06-07 18:35:47 <^7heo> that explains it. 2018-06-07 18:36:27 <^7heo> azarus: are you interested in maintaining packer and its upcloud related plugin? 2018-06-07 18:36:35 what even is packer? :P 2018-06-07 18:36:46 <^7heo> http://hashicorp.io/packer 2018-06-07 18:37:05 <^7heo> (don't blame me if this gives a 404 or else, I just groked it) 2018-06-07 18:37:17 yup, site stays white for me 2018-06-07 18:37:39 <^7heo> damn. 2018-06-07 18:38:03 <^7heo> oh dot com. 2018-06-07 18:38:09 this is weird: some weird godaddy.com stuff 2018-06-07 18:38:29 <^7heo> https://www.packer.io/ 2018-06-07 18:38:39 <^7heo> that's where I got the .io from. 2018-06-07 18:38:51 ah, okay, never heard of it before. 2018-06-07 18:39:17 I'm probably not the guy for it, terribly sorry :< 2018-06-07 18:39:25 <^7heo> it's ok 2018-06-07 18:39:47 <^7heo> I just wish I would find someone ;) 2018-06-07 18:40:56 <^7heo> okay, time to go home. 2018-06-07 18:40:57 <^7heo> laters. 2018-06-07 19:16:28 Guys, any news on updating Chromium with 3.8? 2018-06-07 19:20:08 terra: i think ncopa gave it a try but had some issues. 2018-06-07 19:30:10 clandmeter: void-linux seems done it.But I have no idea what is the real cause about Alpine.Probably related with new version of clang. 2018-06-07 19:30:31 yes void has it. 2018-06-07 19:30:43 does it run properly? 2018-06-07 19:31:07 I just checked at git 2018-06-07 19:31:24 you could ask Gottox 2018-06-07 19:31:29 i think he packaged it. 2018-06-07 19:32:35 I tested when it was 65 (now 66). It was running just fine. 2018-06-07 19:33:52 I hope we could make it because it brings video hardware acceleration with 65 and onwards. 2018-06-07 19:34:34 maybe ncopa can share his work and somebody can look at it. 2018-06-07 19:34:52 not sure he has time himself, although i do think he used it. 2018-06-07 19:38:21 if it wasn't such a bulky package I could try for myself but I don't have such a powerful machine to compile. 2018-06-07 19:57:28 clandmeter: duncaen is our chromium guy. 2018-06-07 19:58:30 ah sorry, i mixed nicknames :) 2018-06-07 20:00:55 but I remember a commit mentioning chromium and clang. 2018-06-07 20:01:31 https://github.com/voidlinux/void-packages/commit/306d54f76870c753cc022f4889af1512286bfb20 2018-06-07 20:01:39 terra: i got chromium to build, but it does not run 2018-06-07 20:01:49 i have looked and used the patches from void 2018-06-07 20:02:08 and i cannot figure out what goes wrong 2018-06-07 20:02:16 i get "aw snap" error 2018-06-07 20:04:48 ncopa: does it run without sandbox? 2018-06-07 20:06:58 terra i can give you an lxc on my quad e7 box if it helps? 2018-06-07 20:07:27 azarus, no, no experience with armada 2018-06-07 20:08:29 Kinda want to try to port Alpine to a device that has an armada SOC 2018-06-07 20:08:39 it just works 2018-06-07 20:08:45 that's what the scaleway arm servers are 2018-06-07 20:09:18 This is what I'm looking to run: https://kobol.io/helios4/ 2018-06-07 20:09:30 a rather cool ARM-based NAS 2018-06-07 20:09:43 kaniini: Thanks. But it seems the issue is beyond me according to ncopa's answer. 2018-06-07 20:09:56 <^7heo> ncopa, fabled: would you take over packer if I add it? 2018-06-07 20:11:47 clandmeter: no 2018-06-07 20:12:41 ^7heo: packer? 2018-06-07 20:12:53 <^7heo> packer.io 2018-06-07 20:13:04 <^7heo> seems like something alpine could use 2018-06-07 20:13:13 that NAS has its own dtb file: https://github.com/helios-4/linux-marvell/blob/linux-marvell-4.4/arch/arm/boot/dts/armada-388-helios4.dts 2018-06-07 20:13:14 <^7heo> it's from hashicorp 2018-06-07 20:13:27 <^7heo> like terraform and consul and cie 2018-06-07 20:14:13 send a patch wihtout maintainer set 2018-06-07 20:14:18 and lets see what happens 2018-06-07 20:14:28 ncopa: did you try with clean chromium profile? 2018-06-07 20:14:35 terra: yes 2018-06-07 20:14:51 i suspect its a 3rd party lib 2018-06-07 20:14:59 for example freetype 2018-06-07 20:15:02 <^7heo> ncopa: ok :) 2018-06-07 20:15:25 ^7heo: but right now my prio is to get v3.8 out, so maybe wait with post it til after v3.8 is out 2018-06-07 20:15:49 <^7heo> ok 2018-06-07 20:15:51 ncopa: void and alpine's freetype profiles differ...I'm just thinking. 2018-06-07 20:20:38 terra: thats what i saw 2018-06-07 20:21:01 maybe strace gives some clue 2018-06-07 20:21:27 possibly, i have not had time to look at it this week 2018-06-07 20:21:36 im currently using firefox ... 2018-06-07 20:21:46 me too :) 2018-06-07 20:26:01 Because during testing void's chromium, I made my chromium profile useless for 64. 2018-06-07 20:49:13 stracing chromium/firefox works but you have to go through many files 2018-06-07 20:49:38 the sandbox stuff makes it harder 2018-06-08 01:45:02 ncopa: updated https://wiki.alpinelinux.org/wiki/S390x, and https://github.com/alpinelinux/aports/pull/4100 2018-06-08 06:42:01 tmh1999: nice work with the wiki article! 2018-06-08 06:42:27 and i finally understood what the pr 4100 was about 2018-06-08 06:42:42 ncopa: thanks. Hopefully we can create the boot media today 2018-06-08 06:42:55 i think we may need a "netboot" target for the other arches too 2018-06-08 06:43:02 yeah I've must told you somewhere and I forgot to remind you again. 2018-06-08 06:43:03 agree 2018-06-08 06:43:12 so im not sure how to do it 2018-06-08 06:43:12 clandmeter is working hard on it 2018-06-08 06:43:24 we should also include version number there 2018-06-08 06:43:30 im thinking 2018-06-08 06:43:37 right ... 2018-06-08 06:43:54 the mkimage.sh reads those profile files and generate different kind of images 2018-06-08 06:44:10 iso, tarball, minirootfs 2018-06-08 06:44:45 morning 2018-06-08 06:44:47 the output_format 2018-06-08 06:44:53 morning clandmeter 2018-06-08 06:45:06 i was thinking, what if we have an output_format="netboot" 2018-06-08 06:45:40 and it creates a directory boot-$version/ 2018-06-08 06:45:52 where vmlinux initramfs and modloop is stored 2018-06-08 06:46:40 it should also include the "net" feature in the initramfs 2018-06-08 06:46:48 so ethernet drivers are included there 2018-06-08 06:46:57 the idea with current netboot is that we have current kernel not release kernel. 2018-06-08 06:47:28 ncopa: The thing with iso is, I'm not prepared to do the .iso thing atm. It requires me to read some more. Agree on the netboot output format though. 2018-06-08 06:47:34 but i have nothing against a working netboot in release dirs. 2018-06-08 06:47:42 +1 2018-06-08 06:48:00 clandmeter: i was thinking of doing netboot releases 2018-06-08 06:48:09 so you could netboot 3.8.0 2018-06-08 06:48:12 3.8.1 2018-06-08 06:48:12 etc 2018-06-08 06:48:20 yes it makes sense 2018-06-08 06:48:30 its how all others do it i believe. 2018-06-08 06:49:09 yeah at least debian, ubuntu, fedora, and the BSDs 2018-06-08 06:49:19 im currently looking into rpi kernel. ncopa do you think we can still include it in 3.8? 2018-06-08 06:49:34 debian's pre-made thingy was how I managed to smoketest sparcs back in the day 2018-06-08 06:50:08 clandmeter: yes. we need update rpi kernel before 3.8.0 release 2018-06-08 06:50:32 i think i have it kind of working, need to clean it up and ill send you a patch. 2018-06-08 06:50:37 good 2018-06-08 06:50:38 its using upstream config now. 2018-06-08 06:50:45 with changes to make it actually compile. 2018-06-08 06:50:53 so no more local config. 2018-06-08 06:51:07 too fast too furious 2018-06-08 06:51:26 going to build aarch64 now and see if it builds. 2018-06-08 06:51:29 tmh1999: suse has a isozipl tool, which can make an isohybrid bootable on z 2018-06-08 06:51:50 i looked at it but it may need some tweaking 2018-06-08 06:52:05 it tries to list content of iso using isoinfo 2018-06-08 06:52:09 ncopa: they use iso to boot on LPAR, not z/VM + KVM (What we are doing). We don't have LPAR infra. I mentioned this in the top of the wiki page. 2018-06-08 06:52:10 which we dont have 2018-06-08 06:52:19 aha 2018-06-08 06:52:20 ok 2018-06-08 06:52:47 so it does not make sense to build .iso for s390x for us 2018-06-08 06:52:52 I wanted to do LPAR but it may need me to have hardware access, which I hope when I have a job I would be able to. 2018-06-08 06:52:57 for now, yes 2018-06-08 06:53:05 hopefully after Oct. Or 3.9. 2018-06-08 06:53:12 yes 2018-06-08 06:53:25 ok, so we only need this netboot thing for s390x 2018-06-08 06:53:29 and minirootfs 2018-06-08 06:53:31 +1 2018-06-08 06:54:27 we need fix the iso image volume id too 2018-06-08 06:54:30 its too long 2018-06-08 06:54:54 "alpine-$PROFILE $RELEASE $ARCH" 2018-06-08 06:55:15 we need to shorten it 2018-06-08 06:55:41 i think we could have a short version of profile 2018-06-08 06:55:50 standard -> std 2018-06-08 06:55:55 extended -> ext 2018-06-08 06:56:05 clandmeter: I think we can merge alpine-netboot into current aports/scripts, which you also expressed earlier that it should be. In fact I used aports/scripts to create netboot image for x86. 2018-06-08 06:56:27 Just add "net" to initfs feature 2018-06-08 06:57:12 std sounds nice 2018-06-08 06:57:52 aw alpine-netboot involves ipxe... 2018-06-08 07:04:33 or do we simply drop the profile name from iso image volume id? 2018-06-08 07:22:21 clandmeter, ncopa: re netboot profile, it doesn't seem to be that hard doesn't it ? just add new profile with correct initramfs features. 2018-06-08 07:24:41 yes 2018-06-08 07:24:50 im working on it 2018-06-08 07:25:20 yes its pretty simple 2018-06-08 07:25:30 nice 2018-06-08 07:25:31 for sure when you build them on the correct builder. 2018-06-08 07:25:42 i currently build them on 1 box 2018-06-08 07:25:59 okay I'm going to sleep, will be back in few hours. 2018-06-08 07:26:04 gnite 2018-06-08 07:26:27 i wonder how many times the s390x installer is going to be used :) 2018-06-08 07:26:53 let's collect user data then :)) 2018-06-08 07:27:16 right, hook it up to algitbot :p 2018-06-08 07:27:40 only if it makes a cannon firing noise 2018-06-08 07:27:53 don't forget to update privacy policy on main website :)) 2018-06-08 07:28:26 (that is reference to the bottom of https://www.jwz.org/gruntle/nscpdorm.html : "We sat in the conference room and hooked up the big TV to one of the Indys, so that we could sit around in the dark and watch the FTP download logs scroll by. jg hacked up an impromptu script that played the sound of a cannon shot each time a download successfully completed. We sat in the dark and cheered, listening to the 2018-06-08 07:28:28 explosions.") 2018-06-08 07:30:06 i need to go out for a while. bbl 2018-06-08 07:31:11 wasn't s390x mostly used by banks? 2018-06-08 08:12:04 ncopa: so I tried your suggestion of setting the right owner of the directories in `package()`. If I `ls` just after it in the same function, the directories have the correct owner. however, once actually installed, the directories are somehow owned by `messagebus:audio` instead. Why does this happen and how could I fix it? 2018-06-08 08:14:43 PureTryOut[m]: do you create the user in pre-install or post-install? 2018-06-08 08:15:28 moved it to pre-install like you said 2018-06-08 08:16:08 tar -ztvf file.apk 2018-06-08 08:17:18 Tar format stores both name an numeric user id. If the user name does not exist on extract, the numeric I'd is used 2018-06-08 08:17:49 Id 2018-06-08 08:18:19 So it sounds like the user is not created in pre-install 2018-06-08 08:18:44 ACTION sent a long message: PureTryOut[m]_2018-06-08_08:18:43.txt  2018-06-08 08:18:50 seems about right? ^ 2018-06-08 08:20:36 I'm not sure why it wouldn't. the line is the same as I used before in post-install (where it was created fine), and the pre-install is executed on install according to the logs 2018-06-08 08:21:58 <_ikke_> Do you see the user has been created? 2018-06-08 08:28:14 well, I have the output redirected to /dev/null so no 😆 I'll remove that bit 2018-06-08 08:28:32 <_ikke_> I mean, just afterwards 2018-06-08 08:29:33 <_ikke_> on the system 2018-06-08 08:29:40 well, the user is listed in `/etc/passwd` if that is what you mean 2018-06-08 08:29:55 so yes, it has been created 2018-06-08 08:30:06 hmm, now i have a rpi3-aarch64 kernel without an rpi to test with :| 2018-06-08 08:34:56 ok even more interesting. `/var/lib/mopidy` is owned by `mopidy:audio`, but all subdirectories *inside* `/var/lib/mopidy` are owned by `messagebus:audio` 2018-06-08 08:40:46 I'm not sure at all how this is possible 2018-06-08 08:41:16 show us your apkbuild and scripts 2018-06-08 08:44:11 clandmeter: https://github.com/alpinelinux/aports/pull/4440 2018-06-08 08:51:07 PureTryOut[m], those directories already exist by the installer? 2018-06-08 08:53:29 ncopa, i have http://tpaste.us/qovO for rpi 2018-06-08 08:54:20 PureTryOut[m], for directories that already exist by the python installer you should chown them with -R 2018-06-08 08:55:14 Hmm I'm not actually sure if the Pyhon installer creates them, I'll check. thanks for the pointer 2018-06-08 08:55:29 if the directory has contents, it should. 2018-06-08 08:55:39 if I'm going to chown them, where would I do that? in a post-install hook? 2018-06-08 08:55:48 no 2018-06-08 08:55:54 just like you do now with install.... 2018-06-08 08:56:37 ah in `package()`, ok 2018-06-08 09:17:02 ok, so `/var/lib/mopidy` seems to be created by the Python installer, but it's subdirectories are not. the application complains however if it doesn't exist, so they do need to be created by the package 2018-06-08 09:18:11 <_ikke_> Then you'd need a bunch if install -d -m0755 -g .. -o .. $pkgdir/path/to/dir statements 2018-06-08 09:18:58 <_ikke_> But it's odd they aren't created 2018-06-08 09:19:29 yeah so like I have right now. but then those subdirectories are owned by the wrong user 2018-06-08 09:19:56 <_ikke_> How is /var/lib/mopidy set to the correct user? 2018-06-08 09:20:19 <_ikke_> in $pkgdir 2018-06-08 09:21:26 well `/var/lib/mopidy` is actually created by the python installer, so I guess that installer sets it? not entirely sure 2018-06-08 09:21:42 <_ikke_> but to what user? Is the user present on the system creating the package? 2018-06-08 09:22:43 the user isn't presented before I run the pre-install hook 2018-06-08 09:23:14 *isn't present 2018-06-08 09:23:18 <_ikke_> if you run abuild -r -k, you can inspect the pkg directory 2018-06-08 09:23:59 <_ikke_> sorry -K 2018-06-08 09:29:37 -rKf :) 2018-06-08 09:29:49 most of the time. 2018-06-08 09:30:01 <_ikke_> right 2018-06-08 09:35:03 http://tpaste.us/N76l 2018-06-08 09:35:06 looks fine by me 2018-06-08 09:35:52 agreed. but once installed, every subdirectory of `/var/lib/mopidy` is owned by `messagebus:audio` instead 2018-06-08 09:36:09 if you uninstall the pkg, are the dirs still there? 2018-06-08 09:43:25 `/var/lib/mopidy` is, but not it's subdirectories 2018-06-08 09:43:52 <_ikke_> Did /var/lib/mopidy already exist on your system? 2018-06-08 09:45:15 no it does not. but I guess it's created by the adduser command, as it's the home directory of the `mopidy` user 2018-06-08 09:45:30 <_ikke_> ah, that would explain 2018-06-08 09:45:42 would explain the fact it has the correct permissions where it's subdirectories do not: they are created in separate parts of the package 2018-06-08 09:46:44 I guess I could also create the directories in the pre-install hook, just as the user creation. but I was told it's preferable to do it in `package()` 2018-06-08 09:47:02 <_ikke_> Personally I fail to see how it's even possible to do it outside of post-install 2018-06-08 09:47:08 <_ikke_> Right 2018-06-08 09:47:17 it just doesn't work in package() 2018-06-08 09:47:30 <_ikke_> The directory creation should be done there, but permissions should be done on the system where the user is created 2018-06-08 09:48:10 <_ikke_> unless you create the user on the build system and what ncopa says is correct (regarding first using the username) 2018-06-08 09:48:14 this is related to that uid/gid cache problem I talked about last week, I think 2018-06-08 09:48:23 http://tpaste.us/YvjQ 2018-06-08 09:49:21 <_ikke_> clandmeter: Does that also work if mopidy happens to have a different uid on that system? 2018-06-08 09:49:55 huh...? it works for you? 2018-06-08 09:56:58 _ikke_, i think so 2018-06-08 09:57:19 i think apk will lookup the user and apply the correct uid 2018-06-08 10:00:16 so, what exactly should I do then? I don't know why it works for clandmeter , as it definitely doesn't for me. my previous way of doing it in post-install worked, but wasn't the "correct" way of doing it 2018-06-08 10:01:00 that said, creating the user in the pre-install hook and chowning the directories in the post-install hook didn't really work either iirc 2018-06-08 10:01:12 what happens if you remove the package user and mopidy dirs? 2018-06-08 10:01:58 without removing the package itself? what do you mean? 2018-06-08 10:02:55 remove pkg, user and dirs and isntall again. 2018-06-08 10:06:59 oh huh, that worked 2018-06-08 10:07:22 so it's just on first install? what the hell? 2018-06-08 10:13:06 hmm ok, this seems to be an edge case in our pmbootstrap installer (postmarketOS) actually. if I install the system without mopidy at first, and only install mopidy once the system has booted once, the directories are created with the proper owner 2018-06-08 10:14:36 this is pretty much what we've seen in our internal Alpine-based project as well 2018-06-08 10:17:01 well, I guess this package is fine then. I've updated the PR to resolve the last comments 2018-06-08 10:26:26 <_ikke_> But shouldn't it work regardless of when you install it? 2018-06-08 10:27:37 I suppose so 2018-06-08 10:34:47 What would be a correct solution then? 2018-06-08 12:20:46 Clandmeter: that rpi stuff lgtm 2018-06-08 12:21:39 Do you know approximately what the diff is from previous config? 2018-06-08 12:26:00 i can generate it 2018-06-08 12:26:23 there have been some changes like the install firmware part 2018-06-08 12:26:30 not sure that affects the release scripts 2018-06-08 12:27:45 and it would be nice if we could test images befre shipping them 2018-06-08 12:44:10 ncopa, http://tpaste.us/5Ydj 2018-06-08 12:45:25 one thing i noticed is config_packet, i think we should build it as module as we use it in /etc/modules 2018-06-08 12:59:51 yeah 2018-06-08 12:59:58 also optimize cc 2018-06-08 13:08:11 you want to optimize for size instead of performance? 2018-06-08 13:09:09 thats what we do for linux-vanilla, all arches 2018-06-08 13:09:34 the stack protector strong too 2018-06-08 13:10:57 CONFIG_SLAB_FREELIST_RANDOM 2018-06-08 13:12:17 CONFIG_CGROUP_PIDS 2018-06-08 13:12:39 cgroup* configs are useful for containers, lxc and docker etc 2018-06-08 13:13:49 CONFIG_SLAB_FREELIST_HARDENED 2018-06-08 13:14:32 CONFIG_CC_STACKPROTECTOR and stack protector strong 2018-06-08 13:16:20 Ok I'll add it 2018-06-08 13:17:17 im a bit in doubt of CONFIG_PREEMPT 2018-06-08 13:17:25 reduces latency 2018-06-08 13:17:34 i guess stick to rpi default is ok 2018-06-08 13:18:13 as you mentioned CONFIG_PACKET=m 2018-06-08 13:18:46 i suppose we should do CONFIG_PACKET=y on all the other kernels really 2018-06-08 13:20:06 CONFIG_IPV6_GRE=m may be needed for dmvpn, i guess we can let it be disabled til someone ask for it 2018-06-08 13:20:55 CONFIG_NF_CT_PROTO_DCCP=m and 2018-06-08 13:20:56 -CONFIG_NF_CT_PROTO_SCTP=m 2018-06-08 13:20:56 -CONFIG_NF_CT_PROTO_UDPLITE=m 2018-06-08 13:22:24 Can you paste a list so I can add them later. I got visitors 2018-06-08 13:40:28 clandmeter: http://tpaste.us/v7kM 2018-06-08 13:40:44 i guess that should be more or less okish 2018-06-08 13:40:53 enabling some hardened features 2018-06-08 13:41:18 CONFIG_SQUASHFS_LZ4=y may be needed for modloop 2018-06-08 13:50:32 now that rc1 is out, can we try focus on: 1) fix bugs. 2) test boot iso, efi, xen, 3) test installers with different options 4) look over what PRs we should prioritize 2018-06-08 14:12:03 re netboot 2018-06-08 14:12:26 should we create a dir with the kernel,initramfs,modloop or do we create a tarball with those? 2018-06-08 14:14:01 do we want a tarball with the kernel,initramfs,modloop: releases/$arch/alpine-netboot-$version-$arch.tar.gz 2018-06-08 14:14:18 or do we want that to be an extracted directory? 2018-06-08 14:15:05 so you can use http://dl-cdn.alpinelinux.org/alpine/v3.8/releases/netboot-3.8.0/vmlinuz-vanilla as kernel directly? 2018-06-08 14:16:34 ok i gotta go again 2018-06-08 15:24:34 ncopa: I would go for directory instead of tarball. https://github.com/alpinelinux/alpine-netboot/blob/master/boot.ipxe#L87 2018-06-08 15:24:44 modloop= kernel= initrd= 2018-06-08 15:25:06 Do we have GNU time packaged? 2018-06-08 15:25:11 having tarball means, tarball= and we need to unpack behind the scene 2018-06-08 15:25:17 Kinda need it for building OpenWRT 2018-06-08 15:25:46 http://dl-cdn.alpinelinux.org/alpine/v3.8/releases/netboot-3.8.0/vmlinuz-vanilla : I think this looks nice. 2018-06-08 15:26:03 clandmeter: how do you think? 2018-06-08 15:26:31 <_ikke_> azarus: apparently not 2018-06-08 15:26:50 _ikke_: I could package it, I suppose 2018-06-08 15:26:55 <_ikke_> https://pkgs.alpinelinux.org/contents?file=time&path=*bin*&name=&branch=edge&arch=x86_64 2018-06-08 15:27:23 Yup, checked pkgs.a.o, and just wanted to make sure 2018-06-08 15:34:39 tarball makes no sense for netboot 2018-06-08 15:45:00 OK, apkbuild posted to the list 2018-06-08 15:49:36 ncopa: the CONFIG_NF_CT_PROTO_xxx are not tristate so i cannot set them to modules 2018-06-08 15:50:11 you disabled ATA_OVER_ETH in favor of a module? any specific reason? 2018-06-08 15:52:40 ncopa, CONFIG_HAVE_ARCH_HARDENED_USERCOPY doesnt exist. 2018-06-08 15:53:39 atleast not on aarch64 2018-06-08 15:54:15 i think i have to adjust the config logic to also allow string values. 2018-06-08 15:57:32 ah https://github.com/torvalds/linux/commit/2fefc97b2180518bac923fba3f79fdca1f41dc15 2018-06-08 23:02:48 I can confirm emacs 26.1 works on arm64 2018-06-09 09:24:48 anyone here? 2018-06-09 09:34:01 always 2018-06-09 14:36:32 does alpine have a user build system to easily build packages locally, something like yaourt? 2018-06-09 14:42:29 <_ikke_> danieli: No 2018-06-09 14:42:36 <_ikke_> well 2018-06-09 14:42:52 <_ikke_> abuild -r build the packages of course 2018-06-09 14:43:08 <_ikke_> but no tool to download package sources from a repo and automatically build them 2018-06-09 14:43:11 abuild is kinda heavy and it's not an extremely easy interface to use 2018-06-09 14:43:22 <_ikke_> heavy in what sense? 2018-06-09 14:43:28 i'm aiming at something targetted at users and not devs/mirror admins/etc 2018-06-09 14:43:47 it pulls in a lot of packages and it's a *fairly* manual process 2018-06-09 14:46:18 <_ikke_> isn't it easier to provide prebuilt packages in that case? 2018-06-09 14:47:01 <_ikke_> whatever the program, it's probably going to use abuild to actually build the packages 2018-06-09 15:39:10 why would one want to build packages locally, anyway? 2018-06-11 09:57:17 clandmeter: re netboot images. do you think it makes sense to ship a alpine-netboot.tar.gz tarball with /boot/* or simply have a directory releases/x86_64/netboot-$version/ with the unpacked content (vmlinuz-vanilla, initramfs-vanilla, modloop-vanilla) 2018-06-11 09:57:42 ncopa, we need direct access to kernel and initramfs 2018-06-11 09:57:56 a tarball makes no sense except for local install. 2018-06-11 09:59:14 my point is: do you want use the dl-cdn.alpinelinux.org/alpine/v3.8/releases/x86_64/netboot-3.8.0/vmlinuz-vanilla directly or will you copy it to boot.alpinelinux.org/something ? 2018-06-11 09:59:24 ah like that. 2018-06-11 09:59:37 now you are making sense :) 2018-06-11 09:59:47 hmm 2018-06-11 10:02:34 can we include signatures on the mirror? 2018-06-11 10:03:04 i guess it means you need the CA on the builders. 2018-06-11 10:03:48 or add some logic to do it centralized. 2018-06-11 10:04:44 or just separate the boot scripts and signatures. 2018-06-11 10:45:05 signatures of what? 2018-06-11 10:45:14 its trivial to sign a tarball 2018-06-11 10:45:19 <_ikke_> the boot images 2018-06-11 10:45:25 <_ikke_> netboot has its own pki 2018-06-11 10:45:37 oh, ok 2018-06-11 10:46:09 where and how are the boot images signed? do we also sign the modloop and verify the signature of that? 2018-06-11 11:17:25 ncopa, check the netboot repo 2018-06-11 11:20:11 not sure why netboot repo is hidden on git.a.o. 2018-06-11 11:20:15 it shows on gh 2018-06-11 11:25:27 <_ikke_> Might be missing some kind of export attribute 2018-06-11 11:25:46 yes, but it was working before. 2018-06-11 11:25:50 not sure what changed. 2018-06-11 11:28:41 ncopa, only the kernel and initramfs are signed. 2018-06-11 11:28:58 i dont think we can verify it from ipxe. 2018-06-11 11:29:09 we could however do it from modloop initd. 2018-06-11 11:29:38 im open for suggestions. 2018-06-11 11:30:35 im trying to figure out how to do the s390x wihtout duplicate the ipxe work 2018-06-11 11:31:19 https://wiki.alpinelinux.org/wiki/S390x#KVM 2018-06-11 11:31:32 there is a modloop=http://.... 2018-06-11 11:31:52 the modloop needs to correspond with the running kernel 2018-06-11 11:32:10 so user needs to fetch kernel and then point to a remote modloop 2018-06-11 11:34:08 the https://github.com/alpinelinux/alpine-netboot/blob/master/mknetboot.sh script will put the modloop on boot.a.o 2018-06-11 11:34:18 i wonder if we should do the same with the s390x 2018-06-11 11:36:52 alternatively, i make a tarball from alpine relaese scripts and boot.a.o fetches those releases, and extrat them there 2018-06-11 11:37:02 we can try that with rc2 2018-06-11 12:39:49 ncopa, i think it would be nice if netboot can profit from using cdn. 2018-06-11 12:40:36 it also means that we stop shipping the latest kernel with netboot. 2018-06-11 12:40:52 its probably not a big issue. 2018-06-11 12:47:03 the only problem with cdn is that it does not get fetched over https 2018-06-11 12:47:09 and we dont sign modloop 2018-06-11 12:48:09 I don't expect much traffic from netboot downloads 2018-06-11 13:09:15 could someone merge/review https://github.com/alpinelinux/aports/pull/4083? it's been open for quite a while now 2018-06-11 13:12:07 <_ikke_> focus is mostly on releasing 3.8 2018-06-11 13:12:48 it's in testing so I just pushed it, editing commit msg 2018-06-11 13:13:14 <_ikke_> rnalrd: nice 2018-06-11 13:13:43 PureTryOut[m], what do you mean you cannot see it on pkgs.? 2018-06-11 13:14:16 testing is not available in stable branches, if thats what you mean. 2018-06-11 13:16:37 clandmeter: huh? are you talking to the wrong person? 2018-06-11 13:17:08 i dont think it niet 2018-06-11 13:17:29 <_ikke_> clandmeter: combining dutch and english? :D 2018-06-11 13:17:35 :p 2018-06-11 13:17:52 PureTryOut[m], read your own pr msg. 2018-06-11 13:18:17 <_ikke_> "however they are not listed as such on https://pkgs.alpinelinux.org. Bug?" 2018-06-11 13:19:03 Ik denk toch echt van wel haha 😉 2018-06-11 13:19:43 What PR? 😆 2018-06-11 13:20:12 <_ikke_> The one you just referred to 2018-06-11 13:20:15 do you have a split personality? 2018-06-11 13:20:20 oh 2018-06-11 13:20:21 :p 2018-06-11 13:20:23 <_ikke_> https://github.com/alpinelinux/aports/pull/4083?#issue-183240365 2018-06-11 13:21:13 well this package does not list all build requirements https://pkgs.alpinelinux.org/package/edge/testing/s390x/snapcast 2018-06-11 13:21:35 however, both snapcast (the package that doesn't list all it's build requirements) and the actual build requirements themselves are in testing 2018-06-11 13:22:06 listed as in the webpage doesn't show them 2018-06-11 13:23:21 sorry I'm working on multiple things at once right now, I tend to lose track a bit when doing so haha 2018-06-11 13:27:44 but yeah seems like a bug in the webinterface 2018-06-11 13:41:26 so what do you guys think about this? https://github.com/alpinelinux/aports/pull/4440#issuecomment-395771782 2018-06-11 13:41:48 can it be merged like that? I don't think mopidy will ever be part of any base installation, so it should be fine 2018-06-11 13:50:55 PureTryOut[m], it works just fine if you know how to use it. 2018-06-11 13:57:34 sorry, I'm again not entirely sure what you're talking about now 2018-06-11 13:57:55 15:27 but yeah seems like a bug in the webinterface 2018-06-11 14:01:17 is it right though? if you go to the popl package, it also doesn't show it's used by snapcast 2018-06-11 14:01:17 or is the web interface literally just talking about runtime dependencies? 2018-06-11 14:01:59 <_ikke_> yes 2018-06-11 14:02:05 <_ikke_> build dependencies are not listed 2018-06-11 14:04:08 ok, confusing 😆 then it's fine 2018-06-11 19:20:35 ncopa: I've tested xen boot in virtualbox and run setup-bootable on single disk, reboot, checked xen working 2018-06-11 19:20:57 ncopa: works fine with EFI but ISO doesn't boot on BIOS VM, fix verified on my end: https://github.com/alpinelinux/aports/pull/4481 2018-06-11 20:28:38 https://patchwork.alpinelinux.org/patch/3999/ would be nice to merge, removes a no longer needed patch 2018-06-11 20:41:32 radhus_: great! thanks! 2018-06-11 20:57:29 radhus_: im gonnapoush it with a trivial commit message change 2018-06-11 21:00:37 ncopa: ah, thanks, forgot the prefix :) 2018-06-11 21:11:31 thank you very much for testing and providing a fix 2018-06-11 21:14:29 np. I want to automate this test suite. lets see how much spare time I have during the summer :D 2018-06-11 21:35:56 ncopa: looks like you add netboot profile ! do you want me to update current pr to switch to netboot instead of standard ? 2018-06-11 21:49:40 how do you hook create_image_netboot() so it can be run ? 2018-06-11 21:59:21 wow 2018-06-11 21:59:29 that's cool ! 2018-06-11 22:57:22 ncopa: adding 2 modules for s390x on scripts/mkimg.netboot: https://github.com/alpinelinux/aports/pull/4482. 2018-06-12 06:57:11 hrm -- I'd like to upgrade community/minetest to fix some crashes in it, but I still have a cleanup patch pending :/ 2018-06-12 07:36:39 hmm, so I'd like to add Qt bindings to gpgme. However, gpgme is a package in main, where as the new qt5-qtbase-dev dependency is in community. how would I resolve this, if at all? 2018-06-12 07:37:14 <_ikke_> move gpgme to community/ 2018-06-12 07:37:16 <_ikke_> ? 2018-06-12 07:38:26 would that be accepted that easily though? 2018-06-12 07:38:56 <_ikke_> I don't know, but moving to community should be easier than the other way around 2018-06-12 07:39:48 <_ikke_> The problem is other things depending on it 2018-06-12 07:39:54 <_ikke_> required by (19) 2018-06-12 07:40:08 yteah 2018-06-12 07:41:46 yeah of which at least 3 are in main as well 2018-06-12 07:42:39 morning 2018-06-12 07:42:54 ncopa, why did you add add all those features to netboot? 2018-06-12 07:44:05 I guess I could move those 3 to community as well, but I don't think that will be well received 2018-06-12 07:44:12 I could make a new package entirely for it 2018-06-12 07:44:24 ncopa, and we are missing aarch64 in netboot arch? 2018-06-12 07:48:47 initfs_features="ata base bootchart squashfs ext2 ext3 ext4 mmc network scsi usb virtio" 2018-06-12 07:48:54 those features? 2018-06-12 07:49:17 i copied from standard profile, removed those i though was absoulutely unneccesary 2018-06-12 07:49:31 bootchart could probably be dropped too 2018-06-12 07:49:54 why do you need disk support? 2018-06-12 07:50:11 ata, base, ext*, mmc, scsi may be needed if you have an apkovl in local media (but no kernel) 2018-06-12 07:50:41 i wonder if thats really used a lot. 2018-06-12 07:50:42 so you can have local config while you update kernel via netboot 2018-06-12 07:50:44 probably not 2018-06-12 07:50:53 but you increase fetch time of initramfs 2018-06-12 07:50:57 but that was what i was thinking of when adding it 2018-06-12 07:51:05 the usb was added so you can have usb keyboard 2018-06-12 07:51:18 virtio may include ethernet driver? 2018-06-12 07:51:24 yes we need virtio 2018-06-12 07:51:36 what do you suggest we use instead as features? 2018-06-12 07:51:49 im not really sure. 2018-06-12 07:51:57 if there is a use case for usb disk, ok lets keep it. 2018-06-12 07:52:10 i wonder how much the size will differ. 2018-06-12 07:52:18 im thinking that we can remove it til someone asks for it 2018-06-12 07:52:30 maybe we should change our ext driver. 2018-06-12 07:52:36 wasnt there a catch all ext driver? 2018-06-12 07:52:48 ext4 2018-06-12 07:52:55 ext4 is enough? 2018-06-12 07:52:57 it supports ext2,3,4 filesystems 2018-06-12 07:52:59 yes 2018-06-12 07:53:02 ok 2018-06-12 07:53:05 i think its an option in kernel 2018-06-12 07:53:05 that we can fix 2018-06-12 07:53:06 ACTION peeks at the kernel config 2018-06-12 07:53:28 i suggest we remove it all 2018-06-12 07:53:36 and add when first person ask for it 2018-06-12 07:53:42 im not sure what the downsides will be. 2018-06-12 07:54:04 ncopa, right. that sounds good. 2018-06-12 07:54:09 you cannot have apkovl config stored locally 2018-06-12 07:54:14 thats the downside 2018-06-12 07:54:20 but if nobody uses it, then no problem 2018-06-12 07:54:27 thr ext4 kernel driver always understands ext2 and ext4 filesystems, that option clandmeter is talking about is using the ext4 driver as default 2018-06-12 07:54:29 i mean regarding ext driver. 2018-06-12 07:54:41 ok 2018-06-12 07:54:41 ext2 and ext3* 2018-06-12 07:54:45 if we change it, it it would break anything. 2018-06-12 07:54:50 lets remove ext2 and ext3 then 2018-06-12 07:55:00 i dont think it will 2018-06-12 07:55:30 maybe we have some part where we select a specific module by file? 2018-06-12 07:55:47 probably need to check features. 2018-06-12 07:56:03 we should probably also fix the description for the netboot image 2018-06-12 07:56:38 what about usb keyboard? 2018-06-12 07:56:45 do we need that for netboot? 2018-06-12 07:57:02 i dont think so 2018-06-12 07:57:05 we have modloop fetched 2018-06-12 07:57:16 only in rescue mode 2018-06-12 07:57:21 it would be to debug initramfs 2018-06-12 07:57:42 lets just add it. 2018-06-12 07:57:56 we should have a working env when using kernel+initramfs 2018-06-12 08:00:36 From ext4.wiki.kernel.org: "Note: The ext3 driver will be removed from the kernel in 4.3. The ext4 driver will mount ext3 volumes while maintaining ext3 disk format compatibility." ? 2018-06-12 08:00:46 Why isn't it gone already then? :P 2018-06-12 08:13:03 it is gone 2018-06-12 08:13:10 the ext3 is an alias 2018-06-12 08:13:14 but can ext4 mount ext2? 2018-06-12 08:17:33 CONFIG_EXT4_USE_FOR_EXT2 2018-06-12 08:18:11 ncopa: yes 2018-06-12 08:18:24 "Note: The ext3 driver will be removed from the kernel in 4.3. The ext4 driver will mount ext3 volumes while maintaining ext3 disk format compatibility." 2018-06-12 08:18:48 "both ext3 (and ext2, in kernels 2.6.28 and later)"* 2018-06-12 08:19:05 its already removed 2018-06-12 08:19:09 cool 2018-06-12 08:19:15 This config option is here only for backward compatibility. 2018-06-12 08:33:04 ncopa, please dont forget to add aarch64 to netboot. 2018-06-12 09:01:31 http://tpaste.us/kWo7 2018-06-12 09:25:57 anything else we nee to get in for the rc2? 2018-06-12 09:26:46 the readline package can't be installed due to a bad signature. for me locally the fix was just bumping `$pkgrel` by one, is that the proper fix? 2018-06-12 09:28:18 readline is in main btw, might be worth fixing before 3.8 2018-06-12 09:38:14 is that v3.8 package? 2018-06-12 09:38:17 which arch? 2018-06-12 09:39:38 amd64 2018-06-12 09:41:01 <_ikke_> PureTryOut[m]: did it get reverted? 2018-06-12 09:41:16 <_ikke_> that's the usual problem that causes this 2018-06-12 09:41:43 does not look like it 2018-06-12 09:41:55 how can i reproduce? 2018-06-12 09:42:49 installs just fine for me 2018-06-12 09:42:57 _ikke_: no, it was not reverted 2018-06-12 09:43:03 <_ikke_> ok 2018-06-12 09:44:06 hmm ok I'll try again, maybe it's fixed already? 2018-06-12 09:44:28 maybe you had local network problem? 2018-06-12 09:46:19 oh yeah it seems to have resolved itselve since yesterday. never mind then, ignore it 😉 2018-06-12 09:46:24 no everything else installed correctly 2018-06-12 10:05:48 few days ago I wrote in the #alpine-linux that openssl pkcs12 from libressl ave bug, it doesn't read pkcs12 file 2018-06-12 10:06:28 it should be fixed for 3.8 release 2018-06-12 10:07:18 also, binutils-dev doesn't install /usr/lib/libiberty.a file 2018-06-12 10:08:07 imho, that also should be fixed before release 2018-06-12 10:09:53 mps: do you have it on bugs.a.o? 2018-06-12 10:10:52 ncopa: no, should I fill one? I didn't because have no clear idea how to describe these bugs, but I could try if you think it would help 2018-06-12 10:11:11 things that are written in irc can easily be forgotten 2018-06-12 10:11:53 I know, but also thing in bugs.a.o tends to be ignored or forgotten ;) 2018-06-12 10:12:14 sometimes i remember "there was something about blabla" 2018-06-12 10:12:23 then i dont go search irc logs 2018-06-12 10:12:28 but i do search PRs anb bugs 2018-06-12 10:12:47 re openssl pkcs12 2018-06-12 10:12:59 i currently only that something is broke 2018-06-12 10:13:02 but i have no clue what 2018-06-12 10:13:06 or how to reproduce it 2018-06-12 10:13:11 or where to start look for a fix 2018-06-12 10:13:12 so 2018-06-12 10:13:13 no problem, I will fill bug reports later today when I come to my work machine 2018-06-12 10:13:46 thanks 2018-06-12 10:14:16 and, is it ok to post bug reports url here? 2018-06-12 10:22:30 it should actually do that, i have no idea why it has stopped doing it. 2018-06-12 10:24:05 clandmeter: yes, I remember algitboot messages but looks like it stoped to work 2018-06-12 10:35:29 freetype has CVE as of last month, appears to be unmitigated in edge https://sourceforge.net/projects/freetype/files/freetype2/2.9.1/ http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-6942 2018-06-12 10:47:50 awilfox: good catch. we shoudl fix this before v3.8 2018-06-12 11:03:25 a PR fixing this was opened a month ago https://github.com/alpinelinux/aports/pull/4243 2018-06-12 11:04:05 we could just go ahead and merge it. except for the fact that it includes a few stylistic changes it looks good to me 2018-06-12 11:38:27 the removal of freetype-config looks scary 2018-06-12 11:38:41 not a good idea to do that with a security fix 2018-06-12 11:39:54 yeah, indeed 2018-06-12 11:40:38 I am considering to just cherry-pick the commit fixing the CVE from the freetype repository 2018-06-12 11:43:36 https://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=29c759284e305ec428703c9a5831d0b1fc3497ef 2018-06-12 11:44:34 though it seems that they fixed a few other bugs in the 2.9.1 release as well but these weren't assigned a cve number so they are probably not as critical 2018-06-12 11:50:00 ncopa: http://tpaste.us/O4jZ are you ok with using this patch instead of the PR for now? 2018-06-12 11:50:45 oops. I actually made a mistake 2018-06-12 11:53:23 accidentally generated a git-format patch for the wrong commit. This should be the proper fix: http://tpaste.us/w7O9 2018-06-12 11:57:59 I will go get some lunch, unless they are any objection when I return I will just assume lazy consent and commits this as is 2018-06-12 12:05:54 i think we can upgrade and may be do some random tests and see if something breaks 2018-06-12 12:05:59 i assume most things will work 2018-06-12 12:08:57 ncopa, i guess 3.8 is close? 2018-06-12 12:09:05 ill add it to pkgs already 2018-06-12 12:09:31 yes 3.8 is close 2018-06-12 12:09:39 i am hoping to get rc2 out today 2018-06-12 12:09:56 im sure i will forget if i dont do it now. 2018-06-12 12:23:16 whats the status of rpi kernel? 2018-06-12 12:23:27 maybe we just push it and hope it works? 2018-06-12 12:27:11 idk, i tried it and it didnt. 2018-06-12 12:27:30 i think the release script also need modification 2018-06-12 12:27:35 for the bootloader. 2018-06-12 12:28:00 not sure if anybody wants to debug the kernel. i can provide it. 2018-06-12 12:41:20 ncopa: is there any reason against just pushing the CVE fix for now instead of doing the upgrade? we could just do the freetype upgrade as soon as 3.8 is released 2018-06-12 12:42:40 will make it more difficult to upgrade to a future 2.9.2 security upgrade 2018-06-12 12:46:57 any idea why s390 package was not updatedhttps://pkgs.alpinelinux.org/package/edge/testing/s390x/php7-protobuf 2018-06-12 12:47:23 but logs shows 3 days ago it was build fine http://build.alpinelinux.org/buildlogs/build-edge-s390x/testing/php7-protobuf/ 2018-06-12 12:57:37 s390x builder didnt complete the edge/testing repo 2018-06-12 13:12:29 yeah I ignored testing for now ... sorry 2018-06-12 13:14:37 anything else we nee to get in for the rc2? 2018-06-12 13:14:39 https://github.com/alpinelinux/alpine-conf/pull/16 2018-06-12 13:14:43 https://github.com/alpinelinux/alpine-conf/pull/14 2018-06-12 13:15:05 ncopa: you approved 16 already 2018-06-12 13:33:24 *14 2018-06-12 13:41:14 [ -n "$KOPT_ssh_key" ] && need sshd 2018-06-12 13:41:14 [ -n "$KOPT_ssh_pass" ] && use sshd 2018-06-12 13:41:49 tmh1999: the firstboot script. why is there difference on ssh_key and ssh_pass? 2018-06-12 13:42:18 because 'need sshd' on ssh_pass will have cyclic deps 2018-06-12 13:42:33 when you restarting 2018-06-12 13:42:40 restarting firstboot 2018-06-12 13:44:31 no. I rephrase. when inside firstboot, and you start/restart sshd, which you currently need it, it will have cyclic deps. 2018-06-12 13:49:07 starting services from an init.d script is a bad idea i think 2018-06-12 13:52:43 this was also my concern 2018-06-12 13:52:56 but at the time i didnt know any other solution. 2018-06-12 13:53:01 but is there any other way ? 2018-06-12 13:53:10 dont use password :) 2018-06-12 13:53:12 there is always other ways :) 2018-06-12 13:53:24 ncopa, thats why we have you. 2018-06-12 13:53:25 so 2018-06-12 13:53:30 lol 2018-06-12 13:53:37 I'm listening :P 2018-06-12 13:54:40 so the reason for the firstboot script in the firstplace was to add support to fetch ssh keys from https 2018-06-12 13:54:54 because then you could have busybox wget with https support 2018-06-12 13:55:13 and we didnt want add openssl binary to initramfs 2018-06-12 13:55:33 right? 2018-06-12 13:55:54 my idea was to keep as much logic out of initramfs if possible. 2018-06-12 13:56:00 right. also wget is actually added during/inside initramfs-init. 2018-06-12 13:56:06 if it happens after init, keep it out. 2018-06-12 13:56:14 but that was my logic :) 2018-06-12 13:56:29 but we cannot remove all logic from initramfs 2018-06-12 13:56:48 thats not what i said. 2018-06-12 13:56:49 we still need to parse cmdline to figure out if we should install openssh 2018-06-12 13:57:34 we could at the same time make sure that sshd service starts 2018-06-12 13:57:47 we dont need wget in initramfs afaik. 2018-06-12 13:57:53 only when we fetch ovl 2018-06-12 13:58:21 right, we dont need wget to make sure openssh is installed 2018-06-12 13:58:26 and make sure it starts 2018-06-12 13:58:47 if we fetch things after init we need it on newroot 2018-06-12 13:59:20 this is to fix the problem with starting sshd from firstboot script 2018-06-12 13:59:51 starting is not the issue 2018-06-12 14:00:05 start it with modified config 2018-06-12 14:00:19 aha 2018-06-12 14:00:20 thats why i suggested to modify sshd initd. 2018-06-12 14:00:37 to allow root login with password 2018-06-12 14:00:42 exactly 2018-06-12 14:00:54 :D 2018-06-12 14:01:02 and it needs to be disabled again after reboot. 2018-06-12 14:01:06 for sane reasons. 2018-06-12 14:01:14 right 2018-06-12 14:01:22 yeah... 2018-06-12 14:01:25 hum 2018-06-12 14:01:36 password is causing problems on many levels here 2018-06-12 14:02:30 if we can skip password login, life would be easier and more safe :) 2018-06-12 14:03:23 i was initially thinking of moving the logic back to initramfs 2018-06-12 14:03:40 but it does not solve the problem with removing the password login 2018-06-12 14:03:42 and 2018-06-12 14:04:01 are we sure we want remove the password login after first boot? 2018-06-12 14:04:17 what happens if sysadmin forgets to add the ssh key before reboot? 2018-06-12 14:04:40 he netboots again :) 2018-06-12 14:05:39 i would like to drop support for passwords 2018-06-12 14:05:47 that would make things alot simpler 2018-06-12 14:05:58 tmh1999: would that be an acceptable solution? 2018-06-12 14:06:04 i tried to talk tmh1999 out of it. 2018-06-12 14:06:16 i was not successful :) 2018-06-12 14:06:28 ncopa: afaik other s390x installer do have password in their installer. 2018-06-12 14:06:37 but if it's a strong no then I'm with you 2018-06-12 14:06:46 *other distros 2018-06-12 14:07:09 if other distros are the reason, i would suggest to drop it. 2018-06-12 14:07:39 the thing is that ed25519 pubkeys are short enough to substitute password 2018-06-12 14:07:42 yeah all I'm trying to do is to match what other distros do in terms of capabilities 2018-06-12 14:07:59 yeah I will mention that in the wiki page then 2018-06-12 14:08:45 ncopa, that reminds me. you nack my fallback to https repo if no apk repo is found. 2018-06-12 14:09:11 url? 2018-06-12 14:09:28 check history 4 weeks ago :| 2018-06-12 14:09:33 :P 2018-06-12 14:09:35 ha :) 2018-06-12 14:09:43 i dont remember when it was 2018-06-12 14:09:47 i think it was per pm 2018-06-12 14:10:00 i need history search in this irc client. 2018-06-12 14:10:10 tmh1999: i think the other option would be to enable ssh_pass from initramfs and simply not change config back 2018-06-12 14:10:18 maybe i have it in my local repo 2018-06-12 14:10:31 which is strongly not recommended 2018-06-12 14:10:47 and sysadmins will forget to change it back manually 2018-06-12 14:11:13 ncopa: okay. ssh_pass is not welcomed in initramfs nor firstboot then we drop it then. 2018-06-12 14:11:27 so if we support ssh_pass it will be not recommended 2018-06-12 14:11:44 so i think its better to not add the not recommended option in the first place 2018-06-12 14:11:59 and try make it as easy as possible to do it right 2018-06-12 14:12:10 I don't have a religion on this, just want to find a way that work out for both Alpine and s390x people. 2018-06-12 14:12:14 okay 2018-06-12 14:12:49 who knows, maybe s390x people will appreciate that we support ssh keys while other distros doesnt 2018-06-12 14:13:04 I will mention the ed25519 keys are short enough 2018-06-12 14:13:14 yeah hopefully :D 2018-06-12 14:13:36 if lack of ssh_pass will be a problem, we can add it later 2018-06-12 14:13:43 agreed 2018-06-12 14:14:07 the second issue was fetch key from https 2018-06-12 14:14:26 with the fixed busybox wget, adding https support is not that big deal in initramfs 2018-06-12 14:14:36 just add ssl_client 2018-06-12 14:14:40 which is relatively small 2018-06-12 14:15:05 so its not unreasonable to add https support to initramfs 2018-06-12 14:15:17 but i think we can do even better 2018-06-12 14:15:36 ncopa, http://tpaste.us/nqlM 2018-06-12 14:16:36 if we skip the password setup, i think the firstboot is pretty ok. 2018-06-12 14:17:22 what if we check if ssh_key is an url and if it is not, then create /sysroot/root/.ssh/authorized_keys 2018-06-12 14:17:30 eg if you have the key pasted there 2018-06-12 14:17:59 then from sshd init.d service it self we can again parse cmdline and check ssh_key 2018-06-12 14:18:05 if it is https:// the wget it from there 2018-06-12 14:18:29 from sshd init? 2018-06-12 14:18:29 if it https:// and /root/.ssh/authrized_keys not already exist 2018-06-12 14:18:31 yes 2018-06-12 14:18:59 i liked ther idea of firstboot. its more clear imho. 2018-06-12 14:19:13 but im not against sshd init. 2018-06-12 14:20:41 it's already done in firstboot 2018-06-12 14:20:54 https://git.alpinelinux.org/cgit/aports/tree/main/openrc/firstboot.initd#n34 2018-06-12 14:21:04 heh 2018-06-12 14:21:12 another interesting side-effect 2018-06-12 14:21:46 side-effect with parsing ssh_key and fetch from sshd init.d script 2018-06-12 14:22:21 is that if you set up lxc host with boot option ssh_key=... 2018-06-12 14:22:46 then will the lxc-create -t alpine ... && lxc-start -n .... 2018-06-12 14:22:55 also fetch the ssh key from the lxc host 2018-06-12 14:23:03 i dont know if that is wanted 2018-06-12 14:23:15 but thats an interesting side effect 2018-06-12 14:23:17 heh 2018-06-12 14:23:35 ncopa: thanks for merging ghc/cabal updates, I'll update ghc to 8.4.3 later 2018-06-12 14:23:51 mitchy: i think i already upgraded it 2018-06-12 14:23:55 at the same time 2018-06-12 14:24:15 to save compile time at the builder 2018-06-12 14:25:36 ah ok, any chance you could snag idris too? https://github.com/alpinelinux/aports/pull/4469 it only failed due to ghc 8.0.2 being in travis at the time 2018-06-12 14:27:50 ncopa, if we remove password login we should probably also remove insecure url support in firstboot key fetching. 2018-06-12 14:29:29 yes, only support https 2018-06-12 14:29:46 mitchy: it fails: http://tpaste.us/8xaR 2018-06-12 14:34:21 to sum up, 1. drop ssh_pass in firstboot and initramfs-init 2. drop http/ftp fetching 2018-06-12 14:34:54 we still need to remove firstboot in setup-disk.in though. that'd be 3. 2018-06-12 14:35:59 whats wrong to remove firstboot in setup-disk? 2018-06-12 14:36:36 idk ncopa is still thinking about it. https://github.com/alpinelinux/alpine-conf/pull/16 2018-06-12 14:37:48 ncopa: gah, i hate restrictive base library bounds 2018-06-12 14:39:18 clandmeter: not every setup uses setup-disk? 2018-06-12 14:39:19 ncopa: back it out if you like, I'll find the --constraints necessary to force it to build sanely 2018-06-12 14:39:36 mitchy: great. thanks! 2018-06-12 14:39:58 but it only affects setup-disk users? 2018-06-12 14:40:34 setup-alpine will install current system to disk including the firstboot runlevel. 2018-06-12 14:40:56 and diskless users? 2018-06-12 14:41:08 will still run firstboot right? 2018-06-12 14:41:16 lbu commit and reboot 2018-06-12 14:41:19 and it will run again? 2018-06-12 14:41:27 depends on boot ops 2018-06-12 14:41:58 maybe also add it to initd yes 2018-06-12 14:42:08 i think its better to do it from firstboot itself 2018-06-12 14:42:28 only remove it if it was actually run 2018-06-12 14:42:33 firstboot knows which disk you install? 2018-06-12 14:43:08 no, thats the point. it does not need to 2018-06-12 14:43:30 ah you mean remove before stup-disk 2018-06-12 14:43:35 yes 2018-06-12 14:43:44 i was thinking of initd stop 2018-06-12 14:43:46 :) 2018-06-12 14:43:52 first thing firstboot does is remove it from runlevels 2018-06-12 14:44:10 +1 2018-06-12 14:44:13 or at end of doing its job successfully if that is what we want 2018-06-12 14:44:23 then setup-disk does not need to care bout firstboot 2018-06-12 14:44:42 and if we remove or rename it we dont need search for a bunch of other scripts and adjust 2018-06-12 14:44:48 and make sure version nhumbers matches etc 2018-06-12 14:45:02 yeah that's what I mentioned. don't know if you like it though. 2018-06-12 14:48:21 I mean, mentioned in github conversation. 2018-06-12 14:48:58 do we do anything with ssh_key in initramfs now? 2018-06-12 14:49:01 i think we do 2018-06-12 14:49:36 i think we should make sshd start from initramfs if ssh_key is set 2018-06-12 14:49:43 and remove the depend in firstboot 2018-06-12 14:50:07 something like this: http://tpaste.us/rZpE 2018-06-12 14:51:23 tmh1999: i prefer rm /etc/runlevels/*/firstboot over rc-status del ... 2018-06-12 14:51:31 noted 2018-06-12 14:51:47 incase firstboot starts from other runlevel 2018-06-12 14:51:51 then we dont need change 2 plaes 2018-06-12 14:51:53 places 2018-06-12 14:52:07 +1 2018-06-12 14:52:42 while/if you move the starting of sshd to initramfs, please also drop ssh_pass too, in 1 commit. 2018-06-12 14:55:21 isnt SVCNAME depricated? 2018-06-12 14:55:33 doh, ghc-boot-th from 8.4.2 got in the cabal.config, 2018-06-12 14:55:53 so should be pretty easy to get idris up with 8.4.3 2018-06-12 14:56:30 clandmeter: probably, but you get the point 2018-06-12 14:59:21 i suppose we also remove the need_wget logic? 2018-06-12 15:00:38 is ssl_helper a seperate pkg? 2018-06-12 15:00:44 yes 2018-06-12 15:01:03 you pull it how? 2018-06-12 15:01:10 install_if 2018-06-12 15:01:17 if libssl is installed and busybox 2018-06-12 15:01:27 apk depends on libssl 2018-06-12 15:01:40 so ssl_client should be almost always installed 2018-06-12 15:01:52 ok then remove it. 2018-06-12 15:02:29 but if you want to fetch ovl you need it in initramfs. 2018-06-12 15:02:38 maybe add it as a feature. 2018-06-12 15:02:52 hum 2018-06-12 15:04:59 we could add it to the network feature 2018-06-12 15:05:36 it will make network bigger and most dont need it. 2018-06-12 15:05:44 err initramfs bigger. 2018-06-12 15:05:58 its 10k 2018-06-12 15:06:09 ah apk alraedy needs ssl 2018-06-12 15:06:20 ok just add it 2018-06-12 15:09:42 http://tpaste.us/6Ddz 2018-06-12 15:09:54 i'll test that it does not break the other stuff in a bit 2018-06-12 15:15:57 im testing 2018-06-12 15:16:08 also backport from alpine-conf: https://github.com/alpinelinux/aports/pull/4061 2018-06-12 16:27:25 hi alpine-dev, has anyone PXE booted alpine? curious what your kernel boot args were 2018-06-12 16:29:11 mickibm: alpine_repo=, ssh_key=, ip= and modloop= 2018-06-12 16:29:45 check out http://boot.alpinelinux.org/ 2018-06-12 16:30:10 thank you, no ppc64le on that page :) 2018-06-12 16:30:47 leitao and rdutra may answer your questions related to ppc64le 2018-06-12 16:31:03 is there a particular reason why there isn't a armhf kernel/initramfs on boot.alpinelinux.org? 2018-06-12 16:31:38 because core dev doesn't have time nor hardware to test. you're welcome to contribute. 2018-06-12 16:34:21 besides there being no pxe-like binary, it would stillbe handy to me, to have a virtio_net enabled initramfs for armhf accessible somewhere public 2018-06-12 16:36:38 mickibm: i am working on netboot releases for v3.8. i can add ppc64le if you want 2018-06-12 16:36:38 how can i contribute in this direction? i've manually built a initrd with network enabled, and can confirm that it works with qemu-system-armhf 2018-06-12 16:36:58 mickibm: would be great if you can help us test on ppc64le 2018-06-12 16:37:17 no problem 2018-06-12 16:39:18 please add ppc64le, i can talk with leitao too... http://openpower.ic.unicamp.br/minicloud/ 2018-06-12 16:39:29 ^public ppc64le boxes 2018-06-12 16:46:36 strfry: should be easy to add armhf support too. will do so 2018-06-12 16:46:40 for rc2 2018-06-12 16:48:43 would you like me to create a tracker bug for pxe support in ppc64le on bugs.alpinelinux? 2018-06-12 16:51:31 @ncopa: a feature request rather? 2018-06-12 16:55:22 should not be necessary, but maybe ping me in a hour to check that i havent forgotten 2018-06-12 16:55:58 will do, thnx 2018-06-12 16:57:33 i just did the commit so it will not be forgotten 2018-06-12 16:59:20 ncopa: thanks, that would be cool :) 2018-06-12 16:59:55 rdutra: i think py-setuptools-git is broken due to no git config is set on builders 2018-06-12 17:00:31 it might be that you can set EMAIL env var 2018-06-12 17:00:49 a8e435bd8c2800971f8b46a530b006ca2e2c2cf8 2018-06-12 17:01:04 http://dup.pw/aports/a8e435bd8c2800971f8b46a530b006ca2e2c2cf8 2018-06-12 17:01:28 oh he is not here 2018-06-12 17:11:58 hum 2018-06-12 17:12:53 ssh_key only works with netboot atm 2018-06-12 17:13:10 because it does not start network 2018-06-12 17:13:44 i wonder if we should set up dhcp by default too 2018-06-12 17:14:21 then you can add ssh_key=https://github.com/ncopa.keys as boot option and will be all good to go 2018-06-12 17:14:58 * Starting firstboot ... 2018-06-12 17:14:58 * Fetching ssh keys 2018-06-12 17:14:58 chmod: /root/.ssh/authorized_keys: No such file or directory [ !! ] 2018-06-12 17:14:58 wget: bad address 'github.com' 2018-06-12 17:14:58 * ERROR: firstboot failed to start 2018-06-12 17:17:35 welcome to the matrix. 2018-06-12 17:22:05 it would be nice if ppc64le was on http://boot.alpinelinux.org/images/edge/ ... would it be possible for someone to loop mount an iso soon? or just what until 3.8? 2018-06-12 17:23:18 mickibm: boot.alpinelinux.org is a parallel effort. we are working on merging it with the release process 2018-06-12 17:23:51 sweet- thatd be awesome. thank you 2018-06-12 17:28:34 heyyy thanks for looking at that PR in mkinitfs :) 2018-06-12 17:42:12 ncopa: beside netboot, what is the use of ssh_key for ? 2018-06-12 17:42:57 setup dhcp by default is kind of strong assumption 2018-06-12 17:43:43 I mean, when you add ssh_key, you should also net/network 2018-06-12 17:54:28 ncopa fixed the idris shenanigans sorry for the failure 2018-06-12 18:25:56 tmh1999: the idea was: boot standard alpine, add ssh_key=https:// and at the end of the boot you have ssh and netowrk running 2018-06-12 18:26:10 sshd will start but network is not configured 2018-06-12 18:26:35 and net work cannot be configured in initramfs unless all the network drivers are there 2018-06-12 18:26:41 which takes alot of space 2018-06-12 18:27:24 so for now ssh_key only works with netboot 2018-06-12 19:29:29 ncopa: https://bugs.alpinelinux.org/issues/8991 as promised today 2018-06-12 19:36:44 ncopa: another one: https://bugs.alpinelinux.org/issues/8992 2018-06-12 19:36:46 ah! great! I had already forgot about it. thanks! 2018-06-12 19:37:11 I'm new algitbot ;) 2018-06-12 19:39:05 if I know how to change subpackage in APKBUILD I would try to fix that bug in binutils-dev but looking to the subpackage section I didn't managed to understand it 2018-06-12 19:40:41 i think i broke binutils 2018-06-12 19:41:00 http://dup.pw/aports/b870dd8c4e66b1bb39542a6c6fd2c8e85f5101fe 2018-06-12 19:42:57 I see line 'rm -f "$pkgdir"/usr/lib/libiberty.a' in APKBUILD. Is that the problem 2018-06-12 19:49:16 looks like not, tried to rebuild binutils with this line removed but libiberty.a is not put in pkg/binutils-dev/usr/lib/ 2018-06-12 20:52:51 rc1 is out 2018-06-12 20:52:58 rc2 is out 2018-06-12 20:54:50 netboot images are built for all arches 2018-06-12 21:44:14 ncopa: nice 2018-06-12 21:44:44 i wonder how i could select the latest stable netboot images? 2018-06-12 22:29:08 aww sorry my ISP was out of services. testing the new rc2 now. 2018-06-12 22:54:39 \o/ everything working perfect 2018-06-12 22:56:45 Hey ncopa I am trying to enable armada support for arm. I built libdrm with a few tweaks and it packaged fine. However, when I go to build mesa the binaries build, but for some reason the .so files are not wrapping up into a apk. 2018-06-12 22:58:06 once I get this going I'll push this up into the alpine aports repos. 2018-06-12 22:59:25 When installing alpine in a kvm guest on ppc64le the grub.cfg is incorrect after install and the subsequent reboot will fail. The grub.cfg created during install has a boot stanza which contains "/boot/vmlinuz". However the linux-vanilla apk that is 2018-06-12 22:59:25 installed creates /boot/vmlinuz-vanilla. The mismatch appears to be in the alpine-conf-3.8.0_rc1 setup-disk.in script. That script on line 309 contains: 2018-06-12 22:59:25 case $KERNEL_FLAVOR in 2018-06-12 22:59:25 # setup GRUB config 2018-06-12 22:59:25 local kernel 2018-06-12 22:59:25 vanilla) kernel=vmlinuz ;; 2018-06-12 22:59:25 *) kernel=vmlinuz-$KERNEL_FLAVOR ;; 2018-06-12 22:59:26 esac 2018-06-12 22:59:26 Since the linux-vanilla apk really installs /boot/vmlinuz-vanilla shouldn't this just instead be: 2018-06-12 22:59:27 # setup GRUB config 2018-06-12 22:59:27 local kernel=vmlinuz-$KERNEL_FLAVOR 2018-06-12 23:06:21 does anyone know why a abuild -r would make the binaries but not package? 2018-06-12 23:12:27 mksully221: it happens on x86_64 too. it seems the kernel check was not updated. please send a patch. 2018-06-12 23:12:55 market_zero: how do you mean by make the binaries but not the package ? 2018-06-12 23:19:54 top_level/pkg/{.control.mesa-dev,mesa,mesa-dev,mesa-dri-ati} has been created but no *.apk 2018-06-12 23:21:21 have* 2018-06-12 23:22:56 Another note: I built libdrm package with etnaviv and then installed it on my local machine since mesa depends on it. 2018-06-12 23:23:33 seems like the build failed 2018-06-12 23:24:06 prob during/after package() in APKBUILD 2018-06-12 23:29:43 market_zero: and where did you look for the *.apk package? did you look under ~/packages ? 2018-06-12 23:30:06 correction: all the .so's are within the /pkg/{mesa,mesa-dev,mesa-dir-ati}/usr/lib/... and so on. So I have a bunch of compiled shared objects but no apk. Another thing I noticed after running `abuild clean` `abuild cleanoldpkg` abuild cleancache` make still enters directories saying there is nothing to be done, meaning it has already created the objects from a previous build 2018-06-12 23:30:19 yes I looked in ~/packages nothing 2018-06-12 23:31:19 abuild -r should delete the pkg/ dir after creating the package, so it looks something failed 2018-06-12 23:32:14 I piped everything to a log file looking for the error messages that are defined in the `/usr/bin/abuild` script, still no error reported 2018-06-12 23:34:51 according to the wiki the `clean_up()` function happens last in abuild but I am not sure where to look for this error. 2018-06-13 05:57:00 mksully221: its #8966 2018-06-13 05:58:37 algitbot started to work again, nice 2018-06-13 06:01:39 I cannot upgrade exiv2 package in edge. 'apk add -u exiv2' shows just '1 error; 1738 MiB in 614 packages' 2018-06-13 06:03:18 and 'apk version | grep exiv2' shows 'exiv2-0.25-r0 < 0.26-r0' 2018-06-13 06:40:56 mps: try: apk fix 2018-06-13 06:56:02 ncopa: tried but didn't help 2018-06-13 06:59:21 ncopa, moring. 2018-06-13 06:59:37 did you see my question? 2018-06-13 07:11:35 how to select latest netboot 2018-06-13 07:11:39 i saw it 2018-06-13 07:11:43 and i am thinking of it 2018-06-13 07:11:55 short answer: parse latest-release.yaml 2018-06-13 07:12:39 I am thinking that we could also create a symlink named 'netboot-latest' or simply 'netboot' which points to latest 2018-06-13 07:13:15 for all other images we dont create such symlink, but you can parse the yaml 2018-06-13 07:14:38 ncopa, parsing seems strange 2018-06-13 07:14:54 can we not have a single netboot folder with latest release? 2018-06-13 07:15:16 everything is possible 2018-06-13 07:15:24 :) 2018-06-13 07:15:33 can we have a single url with the latest iso? 2018-06-13 07:15:35 yes 2018-06-13 07:15:53 but i see the point 2018-06-13 07:16:31 maybe we can have a metadata file in the folder saying which release it is? 2018-06-13 07:16:46 or a symlink 2018-06-13 07:16:46 i am slightly hesitant though because i dont want to recommend use of the netboot-3.8.0_rc2/ files 2018-06-13 07:17:03 we don't sign those files 2018-06-13 07:20:55 well i can sign them via netboot.a.o just not the modloop. 2018-06-13 07:22:28 if you need to (re)sign them via netboot, then i assume that you need to download them to netboot.a.o 2018-06-13 07:22:39 yes i would 2018-06-13 07:23:08 then you can download the signed tarball, (and verify gpg signature) and put them in your own netboot/ directory 2018-06-13 07:23:10 but it would be nice if we could split bootscript/signatures and images. 2018-06-13 07:23:56 i guess we could sign the files using apk key 2018-06-13 07:25:07 why dont we sign the netboot images? 2018-06-13 07:25:25 we will sign the tarballs 2018-06-13 07:25:46 i know 2018-06-13 07:25:51 but you cant boot from it. 2018-06-13 07:26:09 the problem is how the mkimage script is designed 2018-06-13 07:26:17 it is designed to produce a single outfile 2018-06-13 07:26:20 not 3 2018-06-13 07:26:28 so it does not create checksums 2018-06-13 07:26:30 etc 2018-06-13 07:26:38 does not put the url in the yaml 2018-06-13 07:26:38 we cannot fix that? 2018-06-13 07:26:55 it requires a relatively big refactoring 2018-06-13 07:27:10 outfile needs to be an array 2018-06-13 07:27:28 there are many weird questions 2018-06-13 07:27:37 what if you have 3 different file extensions? 2018-06-13 07:27:49 it is a can of worms 2018-06-13 07:28:29 then if we put the raw vmlinuz and initramfs on all mirrors 2018-06-13 07:29:15 we make it very easy and convenient for people to do stupid stuff like fetch kernel with http and just boot it 2018-06-13 07:29:30 all major distros supply netboot images. 2018-06-13 07:29:43 if we do it this way i suggest remove it completely 2018-06-13 07:29:56 i dont oppose images 2018-06-13 07:30:17 you can ship a netboot.tar.gz but i would suggest to rename it. 2018-06-13 07:30:27 it has nothing to do with netboot. 2018-06-13 07:30:54 it has a kernel and modloop and initramfs with ehternet dirvers 2018-06-13 07:31:08 all you need to set up your own tftp 2018-06-13 07:31:40 ok lets tell that our users. 2018-06-13 07:31:44 im just expressing my thoughts 2018-06-13 07:31:47 you want to netboot like other distros? 2018-06-13 07:31:50 im not saying i am right :) 2018-06-13 07:32:02 im sorry, but you will have to setup it up yourself. 2018-06-13 07:32:06 :) 2018-06-13 07:32:11 how do you do netboot on otherdistros? 2018-06-13 07:32:22 http://ftp.nl.debian.org/debian/dists/stretch/main/installer-amd64/current/images/netboot/debian-installer/amd64/ 2018-06-13 07:33:14 so you just download the files from http and thats it? 2018-06-13 07:33:28 no checksum verification? no signature check? not even https? 2018-06-13 07:34:15 what is this netboot.tar.gz? http://ftp.nl.debian.org/debian/dists/stretch/main/installer-amd64/current/images/netboot/ 2018-06-13 07:34:36 there is an iso 2018-06-13 07:35:35 https://www.debian.org/distrib/netinst there is a "network boot" paragraph to the right 2018-06-13 07:36:07 https://www.debian.org/releases/stable/amd64/ch04s05.html.en 2018-06-13 07:40:20 if we use our own ipxe bootloader we can verify the images except the modloop. 2018-06-13 07:46:03 and we can sign the modloop similar to what we do with apk.static 2018-06-13 07:46:23 so we can verify it with the apk keys 2018-06-13 07:48:38 yes that would be neat 2018-06-13 07:51:13 lets say we create a netboot-latest symlink to the netboot directory 2018-06-13 07:51:19 how are this supposed to be used? 2018-06-13 07:51:44 i dont have much experience with netboot, that is why i am asking 2018-06-13 07:57:10 ncopa, this is the main ipxe boot script https://github.com/alpinelinux/alpine-netboot/blob/master/boot.ipxe 2018-06-13 07:57:41 it loads the kernel and initramfs 2018-06-13 07:57:49 and will verify with the supplied signatures 2018-06-13 08:16:11 @ncopa: fast-tracking here 2018-06-13 08:16:24 if you want that case statement structured multi-line, i can do it 2018-06-13 08:16:36 i don't mind either way, it was mostly to avoid a bashism and to discourage 'extension' 2018-06-13 09:23:44 Tecuane: i think i can fix it. I am testing it here now 2018-06-13 09:40:02 Anyone noticed that firefox-esr decorations problematic on x86 ? 2018-06-13 09:40:09 terra: yes 2018-06-13 09:40:14 its an old issue 2018-06-13 09:40:23 and nontrivial to ix 2018-06-13 09:40:24 fix* 2018-06-13 09:40:40 is there a workaraound? 2018-06-13 09:41:21 Same issue with Pale Moon 2018-06-13 09:42:16 #4248 2018-06-13 09:43:13 oh i never posted the upstream bug report 2018-06-13 09:43:46 https://bugzilla.mozilla.org/show_bug.cgi?format=default&id=1284293 2018-06-13 09:46:10 ncopa: thanks. I'm reading. 2018-06-13 09:50:57 I re-read it myself 2018-06-13 09:51:08 and i think I may have a suggestion to ao workaround 2018-06-13 09:51:10 i mean 2018-06-13 09:51:27 i may have something that makes it better 2018-06-13 09:51:40 It seems related with degraded floating point precision on 32bit mode 2018-06-13 09:51:50 yes 2018-06-13 09:51:56 i think we should just drop that 2018-06-13 09:51:58 Can it be fixed with some extra gcc optimizations? 2018-06-13 09:52:18 i think it can be fixed to not modify floating point precision 2018-06-13 09:53:01 some JS calculations may not be as expected, but at least i should show the widgets properly 2018-06-13 09:53:18 iirc there was some testcases for what this is supposed to solve 2018-06-13 09:53:48 The bad thing is even web content text can't be rendered on Pale Moon. But this is out od scope of Alpine. 2018-06-13 09:53:57 *of 2018-06-13 09:54:26 yes 2018-06-13 09:59:09 Tecuane: your patch breaks script when there are 2 disks in raid1 2018-06-13 10:24:04 terra: unfortunately i dont have time to work on it now 2018-06-13 10:24:10 i also need work on chromium 2018-06-13 10:24:21 but first prio is the v3.8 release 2018-06-13 10:24:49 ncopa: You already have been helpful 2018-06-13 10:25:00 thank you 2018-06-13 10:26:00 Some Gentoo guys who trying to port PaleMoon to musl noticed this this issue and seek help from me. 2018-06-13 10:26:19 aha 2018-06-13 10:26:35 At least I learned what is all about 2018-06-13 10:26:44 i think just removing that code that change the precision may help 2018-06-13 10:27:13 but i havent investigated what other ocnsequences it leads to 2018-06-13 10:27:56 on musl or firefox ? 2018-06-13 10:28:05 firefox 2018-06-13 10:28:22 prevent firefox to mess with the fpu precision 2018-06-13 10:29:15 https://github.com/mozilla/gecko-dev/blob/esr45/js/src/jsnum.cpp#L1045 2018-06-13 10:29:16 ? 2018-06-13 10:29:45 yes 2018-06-13 10:29:48 https://github.com/mozilla/gecko-dev/blob/esr45/js/src/jsnum.cpp#L1047 2018-06-13 10:29:54 ok thanks. 2018-06-13 10:29:59 change __GNUC__ to __GLIBC__ 2018-06-13 10:30:08 but the code looks different in recent firefox 2018-06-13 10:30:17 i think the function moved or got renamed 2018-06-13 10:30:33 ok 2018-06-13 10:30:36 so you may need to grep for "fstcw" 2018-06-13 10:30:56 I got it 2018-06-13 10:34:50 i think we should drop support for "data" mode disk install 2018-06-13 10:36:42 <_ikke_> Not that I'm using it, but why? 2018-06-13 10:36:54 setup-disk script is messy 2018-06-13 10:36:57 to simplify 2018-06-13 10:37:12 and the data mode setup is tricky to get right wrt upgrades 2018-06-13 10:37:24 we use data mode on our bld1/bld2 2018-06-13 10:37:50 and it is seldom that an upgrade "just works" 2018-06-13 10:39:20 <_ikke_> right ;-) 2018-06-13 11:50:19 ncopa: it seems just discarding that part in jsnum.cpp on musl fixed the problem. At least on Pale Moon. 2018-06-13 11:51:00 Thank you 2018-06-13 11:51:42 I will test it on firefox too. 2018-06-13 12:42:38 https://git.alpinelinux.org/cgit/aports/commit/?id=7a7493c33286ca7e43c8171cd6fad02bd13574c8 didn't we decide that we wanted to upgrade to 2.9.1 instead of simply including the patch for the CVE yesterday? 2018-06-13 12:43:45 terra: would be great if you could send a patch for alpine 2018-06-13 12:44:37 nmeum: that was what I wanted 2018-06-13 12:44:50 its not too late to upgrade freetype 2018-06-13 12:47:54 sure, I just dislike the fact that we discuss something on irc and that the opposite is actually implemented 2018-06-13 12:48:57 but well…I don't really expect everyone to read the entire irc backlog… 2018-06-13 12:49:32 anyway, I am working on an upgrade 2018-06-13 12:56:13 ncopa: turns out: there is a configure option to enable freetype-config again: http://tpaste.us/X6ee ok? 2018-06-13 12:56:49 ah great! 2018-06-13 12:56:52 lets enable it 2018-06-13 12:57:41 ok, I will just push the patch I linked above then 2018-06-13 13:00:41 pushed 2018-06-13 13:13:38 _ikke_ https://pastebin.com/dZYedLZs not really sure how to check /var/logs after mounting the disk, this is what I see after mounting the disk 2018-06-13 14:30:36 heh 2018-06-13 14:30:41 ipxe is pretty cool 2018-06-13 14:31:11 qemu-system-x86_64 --enable-kvm -m 1024 -cdrom http://boot.alpinelinux.org/alpine-ipxe/x86_64/ipxe.iso 2018-06-13 14:32:30 :D 2018-06-13 14:32:55 what :O qemu supports downloading iso from remote :O 2018-06-13 14:33:06 yeah, if its built with curl support 2018-06-13 14:33:20 I've lived my whole life wrong ... 2018-06-13 14:33:41 this is first time i am actually testing it 2018-06-13 14:33:46 +1 2018-06-13 14:34:05 but really 2018-06-13 14:34:07 this is awesome 2018-06-13 14:34:25 clandmeter: ^ that's for you 2018-06-13 14:34:27 clandmeter: you have don great job with this! 2018-06-13 14:34:43 <_ikke_> \o/ 2018-06-13 14:35:16 ncopa, you can also boot ipxe kernel directly 2018-06-13 14:37:52 ncopa: https://github.com/alpinelinux/aports/pull/4495 2018-06-13 14:37:58 qemu: could not load kernel 'http://boot.alpinelinux.org/alpine-ipxe/x86_64/ipxe.lkrn': No such file or directory 2018-06-13 14:38:28 what is awesome with the iso is that you only need qemu and an url to run alpine 2018-06-13 14:39:22 I'm trying to make the iso for s390x too. it looks like kvm can use iso. 2018-06-13 14:49:50 clandmeter: re netboot 2018-06-13 14:50:00 i think i will create a symlink to latest 2018-06-13 14:50:41 ok 2018-06-13 14:51:06 i think the fastly cache is available via https too 2018-06-13 14:51:10 just with other name 2018-06-13 14:53:41 yes it is 2018-06-13 14:54:21 we use it for cname 2018-06-13 15:21:57 ncopa, are you planning to setup periodical edge releases? 2018-06-13 15:22:05 would be nice to have it for netboot 2018-06-13 15:26:26 Will there be more regular releases of 3.8? Especially kernel releases, for those of us using diskless boot, where it's nontrivial to create a new image with updated kernel 2018-06-13 15:31:23 duncan^: yes. we should make releases more often after 3.8..0 2018-06-13 15:32:04 clandmeter: yes, I was thinking that we should do monthly edge releases or similar 2018-06-13 15:32:31 duncan^: there is a tool also: update-kernel 2018-06-13 15:33:36 ok i think its time for rc3 2018-06-13 15:33:37 oh 2018-06-13 15:33:44 clandmeter: what is the status of rpi kernel? 2018-06-13 15:34:12 it's like an rc a day 2018-06-13 15:59:35 ncopa, i didn't have time to check boot properly 2018-06-13 16:00:14 i think i just grab what you had, upgrade it to 4.14.49 and push it 2018-06-13 16:00:18 then ask community to test 2018-06-13 16:00:30 We could try to update 2018-06-13 16:00:45 Ask ppl to test rc 2018-06-13 16:01:17 Need also new fw 2018-06-13 16:01:37 how do i update the firmware? 2018-06-13 16:03:08 There is a commit is 2018-06-13 16:03:12 Id 2018-06-13 16:03:21 In release scripts 2018-06-13 16:04:06 rpi release scripts or alpine release scripts? 2018-06-13 16:04:15 Alpine 2018-06-13 16:04:18 aports-build script? 2018-06-13 16:04:21 on 2018-06-13 16:04:24 oh 2018-06-13 16:05:38 how do i find the correct commit hash? 2018-06-13 16:06:54 i just grab the latest in master branch? 2018-06-13 16:10:13 They don't mention tags in commits? 2018-06-13 16:31:48 They do 2018-06-13 16:35:11 jirutka: looks like perl-test-warn is regularily added to testing :D 2018-06-13 17:32:10 @ncopa: there should be an updated comment with the mkinitfs patch to use first network interface that is up. Want me to submit another PR to change the comment or could someone with master access just add it? 2018-06-13 17:32:13 https://github.com/alpinelinux/mkinitfs/blob/master/initramfs-init.in#L145 2018-06-13 17:32:37 sorry about that 2018-06-13 17:39:18 as far as ppc64le PXE testing is going - we used: http://dl-cdn.alpinelinux.org/alpine/v3.8/releases/ppc64le/netboot-3.8.0_rc2/ and it tried booting with eth3 interface using my patch however eth2 interface is the one we want to use and according to sysfs it is not up . I think it would be beneficial to specify the interface we want when dhcp 2018-06-13 17:39:18 is enabled, such as ip=dhcp:ethX in kernel cmdline. any thoughts? I can submit a PR 2018-06-13 17:45:42 ...trying to get exact operstate right now 2018-06-13 17:50:29 mickibm: i updated the comment. thanks 2018-06-13 17:50:35 i pushed rc3 2018-06-13 17:50:47 thank you. cannot get operstate - stuck in dhcp loop. must be a weird race condition? 2018-06-13 17:51:50 hum 2018-06-13 17:52:13 can you add boot option debug_init 2018-06-13 17:52:25 sure 2018-06-13 17:52:36 should show the execution of the init script 2018-06-13 17:52:45 maybe alos try use the rc3 2018-06-13 17:52:47 which is out now 2018-06-13 17:53:00 ok thanks 2018-06-13 17:53:36 <_ikke_> What did you change? 2018-06-13 17:53:39 <_ikke_> it's still RC2 2018-06-13 17:53:57 <_ikke_> (the topic) 2018-06-13 17:54:11 sorry 2018-06-13 17:54:14 <_ikke_> np 2018-06-13 17:54:18 thanks 2018-06-13 17:54:58 no modloop for rc3 in ppc64le? 2018-06-13 17:56:55 http://dl-master.alpinelinux.org/alpine/v3.8/releases/ppc64le/netboot-3.8.0_rc3/modloop-vanilla 2018-06-13 17:57:55 oh thanks, i was looking at dl-cdn 2018-06-13 17:58:23 <_ikke_> probably still needs to sync 2018-06-13 18:00:00 thanks guys. will update shortly 2018-06-13 19:02:11 @ncopa im using a newer Power machine, but just want to confirm, part of the kernel boot parameters I add: debug_init after my ip=dhcp, modloops, etc... 2018-06-13 19:03:28 because im getting some CPU lockups 2018-06-13 19:07:45 gotta go, be online soon 2018-06-13 19:54:47 on a power8 machine installing rc3 as a qemu guest the install intermittantly fails with the messages: 2018-06-13 19:54:47 Mounting boot media failed. 2018-06-13 19:54:47 initramfs emergency recovery shell launched. Type 'exit' to continue boot 2018-06-13 19:54:47 On successful attempts booting with the debug_init parameter set the "nlplug-findfs -p /sbin/mdev -d -b /tmp/repositories -a /tmp/apkovls" the output includes the scsi devices: 2018-06-13 19:54:47 nlplug-findfs: uevent: action='add' subsystem='scsi_disk' devname='(null)' devpath='/devices/vio/71000002/host0/target0:0:0/0:0:0:0/scsi_disk/0:0:0:0' 2018-06-13 19:54:47 nlplug-findfs: uevent: action='add' subsystem='srp_host' devname='(null)' devpath='/devices/vio/71000002/host0/srp_host/host0' 2018-06-13 19:54:47 nlplug-findfs: uevent: action='add' subsystem='scsi_generic' devname='sg0' devpath='/devices/vio/71000002/host0/target0:0:0/0:0:0:0/scsi_generic/sg0' 2018-06-13 19:54:48 On a failed boot this output isn't present...maybe a race condition in the device discovery? 2018-06-13 20:23:12 ncopa: I submitted the patch that fixing window decoration issue on x86 for firefox-esr. 2018-06-13 20:23:22 https://github.com/alpinelinux/aports/pull/4495 2018-06-13 21:59:41 _ikke_: do you by chance know why the tcl packages for alpine ship the dynamically linked .so library for tcl but not the statically linked .a library for it? 2018-06-13 22:00:23 <_ikke_> Xe: not sure why it's done, but I recall that they are removed by default 2018-06-13 22:00:25 have you looked in the -dev pkg for the .a file? 2018-06-13 22:00:34 zNVxxliww5gP: yes 2018-06-13 22:00:39 ok. just asking 2018-06-13 22:00:59 <_ikke_> there are a lot of .a files in packages though 2018-06-13 22:01:07 _ikke_: i'd be curious to find out. it's worth noting that the alpine packages ship the tcl stubs .a file 2018-06-13 22:02:00 <_ikke_> You'd have to ask one of the core developers probably 2018-06-13 22:02:10 alternatively some subpackage to install the static library would be nice 2018-06-13 22:02:43 kaniini: how come the libtcl8.6.a file isn't shipped in Alpine but its correlating .so file is? 2018-06-13 22:03:02 why not ask whoever maintains it 2018-06-13 22:03:49 <_ikke_> It's not that they are explicitly removed in the package 2018-06-13 22:06:23 clandmeter: how come the libtcl8.6.a file isn't shopped in the tcl-dev package, but the tcl stub library .a file is? 2018-06-13 22:06:28 shipped* 2018-06-13 22:07:18 <_ikke_> sorry for my ignorance, but what's a stub .a file? 2018-06-13 22:07:19 my usecase is to statically link a tool that depends on the system tcl 2018-06-13 22:08:01 <_ikke_> 5unix/libtclstub8.6.a 2018-06-13 22:08:05 <_ikke_> that u mean? 2018-06-13 22:08:12 _ikke_: it's something special to tcl apparently, i only found out about it by digging through /usr/lib while looking for libtcl8.6.a, https://wiki.tcl.tk/285 2018-06-13 22:08:26 the stub library is not the entire tcl library, which is what i'd need 2018-06-13 22:08:45 <_ikke_> Ok, so the compilation apparently only produces that file 2018-06-13 22:09:01 huh 2018-06-13 22:09:08 that's odd 2018-06-13 22:10:37 ah well then 2018-06-13 22:14:14 <_ikke_> http://tpaste.us/xew7 2018-06-13 23:03:52 hi, i took over maintainership for daemontools and ucspi-tcp about two years ago. these packages are in testing since then. is it possible to get them in community in some way? 2018-06-13 23:04:25 sure, submit a PR :) 2018-06-13 23:04:33 that moves it 2018-06-13 23:05:28 okay... but what's the normal process... just adding it too testing pulling it directly over to community would make no sense... so some time they should stay in testing or not? 2018-06-13 23:07:10 with djb software there is another problem. i believe these packages have been in community already but were "downgraded" to unmaintained some day because there where no updates. i belive these packages will not getting updates in the future thoug. so how to prevent them for being moved "down" again? 2018-06-13 23:08:06 I don't have an answer for you but will use that opportunity for a plug 2018-06-13 23:08:48 s6 and s6-networking, which do the same thing as daemontools and ucspi-tcp (basically, same commands, just prefix them with s6-), are in main/ 2018-06-13 23:09:11 is there some discussion somewhere before moving packages to "unmaintained"? 2018-06-13 23:09:58 you mean i should prefix daemontools with s6-daemontools? 2018-06-13 23:10:14 no, but s6-svscan, s6-supervise, s6-svc, etc. 2018-06-13 23:10:20 and s6-tcpserver 2018-06-13 23:10:41 ah, yes... they do the same but a complete rewwrites as i know 2018-06-13 23:10:51 yes, and for a reason 2018-06-13 23:11:12 so, you think there is no space for djb stuff? 2018-06-13 23:11:20 oh, there certainly is space 2018-06-13 23:11:24 ok 2018-06-13 23:11:38 but you can get the same functionality with a more recent and actually maintained code base :P 2018-06-13 23:12:01 i will maybe take a look at s6 in the future and maybe move over... but for now i will make a pull request to community 2018-06-13 23:12:05 https://skarnet.org/software/s6/ 2018-06-13 23:12:25 maybe that is the right choice in the future... ;) 2018-06-13 23:12:30 you really will be in familiar territory if you know daemontools 2018-06-13 23:13:09 yes, i know these tools but was too lazy because djb stuff always worked for me... :P 2018-06-13 23:13:38 of course they work, but they're unmaintained 2018-06-13 23:14:26 it's like runit tbh 2018-06-13 23:15:20 yeah 2018-06-13 23:15:39 but, a s6-tcpserver package is not available btw. 2018-06-13 23:16:16 s6-networking 2018-06-13 23:16:19 ah, yes i see 2018-06-13 23:16:21 thanks 2018-06-13 23:16:56 then it may it's useless to maintain djb stuff and could go ver to other stuff... ;) 2018-06-13 23:17:13 i would like to have netqmail in alpine. 2018-06-13 23:17:27 it isn't there? hm. 2018-06-13 23:17:34 (and no, there's no way I'm rewriting that one) 2018-06-13 23:17:41 (not in the next decade anyway) 2018-06-13 23:18:04 there were licensing issues in the past because djb didn't allowed to package it but i think nowadays it's okay 2018-06-13 23:18:13 :D 2018-06-13 23:18:23 it's been okay for more than 10 years now :P 2018-06-13 23:18:57 i want to migrate all my servers over to alpine this year and i really need qmail 2018-06-13 23:19:12 tbh netqmail can easily be installed from the tarball 2018-06-13 23:19:12 does your tcpserver support ssl? 2018-06-13 23:19:27 skarnet: yeah, but a package would be nice 2018-06-13 23:19:29 try s6-tlsserver 2018-06-13 23:19:37 wow, cool 2018-06-13 23:20:48 and it should link against bearssl nowadays 2018-06-13 23:21:03 try it, if it's linked against libressl then you have an old version 2018-06-13 23:21:15 the new version takes 10% as much RAM :P 2018-06-13 23:22:20 great... i know your s6 stuff for some time but never took a deeper look inside but it looks nice. even your code is very nice and clean. easy readable... 2018-06-13 23:23:07 I learned from djb, and then I kept coding and improved :P 2018-06-13 23:23:57 looks very impressive to me and i believe it does al i want 2018-06-13 23:25:01 cool then :) 2018-06-13 23:25:06 if you have questions we have a #s6 channel 2018-06-13 23:25:43 okay... that's definitely much more djb ever had... :P 2018-06-13 23:26:08 djb didn't have readiness notifications either ;) 2018-06-13 23:26:15 <_ikke_> hanez: afaik, packages are only moved to unmaintained when there are issues building it / running it 2018-06-13 23:26:15 yep 2018-06-13 23:26:26 _ikke_: okay. 2018-06-13 23:26:49 i will make a pull request then. 2018-06-13 23:27:01 and his supervise isn't a finite state machine, there are cases where svc is unresponsive :P 2018-06-13 23:27:13 but it looks like skarnet's stuff looks good for me too 2018-06-13 23:27:29 skarnet: yes, i had often these situations 2018-06-13 23:28:08 did you? I'm impressed - those are corner cases and I only hit them when looking for them :D 2018-06-13 23:28:50 i had that in a very high volume/traffic qmail environmentt at a german tv-channel many years ago 2018-06-13 23:29:18 there were situations were we needed to kill processes the hard way 2018-06-13 23:29:55 chances are that wasn't a "supervise doesn't respond to svc" case, but a lengthy lameduck problem 2018-06-13 23:30:08 i.e. qmail needed time between the SIGTERM and the exit 2018-06-13 23:30:44 maybe... we couldn't really debug because it was a very productive system and in test environments it never happened 2018-06-13 23:30:59 (s6 allows you to define a timeout, if the process hasn't exited after N milliseconds then it gets SIGKILLed) 2018-06-13 23:31:25 (but you don't want to do that with qmail if you value your mail queue) 2018-06-13 23:32:54 yes, that's problem. destroying the queue as evil as hell... /o\ 2018-06-13 23:34:01 what could help you though is receiving a notification when the process has actually died 2018-06-13 23:34:12 send the sigterm, wait for the notification, then proceed 2018-06-13 23:34:14 s6 can do that 2018-06-13 23:35:03 it's nice to see all your stuff in arch's AUR repo so i could start testing you software soon 2018-06-13 23:35:07 cool 2018-06-13 23:35:24 it's in AUR? heh. I have no idea who packages it for arch tho ^^" 2018-06-13 23:35:40 AUR are no packages just build instructions 2018-06-13 23:36:32 if your stuff does a great job this stuff may should go into "community" in arch... ;) 2018-06-13 23:37:06 tbh I've stopped being interested in arch (as well as Debian etc.) when they switched to systemd 2018-06-13 23:37:32 so I don't know how arch works and I don't really want to know :P 2018-06-13 23:37:46 musl distros are way above the others anyway :P 2018-06-13 23:37:51 yep, that is my problem too. on my desktop i do not care so much. my server farm runs gentoo on every mashine but that ofeten is a pain 2018-06-13 23:38:54 yes, ii will swwitch on my desktop away from arch too. but i have no time for that actually. i am planning to buy a new notebook soon and this device will never get in tocuh with systemd. ;) 2018-06-13 23:40:32 i run alpine and void in some virtual machines since some years and maintaining them is no work at all 2018-06-13 23:40:37 i prefer aalpine 2018-06-13 23:40:55 for your next desktop, try Adélie. Also a musl distro. :) 2018-06-13 23:41:48 you do not use alpine on a desktop? 2018-06-13 23:42:20 lots of people do. I don't, for the simple reason I basically don't use a desktop ;) 2018-06-13 23:42:23 <- server man 2018-06-13 23:43:35 yeah, am server man too but i need a device to access them and i am writing a lot of software for fun and my work 2018-06-13 23:45:33 same, but I made the decision long ago not to touch desktop software, because if I look under the hood I'll have an urge to rewrite everything 2018-06-13 23:45:38 and I can't afford that. 2018-06-13 23:47:13 yes, i don't do too. i use awesome wm and mostly minimal tools. i do not need much. in most cases vim is enough. 2018-06-13 23:49:49 many years i spent often a lot more time maintaining my desktop then hacking on cool stuff. nowadays my desktop just works... no features but it works and i am extremely productive since minimalizing my workspace 2018-06-13 23:50:57 ^ 2018-06-13 23:51:13 exact same reason why I don't want a fancy desktop 2018-06-14 06:23:21 simple tiling window managers are where it's at 2018-06-14 06:23:23 imo 2018-06-14 06:23:35 floating windows are such a pain in the ass 2018-06-14 06:30:15 agreed 2018-06-14 06:30:46 I used to be a i3 user, but I've switched to dwm for good half a year ago or so 2018-06-14 06:32:49 < lame plasma 5 user 2018-06-14 06:33:21 hilariously, I was in to tiling when I was a Mac user... there was this tool called Divvy that turned OS X's Aqua into a tiling wm 2018-06-14 06:33:43 when I went back to "real" unix, I gave up on tiling and went back to floating 2018-06-14 06:33:50 oh yup, was too, long time ago, but it practically fried my laptop 100% of the time I was using it (plasma 5, that is) 2018-06-14 06:57:48 anybody has an rpi1,2,3? 2018-06-14 06:57:56 please test current v3.8.0_rc3 2018-06-14 06:58:21 ncopa, there should also be an aarch64 build now. 2018-06-14 07:02:27 clandmeter: there were a bunch of rpi efforts from pmOS ppl which i missed 2018-06-14 07:03:00 Yes there were some prs 2018-06-14 07:03:18 Not sure it were so many 2018-06-14 07:03:36 http://lists.alpinelinux.org/alpine-devel/6194.html 2018-06-14 07:03:43 There is also a aarch64 kernel build 2018-06-14 07:03:56 i saw 2018-06-14 07:03:56 I have a rpi1 with an alpine chroot laying around somewhere but I wasn't having issues (it was using 4.14 anyway) 2018-06-14 07:04:05 Maybe we should add it to the script 2018-06-14 07:04:12 aha 2018-06-14 07:04:17 the release script 2018-06-14 07:04:20 Didn't have time yesterday 2018-06-14 07:04:22 Sorry 2018-06-14 07:04:25 i forgot it 2018-06-14 07:05:00 awilfox: we updated to rpi 4.14 kernel yesterday. can you help us test it? 2018-06-14 07:05:50 can try to tomorrow, if I can find the silly custom power lead... it doesn't like running off usb port 2018-06-14 07:06:24 Rpi3 supports netboot 2018-06-14 07:06:34 I only have a rpi1 2018-06-14 07:06:37 clandmeter: it looks like the netboot symlink didnt get rsynced 2018-06-14 07:08:44 synced? 2018-06-14 07:08:48 i dont see it on master. 2018-06-14 07:09:52 exactly 2018-06-14 07:11:25 it was never copied to dl-master. i dont know why 2018-06-14 07:12:10 we also have another challenge with the release iso 2018-06-14 07:12:36 how the packages to be included are calculated 2018-06-14 07:12:53 does not take install_if into account 2018-06-14 07:13:05 which means that *-openrc are not included on the iso 2018-06-14 07:13:32 hmm that sounds tricky 2018-06-14 07:13:39 yes 2018-06-14 07:13:55 i havent checked but i assume it also excludes ssl_client for same reason 2018-06-14 07:14:21 ssl_client is only included in netboot? 2018-06-14 07:14:31 in initramfs 2018-06-14 07:14:41 netboot does not ship any *.apk 2018-06-14 07:14:52 i know, its a diff question. 2018-06-14 07:15:11 i wonder if we should just have it in initramfs per default. 2018-06-14 07:15:57 yes: https://git.alpinelinux.org/cgit/mkinitfs/commit/?id=33865428099cf29934d02342f008e440b69b74c2 2018-06-14 07:16:09 you currently calculate iso deps with some script? 2018-06-14 07:16:34 yes 2018-06-14 07:17:18 $(apk fetch --root "$APKROOT" --simulate --recursive $apks | sort | checksum) 2018-06-14 07:17:55 10k to always have https support in initramfs would be a no brainer for me. 2018-06-14 07:17:57 sorry 2018-06-14 07:18:22 apk fetch --root "$APKROOT" --link --recursive --output "$_archdir" $apks 2018-06-14 07:18:48 so apk doesnt remember whats fetched? 2018-06-14 07:19:10 it does not need to 2018-06-14 07:19:23 it clears the tmpdir when its doen 2018-06-14 07:19:24 done* 2018-06-14 07:19:38 i mean it needs to know whats installed to trigger install_if 2018-06-14 07:19:57 apk fetch does not have that logic. 2018-06-14 07:20:03 apk fetch --recursive does not take install_if into account. correct 2018-06-14 07:20:34 what if you do a install dry run and get a list? 2018-06-14 07:20:54 which we then feed to apk fetch? 2018-06-14 07:20:57 yes 2018-06-14 07:21:01 but its hackish 2018-06-14 07:21:07 it is 2018-06-14 07:21:11 should be fixed in apk i guess. 2018-06-14 07:21:29 well 2018-06-14 07:21:40 i think current behavior makes sense sort of 2018-06-14 07:21:52 install_if takes into account if something already is installed 2018-06-14 07:22:02 apk fetch does not care about what is installed 2018-06-14 07:22:33 from user perspective is somewhat broken as it doesnt do whats expected. 2018-06-14 07:22:39 yes 2018-06-14 07:23:01 i suspect apk needs a refactor to do it thought 2018-06-14 07:23:26 so we may need to go for the hackish solution for now 2018-06-14 07:26:31 https://code.foxkit.us/adelie/image/blob/master/adelie-build-cd#L213 2018-06-14 07:26:39 that is exactly what we do :) 2018-06-14 07:29:45 awilfox: so you install all the packages into squashroot 2018-06-14 07:30:17 clandmeter: i guess a --print-names option for apk add 2018-06-14 07:30:53 apk add --root $emptydir --simulate --quiet --print-names $apks | xargs apk fetch ... 2018-06-14 07:32:20 sounds good. i think we can use print-names in more applets so its easier to script. 2018-06-14 07:34:42 hum 2018-06-14 07:34:58 looksl ike apk fetch should be able to handle install_if 2018-06-14 07:35:01 it goes via resolver 2018-06-14 07:36:12 ollieparanoid[m], ping 2018-06-14 08:04:15 ncopa, so its a kind of bug or still a feature? 2018-06-14 08:04:28 im investigating it 2018-06-14 08:05:02 $ ./src/apk fetch --simulate --recursive apk-tools busybox 2>&1| tpaste 2018-06-14 08:05:02 http://tpaste.us/YvkQ 2018-06-14 08:05:12 it looks like it is considering ssl_client 2018-06-14 08:07:32 cleaner output, without the local versions of the packages http://tpaste.us/5Y8j 2018-06-14 08:32:05 ncopa, ? 2018-06-14 08:32:22 is that the correct paste? 2018-06-14 08:34:06 the last paste yes 2018-06-14 08:34:17 it shows that solver considers ssl_client 2018-06-14 08:34:31 but i dont know why it does not include it in the fetch 2018-06-14 08:56:26 i know why it doesnt include it now 2018-06-14 10:53:45 i have a fix for apk fetch 2018-06-14 12:13:56 i'd like to push openjdk7 fix, but im afraid it will block the builders for a rc4 2018-06-14 12:26:03 i pushed openjdk7 so i guess the armhf builder will be busy til tomorrow now 2018-06-14 17:30:14 are there any ideas or tricks to deal with the huge dependencies to linux-firmware from the kernel packages? 2018-06-14 17:30:55 i'm trying to make a minimized raspberrypi image, and i currently build a slightly modified linux-rpi package with no dependency to linux-firmware 2018-06-14 17:31:46 but that breaks with every new kernel releases packaged 2018-06-14 19:05:46 strfry: do you know which firwmare is needed for rpi? 2018-06-14 19:06:00 can impossible need all of it 2018-06-14 19:06:46 ncopa: most ones doesn't make much sense, like -amdgpu ;) 2018-06-14 19:07:00 parts of linux-firmware-brcm are required for wifi on rpi3 2018-06-14 19:07:27 didn't stumble over anything else yet 2018-06-14 20:01:57 ncopa: actually, the wifi firmware is pulled in explicitly by the linux-firmware APKBUILD, outside of the prepared firmware tarball 2018-06-14 20:02:35 so it might actually make more sense to make a single package for that, and make linux-rpi not depend on linux-firmware... 2018-06-14 20:05:07 that would at least alleviate the problem on the rpi. while on other systems, drawing in hundreds of MB in firmware is still a nuisance, IMHO ;) 2018-06-14 21:20:16 <_ikke_> hey, that has been a while 2018-06-14 21:21:40 yes the msg.a.o host was set incorrectly on bugs. 2018-06-14 23:47:24 @kaniini @mepholic: you guys were right, I was one step away. Thank you 2018-06-14 23:47:42 i helped with something!? 2018-06-14 23:48:23 oh yeah, I manually moved the binaries over and it worked! 2018-06-14 23:48:53 +1 , I really appreciate the help 2018-06-14 23:50:06 You helped get xf86-video-armada working on Alpine Linux. Thank you so much. This will go upstream very soon. 2018-06-14 23:50:18 for armhf 2018-06-14 23:50:27 oh neat, good work marketzero :) 2018-06-15 01:18:12 just playing around with the idea of reproducible builds. i need to set the timestamp to all files in a package after package() in the APKBUILD was executed. i play a lot around with the abuild code but can't figure out where to that. any idea anyone who is deep into abuild code? 2018-06-15 01:55:51 okay i got that... now i need to know at which place the public RSA key is added to the package... any help would be nice. i am confused... :)) 2018-06-15 02:02:15 got it... 2018-06-15 06:49:55 ncopa, looks like rpi images work fine. 2018-06-15 06:50:07 thx for the firmware change. 2018-06-15 06:50:30 need to get latest firmware added. 2018-06-15 07:05:30 i wonder if we should decouple linux-firmware from kernel 2018-06-15 07:05:39 i dont know how though 2018-06-15 07:05:53 becuase if if simply remoev the dep, then will people have problems when upgrade 2018-06-15 07:06:07 maybe wait til after v3.8 2018-06-15 07:11:40 we need to fix those: http://tpaste.us/N7eB 2018-06-15 07:32:24 i have a tool for checking open github PRs for the aport you has a working directory 2018-06-15 07:32:32 so if you cd main/package 2018-06-15 07:32:36 and aports-ghpr 2018-06-15 07:32:41 it will search open PRs 2018-06-15 07:33:14 https://git.alpinelinux.org/cgit/user/ncopa/aports-ghpr/ 2018-06-15 07:40:06 ncopa: hmmm? decouple how? 2018-06-15 07:40:25 is it in the same package on alpine? i thought there was a separate linux-firmare package 2018-06-15 07:46:17 there is a separate linux-firmware package 2018-06-15 07:46:29 which depends on a bunch of linux-firmware-foobar pacakges 2018-06-15 07:46:38 but linux-vainlla depends on linux-firmware 2018-06-15 07:46:51 so you will always get all of the firmware installed 2018-06-15 07:47:31 i would like to remove the linux-firmware dependency for linux-vanilla 2018-06-15 07:47:43 and at install time, detect exactly which firmware is needed 2018-06-15 07:47:47 and only pull in those 2018-06-15 07:48:19 or maybe install all of them, but make it possible manually remove some of the unused ones 2018-06-15 07:52:37 ncopa: your last idea sounds like it is the most reasonable 2018-06-15 07:53:10 the problem is that if we remove the linux-firmware dependency, it will get uninstalled when people upgrade 2018-06-15 07:53:24 which may give people problems 2018-06-15 07:54:23 so what im thinking is 2018-06-15 07:54:30 yes, install everything and get the system working, after that user/admin could remove what is not needed in his/her system 2018-06-15 07:54:42 problem is when you upgrade 2018-06-15 07:54:44 apk ugprade 2018-06-15 07:55:00 if dependency is removed linux-firmware will be removed 2018-06-15 07:55:12 and user will have to manually apk add it before rebooting 2018-06-15 07:55:23 or network may break if they depend on firmware 2018-06-15 07:55:49 maybe reinstall everything during upgrade? 2018-06-15 07:56:07 people normally just do: apk upgrade 2018-06-15 07:56:12 to upgrade their systems 2018-06-15 07:56:17 without paying attention 2018-06-15 07:56:30 and again user/admin could remove unneeded after upgrade 2018-06-15 07:56:58 the problem is that upgrade will remove needed 2018-06-15 07:57:03 not sure, just thinking aloud 2018-06-15 07:57:42 im not sure you understand the upgrade problem 2018-06-15 07:58:09 example 2018-06-15 07:58:25 user has a machine with a NIC that rquires a firmware 2018-06-15 07:58:33 user installed v3.7 or runs edge 2018-06-15 07:58:56 currnetly the linux-vanilla depends=linux-firmware 2018-06-15 07:59:06 user get linux-vanilla installed and linux-firmware 2018-06-15 07:59:07 that is my case right now 2018-06-15 07:59:09 everything works 2018-06-15 07:59:28 now, what we are discussing is removing the depends=linux-firmware 2018-06-15 07:59:44 I understand 2018-06-15 08:00:05 if we simly remove the dependeny, an apk upgrade will remove the linux-firmware 2018-06-15 08:00:13 if user does not pay attention and reboot 2018-06-15 08:00:17 network will be broken 2018-06-15 08:00:28 right, I know 2018-06-15 08:00:42 but i may have an idea how to solve it 2018-06-15 08:00:47 i am not sure it works though 2018-06-15 08:00:57 I did right that, removed linux-firmware and noticed that 2018-06-15 08:01:39 the idea is that we set provides=linux-firmware on all linux-firmware-$sub 2018-06-15 08:01:50 my thought is that - install everything (firmware) at install or upgrade linux-vanilla (kernel) 2018-06-15 08:02:22 we also add an linux-firmware-empty with provides=linux-firmware 2018-06-15 08:02:47 and in the linux-vanilla we keep the depends=linux-firmware 2018-06-15 08:03:00 that is ok 2018-06-15 08:03:13 this means that you need any of the linux-firmware-* installed to make apk happy 2018-06-15 08:03:32 if you have linux-firmware installed from before, then apk is happy 2018-06-15 08:03:49 if linux-vanilla depends on linux-firmware then the linux-firmware must be installed 2018-06-15 08:03:58 if you want finetune, then you can apk add linux-firmware-foo 2018-06-15 08:04:05 and apk del linux-firmware 2018-06-15 08:04:25 since linux-firmware-foo provides the linux-firmware, apk should be happy 2018-06-15 08:05:14 but doesn't linux-firmware depends on all linux-firmware-xxx 2018-06-15 08:05:32 it does 2018-06-15 08:05:36 but i think it may work 2018-06-15 08:05:51 alternatively we use another provides name 2018-06-15 08:06:15 so removing just one linux-firmware-xxx will remove linux-firmware 2018-06-15 08:06:53 the idea is that you first apk add linux-firmware-foo 2018-06-15 08:07:03 then apk del linux-firmware (catch all package) 2018-06-15 08:07:08 and linux-firmware 'will' remove all linux-firmware-xxx 2018-06-15 08:07:23 you add linux-firmware-foo to /etc/apk/world 2018-06-15 08:07:28 it becomes a top level dependency 2018-06-15 08:08:00 when you apk del linux-firmware, it will delete all linux-firmware-* except the ones listed in world 2018-06-15 08:08:36 the linux-firmware-foo which has provides=linux-firmware will satisfy the linux-vanilla's depends=linux-firmware 2018-06-15 08:08:39 that is the idea 2018-06-15 08:08:45 hmmm, maybe some kind of pinning desired linux-firmware-xx 2018-06-15 08:08:59 that is what apk add linux-firmware-xx does 2018-06-15 08:09:03 it will "pin" it 2018-06-15 08:09:06 to world 2018-06-15 08:09:19 aha, now understand better 2018-06-15 08:09:43 that sounds good 2018-06-15 08:09:59 linux-vanilla dependency will be met if any of the linux-firmware-* are installed 2018-06-15 08:10:07 which of then doesnt matter 2018-06-15 08:10:26 so the problem is: what happens if you dont need any firmware at all? 2018-06-15 08:11:01 thats why i mentioned an empty package named linux-firmware-none 2018-06-15 08:11:25 I can't remember any machine where at least some firmware is not needed 2018-06-15 08:11:34 maybe some VMs 2018-06-15 08:11:40 VMs yes 2018-06-15 08:12:43 let me summarize 2018-06-15 08:13:23 install linux-vanilla will install linux-firmware, which will install all linux-firmware-* 2018-06-15 08:14:36 then, remove unneeded linux-firmware-x and rest of the linux-firmware-x will be 'pinned' for upgrade 2018-06-15 08:14:43 right? 2018-06-15 08:15:19 actually: apk add linux-vanilla will give error 2018-06-15 08:15:30 you will have to pick one linux-firmware package 2018-06-15 08:15:37 but upgrades will work 2018-06-15 08:15:58 unless we give linux-frimware (the catchall) a prioritoy 2018-06-15 08:16:02 then it should work 2018-06-15 08:17:01 to summarize: on fresh install, linux-vanilla and linux-firmware-all is installed 2018-06-15 08:17:14 that is ok 2018-06-15 08:17:54 user who wants remove unneeded will need to: apk add liunx-firmware-foo && apk del linux-firmware-all 2018-06-15 08:18:14 the first 'add' will pin it to worls 2018-06-15 08:18:19 aha, good 2018-06-15 08:18:23 the second will remove all unneeded 2018-06-15 08:18:25 thats the idea 2018-06-15 08:18:36 mps: out of curiosity, do you use tcsh as your main shell? 2018-06-15 08:18:52 mepholic: yes, more that 25 years 2018-06-15 08:19:39 ah nice :) 2018-06-15 08:20:04 how's it treating you on alpine? 2018-06-15 08:20:29 ncopa: so, apk add linux-firmware-foo1 will pin that package, and apk add linux-firmware-foo2 will pin it also 2018-06-15 08:20:41 correct 2018-06-15 08:21:00 lemme catch up on backlog since I asked my q to ncopa 2018-06-15 08:21:24 that sounds good, till you find clever idea :) 2018-06-15 08:21:47 last msg meant to ncopa 2018-06-15 08:21:47 mps: i am not sure it will work in practice though 2018-06-15 08:22:15 we may need use another name for the provides 2018-06-15 08:22:53 ncopa: I thougt about that, but does apk understand 'provides' tag 2018-06-15 08:23:01 yes 2018-06-15 08:23:18 then it should work 2018-06-15 08:23:43 i dont knkow if it works if you have a pkgname=linux-firmware and others with provides=linux-firmware 2018-06-15 08:24:01 i guess i'll have to test it 2018-06-15 08:25:15 if linux-firmware depends on the all linux-firmware-* how it could be 'told' to stop depending on removed ones 2018-06-15 08:26:07 ok, to explain that better, lets say we use provides=anyfw 2018-06-15 08:26:29 the linux-firmware which depends on linux-firmware-*, has a provides=anyfw 2018-06-15 08:26:43 all the linux-firmware-* also has provides=anyfw 2018-06-15 08:26:53 we change linux-vanilla to depend=anyfw 2018-06-15 08:26:53 aha, ok 2018-06-15 08:27:00 ncopa: I'm concerned that that still wont resolve the issue of linux-kernel depending on linux-firmware 2018-06-15 08:27:13 or rather, you'd still need to remove the dep, yes? 2018-06-15 08:27:43 and it'd still uninstall things from the users system if they haven't pinned specific firmwares already 2018-06-15 08:28:12 lets use "anyfw" as provides name in this example 2018-06-15 08:28:38 so current users has: linux-vanilla installed with depends=linux-firmware 2018-06-15 08:28:46 so linux-firmware is installed due to the dep 2018-06-15 08:28:57 we change linux-vanilla depends=anyfw 2018-06-15 08:29:10 OH and linux-firmware provides anyfw 2018-06-15 08:29:12 ! 2018-06-15 08:29:24 when users upgrade, then already have the linux-firmware installed so the dep is satisfied 2018-06-15 08:29:26 that was the idea 2018-06-15 08:29:37 but i dont know if it works 2018-06-15 08:29:40 yeah, gotcha 2018-06-15 08:29:45 sounds reasonable to me 2018-06-15 08:30:55 also to me 2018-06-15 08:31:55 of course, if the apk add firmware-foo1 automatically pins it 2018-06-15 08:32:22 and apk del linux-firmware-foo1 unpins it 2018-06-15 08:35:06 mepholic: what you mean by 'how's it treating you on alpine?' question? 2018-06-15 08:35:51 I'm self taught in English so I cannot catch some finesses 2018-06-15 08:36:17 mps: I think that was basically asking "is it working well" 2018-06-15 08:36:56 awilfox: yes, it works very well 2018-06-15 08:37:20 I don't have any problem with it 2018-06-15 08:40:09 mps: I realized after the fact that I really need to avoid using colloquialisms with people I know are foreigners 2018-06-15 08:40:12 :P 2018-06-15 08:41:02 also, it's impressive to me that some people have been using the same software for as long as I've been alive 2018-06-15 08:41:39 "so by 'legacy', you mean that 'it works'?" :D 2018-06-15 08:41:52 mepholic: 'cat' is longer here that tcsh 2018-06-15 08:41:55 :) 2018-06-15 08:42:52 now the real question is if you've used the same implementation of 'cat' the whole time 2018-06-15 08:42:56 :P 2018-06-15 08:43:00 re linux-firmware 2018-06-15 08:43:03 i think it works 2018-06-15 08:43:15 nice :D 2018-06-15 08:43:19 and i think it works better than i thought 2018-06-15 08:43:29 you simply need to apk add linux-firmware-xx 2018-06-15 08:43:36 and it will purge linux-firmware 2018-06-15 08:43:53 is that a feature though? 2018-06-15 08:43:56 I mean I guess it is 2018-06-15 08:43:58 yes 2018-06-15 08:43:59 I just read how you're doing it; that's how we got alpine<->adelie crossgrades to work with libressl/openssl 2018-06-15 08:44:10 exactly that way 2018-06-15 08:44:49 the only thing i noticed was that with the apk ugprade, it would only upgrade the main package, not the subpackages 2018-06-15 08:45:08 i think that can be solved with versioned deps 2018-06-15 08:45:26 can you version subpackages? 2018-06-15 08:45:43 versioned dependency of subpackage yes 2018-06-15 08:45:58 i figure'd they'd have inherited the main packages version 2018-06-15 08:46:02 depends="subpkg=$pkgver-$pkgrel" 2018-06-15 08:46:20 specify the version in the depends 2018-06-15 08:46:43 so the question is, is THAT a feature? 2018-06-15 08:47:08 versioned dependencies? 2018-06-15 08:47:09 yes 2018-06-15 08:47:17 why would you potentially want stale subpackages hanging around? 2018-06-15 08:47:25 or maybe I'm failing to understand something 2018-06-15 08:47:52 clamav has something like that I think 2018-06-15 08:47:59 the problem is that when i added provides=... on all the subpackages, and did apk upgrade 2018-06-15 08:48:02 freshclan-openrc deps on freshclam=$pkgver 2018-06-15 08:48:10 it didnt upgrade the subpackags 2018-06-15 08:48:10 well -$pkgrel too 2018-06-15 08:50:16 ok that gave error 2018-06-15 08:56:24 ok, it does not work :-( 2018-06-15 08:56:36 well 2018-06-15 08:56:40 it sort of works 2018-06-15 08:56:46 apk upgrade will give error 2018-06-15 08:58:01 so basically, user will get error and will have to apk add linux-firwmare-something 2018-06-15 08:58:20 i guess that sort of works 2018-06-15 08:58:47 because then will user not unintentionally get the firmware removed 2018-06-15 09:00:15 that is ok, IMO 2018-06-15 09:04:47 and it is solvable 2018-06-15 09:05:12 this is great 2018-06-15 09:05:34 if we set provider_priority=1 on the main package 2018-06-15 09:05:40 then it will autopick that 2018-06-15 09:05:50 so you will get the linux-firmware 2018-06-15 09:05:58 unless you pick a specific 2018-06-15 09:06:12 if you apk add linux-firmware-foo 2018-06-15 09:06:19 it will add that and purge the rest 2018-06-15 09:07:01 it works perfect 2018-06-15 09:07:27 and, apk add linux-firmware-foo ; add linux-firmware-bar it will keep both? 2018-06-15 09:07:37 yes 2018-06-15 09:07:42 and only those 2018-06-15 09:07:48 nice 2018-06-15 09:07:58 we only need a dummy package for -none 2018-06-15 09:09:23 so, linux-firmware-none will remove all firmware? 2018-06-15 09:09:34 and install an empty package, yes 2018-06-15 09:10:04 useful for VMs 2018-06-15 09:11:15 ncopa: good work 2018-06-15 09:28:32 :) 2018-06-15 09:28:36 awesome! 2018-06-15 09:29:07 now i just wait for kernel version upgrade to avoid build it twice 2018-06-15 09:29:33 wait for 4.14.50 2018-06-15 10:06:04 ncopa: excellent, also thank you very much for the quick linux-rpi change :) 2018-06-15 13:55:31 ncopa: I guess you'd like to release next week ? 2018-06-15 13:55:54 it's friday. 2018-06-15 14:30:07 yes 2018-06-15 14:30:20 early next week is release 2018-06-15 14:30:31 i was hoping that 4.14.50 comes out first 2018-06-15 14:59:53 +1 2018-06-15 16:39:10 Clandmeter: the netboot symlink is there 2018-06-15 16:40:21 I think we should add versions to the ipxe menu 2018-06-15 16:41:35 Hi 2018-06-15 16:41:56 How do you want to add it? 2018-06-15 16:43:36 Ipxe is limited 2018-06-15 16:47:23 You add the urls in the ipxe config, right? What if we generate the config? 2018-06-15 16:49:04 Hook on mqtt release event we generate the ipxe config 2018-06-15 16:49:32 ncopa: do you have an idea why --mtime is not working here? (line 34 in abuild-sign.in) : tar --mtime='1970-01-01' -f - -c "$sig" | abuild-tar --cut | gzip -9 > "$tmptargz" 2018-06-15 16:49:47 Using mustache template or similar 2018-06-15 16:51:56 How do you define not working? 2018-06-15 16:52:22 Generate scripts will work 2018-06-15 16:52:32 I can check later 2018-06-15 16:52:45 Doesn't the timestamp show 1970 when you tar -ztvf ..? 2018-06-15 16:52:54 Had a funeral today :| 2018-06-15 16:53:01 Aw! 2018-06-15 16:53:01 ncopa: it will be ignored. i have added --mtime there but it still sets the build time and date for the $sig file in the .apk 2018-06-15 16:53:17 not what i defined in --mtime 2018-06-15 16:53:59 in abuild.in it works at the two places where tar is being called 2018-06-15 16:54:21 and if you pipe it to tar? ... | tar -tv 2018-06-15 16:54:47 Note that gzip also store a timestamp 2018-06-15 16:55:05 i am trying to play around with reproducible package builds and the timestamp of files is often a problem... it's just a proof of concept at the moent and i will post all my ideas on the mailinglist for discussion when it works 2018-06-15 16:55:23 ncopa: yeah, but in abuild.in it works 2018-06-15 16:55:27 and the call is teh same 2018-06-15 16:55:35 you mean pipe tar to tar? 2018-06-15 16:55:44 Yes 2018-06-15 16:55:52 okay... i will giveit a try 2018-06-15 16:56:00 To see if it is tar or something else 2018-06-15 16:56:42 yep. are you aware of the idea of reproducible builds? 2018-06-15 17:32:34 hm, tar can not read from stdin so piping from tar to tar will not work 2018-06-15 17:32:41 i am confused 2018-06-15 17:34:06 which tar is it? 2018-06-15 17:34:31 GNU tar 2018-06-15 17:34:46 what i am trying is to set --mtime 2018-06-15 17:35:12 this works in abuild.in: tar --mtime='1970-01-01' -f - -c $(cat "$dir"/.metafiles) | abuild-tar --cut | gzip -9 > control.tar.gz 2018-06-15 17:35:33 but this does not work in abuild-sign: tar --mtime='1970-01-01' -f - -c "$sig" | abuild-tar --cut | 2018-06-15 17:35:35 gzip -9 > "$tmptargz" 2018-06-15 17:51:06 $ tar --mtime='1970-01-01' -c foo | tar -tv 2018-06-15 17:51:12 -rw-r--r-- ncopa/ncopa 13 1970-01-01 00:00 foo 2018-06-15 17:52:05 $ tar --mtime='1970-01-01' -c foo | abuild-tar --cut | tar -tv 2018-06-15 17:52:05 -rw-r--r-- ncopa/ncopa 13 1970-01-01 00:00 foo 2018-06-15 17:54:36 uh, thanks 2018-06-15 17:54:41 i will try that 2018-06-15 17:55:01 you can remove "-f -" 2018-06-15 17:55:10 is the same as not specifying -f 2018-06-15 17:57:11 hm, but the .SIGN.RSA* ist still todays date after running: tar --mtime='1970-01-01' -c "$sig" | tar -tv | abuild-tar --cut | gzip -9 > "$tmptargz" 2018-06-15 17:57:46 it should be 19700101000000 2018-06-15 17:57:58 sorry, 19790101000000 2018-06-15 17:58:02 argh 2018-06-15 17:59:12 been thinking of reproduceable builds and timestamps 2018-06-15 17:59:20 we could use the git commit timestamp 2018-06-15 17:59:23 yep 2018-06-15 17:59:28 yes, thats the idea 2018-06-15 17:59:34 good :) 2018-06-15 17:59:52 i am hard setting it to 1970-01-01 00:00:00 hard ATM 2018-06-15 18:00:02 you also need to set gzip timestamp 2018-06-15 18:00:13 it should be the last git commitz date at some time 2018-06-15 18:00:30 thje timestamp of the gzip is not so important at first 2018-06-15 18:00:48 i need to get the .SIGN.RSA* set to a specific date 2018-06-15 18:01:24 it is abuild sign that creates it, right? 2018-06-15 18:01:30 all other files are set correct within the abuild script but in the signing process it fails 2018-06-15 18:01:34 yes 2018-06-15 18:02:03 and we dont sign via pipe? 2018-06-15 18:02:37 this looks it for me now: https://pastebin.com/uDcCefpH 2018-06-15 18:02:43 then we could make abuild sign keep the date of the original file 2018-06-15 18:03:04 that would be nice too 2018-06-15 18:03:49 tar --mtime='1970-01-01' -c "$sig" | tar -tv | abuild-tar --cut | gzip -9 > "$tmptargz" 2018-06-15 18:03:53 thats wrong 2018-06-15 18:04:11 remove the tar -tv 2018-06-15 18:05:40 yes, but that still sets the timestamp of the .SIGN.RSA* to today and not 19700101 2018-06-15 18:06:53 <[[sroracle]]> yes 2018-06-15 18:07:01 <[[sroracle]]> you need to look at abuild-sign 2018-06-15 18:07:06 i said, in abuild script it works when building data.tar.gz andd control.tar.gz 2018-06-15 18:07:13 <[[sroracle]]> that adds .SIGN file 2018-06-15 18:07:14 i know 2018-06-15 18:07:21 there i am hacking in 2018-06-15 18:07:50 i added --mtime to tar in abuild-sign 2018-06-15 18:08:49 as i said... in abuild script it works with just adding --mtime 2018-06-15 18:08:54 <[[sroracle]]> libarchive tar doesn't support mtime so i just used touch instead 2018-06-15 18:09:14 what i said. in abuild script it works 2018-06-15 18:09:35 uh 2018-06-15 18:09:46 abuild uses /bin/ash and abuild sign /bin/sh 2018-06-15 18:10:00 thats the problem i think 2018-06-15 18:11:08 no 2018-06-15 18:11:10 it isnt 2018-06-15 18:20:02 touching the file $sig before tar'ing it doesn't help 2018-06-15 18:20:08 i am so confused 2018-06-15 18:22:44 <[[sroracle]]> it's still today's date? 2018-06-15 18:23:16 yes 2018-06-15 18:23:28 i think i am stupid actually 2018-06-15 18:24:00 <[[sroracle]]> i think i had the same issue where i was touching it before tar but also before openssl 2018-06-15 18:24:18 <[[sroracle]]> need to touch after openssl 2018-06-15 18:24:44 yes, i do that after openssl 2018-06-15 18:24:59 did you worked on the idea of reproducable buils too? 2018-06-15 18:25:45 <[[sroracle]]> yeah but i have barely scratched the surface as well :) 2018-06-15 18:26:42 i will get it working. i know some devs who invented it at debian and they would be happy to see alpine participate... ;) 2018-06-15 18:26:52 this is how it looks for me now: https://pastebin.com/JArsjPtR 2018-06-15 18:27:22 <[[sroracle]]> my current thinking is to set SOURCE_DATE_EPOCH to either last commit time of APKBUILD or, if APKBUILD is dirty (uncommitted changes etc) then use stat APKBUILD 2018-06-15 18:27:28 i am touching and using --mtime with no luck 2018-06-15 18:28:04 yeah, thats the idea. i am at first want to reset it to 1970-01-01 2018-06-15 18:28:10 then the next step 2018-06-15 18:29:04 in debian they use the last change date of of the source files... 2018-06-15 18:47:25 i am soooooo stupid 2018-06-15 18:55:24 will tell you later... git it now 2018-06-15 18:55:33 <_ikke_> the suspension 2018-06-15 18:57:18 short, it was a calll to the wron abuild-sign script... /o\ 2018-06-15 18:57:48 I know the feeling 2018-06-15 18:58:41 ha \o/ 2018-06-15 18:59:03 hanez: i've done similar.... 2018-06-15 18:59:47 is it necessary to provide an apkovl as a kernel boot argument in order to PXE boot? 2018-06-15 18:59:54 oh, thanks... feeling better now. i was short before shooting myself... :| 2018-06-15 19:06:46 on ppc64le, using a power8 box, only when an apkovl is provided, then networking is configured properly. without apkovl, but still with same repo specified, cannot load initramfs and kernel panic 2018-06-15 19:15:36 okay... got muy first reproducible package... :) 2018-06-15 19:20:49 mickibm: shoudl be possible to load initramfs even without apkovl 2018-06-15 19:24:30 thats what i thought 2018-06-15 21:55:38 [[sroracle]]: ping 2018-06-15 21:56:17 <[[sroracle]]> hanez: pong 2018-06-15 21:56:28 [[sroracle]]: getting the date from stat APKBUILD is not working because it always has the timestamp from cloning or checkout 2018-06-15 21:56:58 getting the date from last git commit of APKBUILD is not trivial too 2018-06-15 21:57:05 <[[sroracle]]> right, so you default to getting the commit or author date first if APKBUILD has not been modified in the eyes of git 2018-06-15 21:57:20 <[[sroracle]]> let me paste what i have 2018-06-15 21:57:30 yeah, that would be nice 2018-06-15 21:58:07 what i have so far. everything is working like we want it. expect the source for the date. currently it is still hardcoded 2018-06-15 21:58:17 but everything else works like a charm 2018-06-15 21:58:35 <[[sroracle]]> http://ix.io/1duN 2018-06-15 21:59:04 <[[sroracle]]> git status --porcelain will be empty iff APKBUILD is unmodified and previously committed 2018-06-15 21:59:29 <[[sroracle]]> if it is modified or untracked then it outputs a status of some kind that you could examine further if you'd like 2018-06-15 21:59:40 <[[sroracle]]> but in that case i just fall back to stat 2018-06-15 22:00:05 <[[sroracle]]> %ct is for commit timestamp; you could also use %at for author timestamp 2018-06-15 22:00:36 are these unix timestamps? 2018-06-15 22:00:43 <[[sroracle]]> they should be yes 2018-06-15 22:01:05 okay. where in abuild would you place that piece of code? 2018-06-15 22:01:48 <[[sroracle]]> towards the end; probably before sourcing $APKBUILD itself 2018-06-15 22:06:14 okay, makes sense. what about line 2547 in https://git.unixpeople.org/hanez/abuild/src/branch/master/abuild.in ? 2018-06-15 22:09:27 2565 is the better place because we the cd'ed to the right dir 2018-06-15 22:10:09 or after 2563 2018-06-15 22:10:18 then source APKBUILD 2018-06-15 22:17:04 hmm, git log does not work with busybox... 2018-06-15 22:17:18 less: unrecognized option: F 2018-06-15 22:18:43 hanez: apk add less 2018-06-15 22:19:35 busybox applets are 'first aid tools' and not useful for 'serious' work 2018-06-15 22:20:02 mps: okay, so less is available on build hosts? 2018-06-15 22:20:22 apk search less will show you 2018-06-15 22:20:50 ah, you are working on build host, sorry 2018-06-15 22:20:57 yes, i know. 2018-06-15 22:21:03 no, i am working on abuild 2018-06-15 22:21:16 I thought you are working on the local machine 2018-06-15 22:21:21 and then less will become a dep of abuild 2018-06-15 22:21:26 `git` should probably depend on `less` 2018-06-15 22:21:27 honestly 2018-06-15 22:21:33 i am working local but hacking on abuild 2018-06-15 22:21:48 awilfox: yeah, you're right 2018-06-15 22:22:35 i really need the last commit date of an APKBUILD file for setting it as SOURCE_DATE_EPOCH for realizing reproducible builds 2018-06-15 22:29:51 [[sroracle]]: i think this line should be enough: SOURCE_DATE_EPOCH=$($git log -1 --format='%ct' "abuild.in") 2018-06-15 22:30:03 s/abuld.in/APKBUILD/ 2018-06-15 22:31:01 s/abuild.in/$APKBUILD/ 2018-06-15 22:31:09 works so far 2018-06-15 22:31:31 git log --pretty=format:'%ci' APKBUILD 2018-06-15 22:32:18 mps: nono, i need the unixtimestamp 2018-06-15 22:32:48 SOURCE_DATE_EPOCH _MUST_ be epoch time 2018-06-15 22:33:04 ah, then %ct is right 2018-06-15 22:33:08 :) 2018-06-15 22:33:22 i am converting where needed 2018-06-15 22:41:54 \o/ it works... :))) 2018-06-15 22:43:38 wireguard kernel module is in linux-vanilla but wireguard-tools is in testing 2018-06-15 22:44:19 shouldn't the wireguard-tools be moved to main or to community at least 2018-06-15 22:44:21 the change now is: builddate, file dates in packages and the date in the header of PKGINFO file is set to the date of the last commit of the APKBUILD file 2018-06-16 05:52:20 <_ikke_> jirutka: What should check() contain if there is no test suite? (I recall ./prog --version wasn't suitable) 2018-06-16 06:17:13 options="!check" 2018-06-16 06:23:19 <_ikke_> Right, so not checking is preferred then 2018-06-16 06:27:43 yes, here is the rationale: http://lists.alpinelinux.org/alpine-devel/6154.html 2018-06-16 06:27:55 basically doing --version makes it /look/ like the software works when it really doesn't 2018-06-16 06:28:15 there's one exception I can think of, x265, it initialises the entire codec and can show SIGILL if it is built with wrong -march/-mcpu 2018-06-16 06:30:01 <_ikke_> right 2018-06-16 10:22:59 [[sroracle]]: i believe getting the SOURCE_EPOCH_DATE is not a good idea. 2018-06-16 10:23:13 sorry, SOURCE_DATE_EPOCH 2018-06-16 10:23:47 i believe getting the date from the last changed file in a source archive is much better and more reliable 2018-06-16 12:58:48 [[sroracle]]: i have a new idea... i could generate SOURCE_DATE_EPOCH when checksum are being generated and write it to .PKGINFO 2018-06-16 12:59:07 then all people could be determistic packages and this is fully reliable 2018-06-16 12:59:46 s/be/build/ 2018-06-16 13:00:09 s/.PKGINFO/APKBUILD/ 2018-06-16 15:04:28 <[[sroracle]]> I used APKBUILD date because it reflects the addition or subtraction of any patches, version upgrades, changes in build process or configuration, etc 2018-06-16 15:05:00 <[[sroracle]]> using the timestamp of the bare source files themselves is not informative enough 2018-06-16 15:37:04 [[sroracle]]: yes i agree 2018-06-16 15:37:22 i had some more solutions but all them fail at some point 2018-06-16 15:38:12 your idea is the best one but it fails on the check if it is git repository when it is not 2018-06-16 15:38:42 the script runs with "set -e" so when the git command fails, the script will terminate 2018-06-16 15:45:25 <[[sroracle]]> Ah 2018-06-16 15:45:48 <[[sroracle]]> There is probably some way to work around that, I’ll have to think about it later 2018-06-16 15:59:33 we can set +a short before the test and set it back right after... but thats not a good idea. now i make the check using "git status" nut the is bad too because my $HOME is a git repo and git status will always return 0 even if the current working directory is not tracked by git... 2018-06-16 16:00:09 s/nut the/but this/ 2018-06-16 16:13:12 using the "write the current date to APKBUILD during abuild checksum as eg. source_date=" would probably be the cleanest solution and align with the way debian does it 2018-06-16 16:13:55 then use CI for ensure source_date= has been increased when $pkgver or $pkgrel are modified 2018-06-16 16:14:04 s/for/to 2018-06-16 16:16:52 for every approach that has weaker rules which value is being used for SOURCE_DATE_EPOCH could result in two identical systems building two different packages. you can still rebuild the package by taking the values from PKGINFO, but you can't just build everything twice and expect it to be identical 2018-06-16 16:17:43 debian is using the source package upload date for this 2018-06-16 16:46:01 [[sroracle]]: as kpcyrd says... the mtime of the APKBUILD will not work 2018-06-16 17:08:27 kpcyrd: i thinkwe misunderstood here... we are not using mtime but last commit date of APKBUILD 2018-06-16 17:08:40 mtime only when it is not a git repo 2018-06-16 17:09:23 kpcyrd: last commit should work 2018-06-16 17:14:46 that would work if you can require that: 1) a package MUST be built from a git checkout and 2) the package that is uploaded MUST be built from the commit that has been merged to master (to ensure the value can't change after that point) 2018-06-16 17:15:56 if you can depend on 1), an exit code of git being != 0 would be a fatal error 2018-06-16 17:16:04 would/should 2018-06-16 17:17:52 not sure how packages are uploaded at alpine, if the packages are built by an automatic build system it probably would be easy to ensure both requirements are always met 2018-06-16 17:19:10 yep 2018-06-16 21:41:12 so what do I have to do still to get this PR merged? https://github.com/alpinelinux/aports/pull/4440 2018-06-16 21:46:49 <_ikke_> PureTryOut[m]: I guess mostly wait 2018-06-16 21:46:55 <_ikke_> 3.8 is next door 2018-06-17 18:51:42 say, a new version of a program in main/ depends on a new library, should that library also be in main/ ? 2018-06-17 18:58:08 (example, new bluez depends on ell, which isn't packaged) 2018-06-17 19:02:49 <_ikke_> Yes, packages from main cannot rely on things in community 2018-06-17 19:03:25 ok, thank you 2018-06-17 19:03:54 <_ikke_> But things in main should be supported for a certain period (sec/bug fixes) 2018-06-17 19:04:25 how would one check for that? 2018-06-17 19:04:47 <_ikke_> Perhaps check the history of the project 2018-06-17 19:07:48 <_ikke_> This works locally, why does it not work on travis? https://travis-ci.org/alpinelinux/aports/builds/393337458?utm_source=github_status&utm_medium=notification 2018-06-17 20:08:25 <_ikke_> Trying to make the git test suite to work, probably still a long way to go. Currently I'm running against musl iconv not adding a BOM to utf-16 encoded files (While the test suite expects it to be there) 2018-06-17 20:08:34 <_ikke_> Any idea how to deal with that? 2018-06-17 20:26:26 Maybe ask the musl folks? 2018-06-17 20:26:53 <_ikke_> yeah, perhaps 2018-06-17 20:35:32 <_ikke_> so apparently it's expected "plain UTF-16 and UTF-32 do not process or honor BOM," 2018-06-17 20:38:01 https://github.com/alpinelinux/aports/commit/a504c4ae694e9d92cfae6b9af6f008118939bb73 2018-06-17 20:38:15 why we need an extra package for static libraries? 2018-06-17 20:39:02 aren't *.a files included in -dev package already if they are exist? 2018-06-17 22:30:11 they should be 2018-06-17 22:30:14 jirutka: ? 2018-06-17 22:51:23 kaniini: work's been underway on a pypy APKBUILD, i recall you having some opinions about it 2018-06-17 22:51:43 I'd like to get it in so would like to know your take 2018-06-17 22:56:25 my take is that i do not care 2018-06-17 22:56:29 do what you need to do 2018-06-17 22:57:13 there is no point in caring since there has been no push to remove python2 despite it being dead in a little under 18 months 2018-06-18 00:11:53 aight 2018-06-18 06:25:57 i wasn't sure if i should up the priority of bug #9018 - to me IPv6 address assignment on VLAN interfaces being broken seems fairly critical 2018-06-18 06:26:35 particularly for a distribution which is often used on routers 2018-06-18 06:32:10 the other thing we seem to have quite an old version of ifupdown https://pkgs.alpinelinux.org/package/edge/main/armhf/ifupdown 2018-06-18 06:32:17 https://salsa.debian.org/debian/ifupdown/blob/master/debian/changelog 2018-06-18 09:29:47 ncopa: btw, did you looked at the pkcs12 bug, https://bugs.alpinelinux.org/issues/8991 2018-06-18 09:31:20 IMO, it would be serious bug to release 3.8 if such important (security related) command does not work 2018-06-18 09:34:50 do the Alpine uses portable version of the libressl, I'm ready to look at source to find what could be a problem with pkcs12 2018-06-18 09:38:56 heyhey 2018-06-18 09:49:30 mps: i didnt look at it yet 2018-06-18 09:50:45 I'm looking at the source but don't understand it's cli parameters parsing. 2018-06-18 09:52:20 huh, I will try to find bug. Are there libressl IRC channel, maybe I should ask there 2018-06-18 10:08:26 the mountainpeople still sleep 2018-06-18 10:20:12 mps, i just tried but i can read p12 fine. 2018-06-18 10:24:53 clandmeter: what is your hversion of the libressl. mine is libressl-2.7.4 2018-06-18 10:30:10 mps, shouldnt you use an applet like -info? 2018-06-18 10:30:41 I can read with p12 (pkcs12) with stable version (AL 3.7) libressl-2.6.4-r2, but not on edge 2018-06-18 10:31:13 http://tpaste.us/8xq8 2018-06-18 10:32:13 clandmeter: I know, but what version do you use 2018-06-18 10:32:25 edge 2018-06-18 10:32:51 libressl-2.7.4 ? 2018-06-18 10:33:20 LibreSSL 2.7.4 2018-06-18 10:35:17 huh, strange. Same pkcs12 file can be read with stable (3.7, libressl-2.6.4) but the same file can't read with libressl-2.7.4 on edge 2018-06-18 10:40:01 mps, i used the one provided by https://itv.mit-xperts.com/clientssl/issue/dload/index.php?id=1571753451 2018-06-18 10:40:28 ncopa: clandmeter: looks like it started to work, for totally inapprehensible reason for me. 2018-06-18 10:41:06 there must be ghosts in my computer 2018-06-18 10:41:52 or the shell is problematic, I will investigate what was the culprit 2018-06-18 10:42:28 maybe some NLS character, but not sure 2018-06-18 10:44:08 but, it works. I will close the bug report. Sorry for wasting yours time 2018-06-18 11:27:30 np 2018-06-18 11:46:02 ncopa: clandmeter: found a reason for pkcs12 behaviour, somehow I entered '–' (226 decimal) for -in parameter instead of '-' (45 decimal). 2018-06-18 11:46:32 ncopa, what are the changes? 2018-06-18 11:46:42 mps, ah, nice you foudn the issue. 2018-06-18 11:47:07 yes, invalid - character 2018-06-18 11:47:44 ncopa: new bluez 5.50 depends on ell (https://01.org/ell), should I send an aport to add it to main/ ? 2018-06-18 11:48:24 it could be that I 'copy/pasted' it from somewhere and countinued using it from shell history 2018-06-18 11:49:15 looks like I cannot close bug report, probably because I'm not developer? 2018-06-18 11:53:08 someone who is allowed, please close https://bugs.alpinelinux.org/issues/8991 2018-06-18 11:55:06 closed 4 minutes ago... 2018-06-18 12:17:01 clandmeter: the changes in rc5 is linux-firmware 2018-06-18 12:17:10 you can apk add linux-firmware-something 2018-06-18 12:17:12 and save space 2018-06-18 13:44:53 ncopa: nice! 2018-06-18 13:45:01 been waiting for this :D 2018-06-18 13:53:59 Hi, would you mind explaining a little bit about new linux-firmware change? Removing linux-vanilla and adding it again will still pull all linux-firmware-* 2018-06-18 13:54:23 tmh1999: try adding linux-firmware-none first 2018-06-18 13:55:03 if that's the case, scripts where adding linux-vanilla and bootloader will still pull in linux-firmware-* by default ? 2018-06-18 13:55:24 and we may need to add linux-firmware-none along with linux-vanilla 2018-06-18 13:55:26 yes, and I think that is a sane default 2018-06-18 13:55:47 ncopa, do you want this ? ^ 2018-06-18 13:55:52 people usually don't know which firmware they need 2018-06-18 13:55:55 thanks azarus 2018-06-18 13:56:03 tmh1999: did it work? nice 2018-06-18 13:56:12 i actually haven't tried it myself ;P 2018-06-18 13:56:19 lol I trusted you, trying ... 2018-06-18 13:56:24 hehehe 2018-06-18 13:56:39 okay that seems working o/ 2018-06-18 14:03:40 problem could be net/wifi card firmware, other could be added if the machine boot and have network 2018-06-18 14:05:49 so, it would be wise to have some spare medium (usbdisk, sdcard …) with firmware file (possibly all) to copy to /lib/firmware 2018-06-18 14:37:36 ncopa, can you check if this is ok? http://tpaste.us/VR61 2018-06-18 14:53:06 is the second hunk necessary? 2018-06-18 14:53:19 i dont think you can have different descriptions for differente arches 2018-06-18 14:54:04 i dunnop 2018-06-18 14:54:46 i only generated the aarch64 rpi profile image. 2018-06-18 14:55:07 thats why i send you the patch, the scripts are bit difficult to read. 2018-06-18 14:56:11 i wonder what to do with rpi kernel firmwares. 2018-06-18 14:57:56 we currently depend on kernel.org firmware brcm but thats not enough. 2018-06-18 15:01:49 ncopa: on the other topic, I managed to create the iso image for s390x, but it's kind of ugly... Will submit a pr later today. 2018-06-18 15:20:12 clandmeter: I'm facing : ERROR: DHCP requested but not present in initrd when using ip=dhcp for kernel parm. It seems relate to busybox-initscripts. What should I do ? 2018-06-18 15:20:53 https://git.alpinelinux.org/cgit/mkinitfs/tree/initramfs-init.in#n204 2018-06-18 15:21:35 missing 'net' in initramfs ? 2018-06-18 15:22:19 'nework' 2018-06-18 15:22:22 'network' 2018-06-18 15:23:24 yes, bingo. PEBKAC. 2018-06-18 15:41:30 ACTION slaps tmh1999 with a keyboard 2018-06-18 15:41:44 :P 2018-06-18 15:41:52 next time its the chair ;-) 2018-06-18 15:42:16 <_ikke_> lol 2018-06-18 15:42:22 I might just take your chair, needing one atm haha 2018-06-18 15:54:39 why is /lib/firmware/iwlwifi-7265-13.ucode in linux-firmware-other and not in linux-firmware-iwlwifi? 2018-06-18 15:57:13 ncopa, i have this change for linux firmware: http://tpaste.us/m5kJ 2018-06-18 15:58:54 clandmeter: could you rebase that? 2018-06-18 15:59:04 check: https://git.alpinelinux.org/cgit/aports/commit/?id=98758e675c63be3cc2c1a6fb010118c8a2b4a9a0 2018-06-18 16:34:47 @ncopa: debug_init is not working on power8 or P9 machines. i have still not successfully netbooted a alpine kernel on ppc64le and without debug_init, totally "blind" 2018-06-18 16:36:09 gonna ping breno 2018-06-18 16:40:49 https://git.alpinelinux.org/cgit/mkinitfs/tree/initramfs-init.in#n277 2018-06-18 16:42:21 back in the day I didn't know it, I put set -x in initramfs-init, rebuild mkinitfs.apk myself and install it, so I can see initramfs log ... 2018-06-18 16:43:12 *didn't know debug_init 2018-06-18 16:46:26 thank you - i havent built an apk yet but looks like today might be the day. now what if i extracted initramfs - put in an init with set -x and then cpio'd it back up? 2018-06-18 16:46:54 does it have to be in the mkinitfs.apk? 2018-06-18 16:48:08 mickibm : https://git.alpinelinux.org/cgit/mkinitfs/tree/mkinitfs.in#n152 2018-06-18 16:48:39 so this comes from me (aka hacky), extract your initramfs, edit your init, and use above link to cpio'd it back 2018-06-18 16:50:43 I'd recommend you check why debug_init (console output from KVM?) is not working rather than doing this 2018-06-18 16:51:48 cpio command is similar to mine: find . | cpio -H newrc -o | gzip -9 > $PXE_DIR/pxe-initramfs 2018-06-18 16:52:44 since its on power, booting via Petitboot on remote bare metal machine... really not sure how to debug this 2018-06-18 17:37:10 this is as far as I get netbooting ppc64le (since debug_init has other issues): https://gist.github.com/jpadams/0291c3bd1d52bb15548bfe830884577f 2018-06-18 18:56:06 ncopa, clandmeter: re create bootable iso image for s930x : http://tpaste.us/9KV6. How do you think ? 2018-06-18 19:50:31 ncopa:firstboot will have issues when device does not have an rtc. 2018-06-18 19:51:22 i guess it needs to depend on ntpd and wait for it to get current time. 2018-06-19 01:09:54 re s390x iso image : https://github.com/alpinelinux/aports/pull/4551. gtg. 2018-06-19 01:11:17 this iso should work for KVM. 2018-06-19 01:11:34 and KVM only. 2018-06-19 01:15:58 I think I kind of finish my TODO for s390x for 3.8. Next thing is fixing testing packages. 2018-06-19 10:03:18 is it really intended that algibot discloses these security issues? 2018-06-19 10:06:34 hmm 2018-06-19 10:06:51 i can check if we can remove security 2018-06-19 10:26:35 ncopa, i think i have an issue. 2018-06-19 10:26:53 update-kernel does magic to stip firmware. 2018-06-19 10:27:12 strip 2018-06-19 10:27:40 looks like it only installs firmware when it finds references in modules. 2018-06-19 10:28:25 yes, that is so we dont pull in unused firmware 2018-06-19 10:28:37 but some fw also need nvram from txt. 2018-06-19 10:29:11 i just spend one hour to find out why im missing so many things in my modlop. 2018-06-19 10:30:20 i suppose we need an option for update-kernel to include all firmware then 2018-06-19 10:31:11 or are there some way to detect which fw need nvram from txt? 2018-06-19 10:37:04 for rpi it has the same name. 2018-06-19 10:37:12 so that could be simple 2018-06-19 10:38:12 brcm/brcmfmac43430-sdio.bin 2018-06-19 10:38:12 brcm/brcmfmac43430-sdio.txt 2018-06-19 10:38:48 yep 2018-06-19 10:39:09 i can add a fix to update-kernel to include the txt if it exists. 2018-06-19 10:39:36 what about TDA7706_OM_v3.0.2_boot.txt and ar3k/30101coex/RamPatch.txt 2018-06-19 10:39:42 how do we detect if those are needed 2018-06-19 10:40:01 btw, i added the bluetooth fw also to linux fw, but then i found out we also ship a seperate bt fw pkg. 2018-06-19 10:40:28 and ofc its not included with update-kernel 2018-06-19 10:40:54 if we use tmpfs boot, we cant include more fw because of modloop 2018-06-19 10:41:04 or we need to copy it to sd. 2018-06-19 10:41:15 the fw needs to be inclued in the modloop 2018-06-19 10:41:36 i dont think we do that for bluetooth. 2018-06-19 10:42:04 can we include the bluetooth firwmare with the linux-firmware package? 2018-06-19 10:42:11 i think if we detect a module that needs fw, and we have the fw, and we have the txt also, we could include the txt? 2018-06-19 10:42:33 that seems to apply for brcm/brcmfmac43430-sdio.bin only 2018-06-19 10:42:40 but i think that is what we want to do 2018-06-19 10:42:45 there are 2 2018-06-19 10:42:54 rpi has 2 wifi fw's 2018-06-19 10:43:15 i already included the bt fw in linux-firmware 2018-06-19 10:43:27 the are on the top in the filelist. 2018-06-19 10:43:28 find /lib/modules -type f -name "*.ko" | xargs modinfo -F firmware | sort -u | while read f; do if [ -e /lib/firmware/${f%.*}.txt ]; then echo $f; fi; done 2018-06-19 11:00:35 ncopa: that is for all installed modules? 2018-06-19 11:02:32 what about to check needed firmware only for loaded modules 2018-06-19 11:03:55 that is the next step 2018-06-19 11:04:32 I tried: lsmod | awk -e '{ print $1}' | xargs modinfo -F firmware 2018-06-19 11:05:06 it shows which firmware are needed for loaded modules on my box 2018-06-19 11:19:28 and there you have the lkey how to do the proper apk add linux-firmware- 2018-06-19 11:20:35 ncopa, i can do this http://tpaste.us/ML75 2018-06-19 11:20:41 but that still does not include bt fw. 2018-06-19 11:22:44 use ${FW%.*}.txt 2018-06-19 11:23:03 so it oes not look for the non-existing brcm/brcmfmac43430-sdio.bin.txt 2018-06-19 11:24:26 ah yes you are right 2018-06-19 11:24:32 /o\ 2018-06-19 12:20:36 ncopa, do you know why we ship an ovl file called dhcp with rpi releaseS? 2018-06-19 12:21:23 it sets interface to dhcp, but it doesnt start at boot. is that a feature? 2018-06-19 12:26:19 PureTryOut[m], i tried ethernet and i can get full 11MB/s and still get around 10ms ping times to 1.1.1.1 2018-06-19 12:27:16 clandmeter: i dont know 2018-06-19 12:27:48 fabled, any idea what the ovl is for? 2018-06-19 12:37:01 clandmeter: ok then wtf is wrong with my RPi lol. it seems literally no one can reproduce it, but I'm having it consistently and reinstalls do not work 2018-06-19 12:47:38 PureTryOut[m], if you want i can share you my aarch64 build. 2018-06-19 12:47:45 not sure it makes any difference. 2018-06-19 12:47:59 maybe your cables are switch is not 100% 2018-06-19 12:48:03 or* 2018-06-19 12:54:23 ncopa, http://tpaste.us/05pE this works but maybe we should have a more general approach for bt fw? 2018-06-19 13:04:12 mayve check if brcm was pulled in, and if it was, add the bt firmware? 2018-06-19 13:06:07 whats wrong with the armhf rpi kernel build? 2018-06-19 13:13:21 ncopa, i dont know, its not very verbose about it. can it be the addition i made for dtb files? 2018-06-19 13:14:28 sure, you'd have to tell me how to install it though (I'm guessing just write the image to sd card?) as normally I do it via our pmbootstrap tool 2018-06-19 13:14:58 but tonight, I don't ave time for it right now 2018-06-19 13:14:58 PureTryOut[m], just copy it to your sd (the contents) 2018-06-19 13:15:05 thats it. 2018-06-19 13:15:12 and make sure your partition is fat 2018-06-19 13:34:38 does it need to be partitioned in a particular way? 2018-06-19 13:41:36 nope 2018-06-19 13:41:47 i think first partition needs fat and thats it. 2018-06-19 13:48:36 oh do I just need one big fat partition (I seem to be behind in chat again)? 2018-06-19 13:49:11 yes if you want to run from ram completely 2018-06-19 14:10:56 ncopa, what do you mean check if brcm is pulled in? 2018-06-19 14:18:44 clanbdmeter: i mean, the loop above will pull in the needed firmware and copy it to $MODLOOP dir 2018-06-19 14:19:16 check in $MODLOOP dir if brcm was copied, and if it was, then also copy the bt firmware 2018-06-19 14:19:45 do that instead of check if kernel is rpi 2018-06-19 14:25:21 + 2018-06-19 14:25:21 + [ "$CARCH" = "aarch64" ] && mv "$INSTALL_DTBS_PATH"/broadcom/*.dtb \ 2018-06-19 14:25:21 + "$INSTALL_DTBS_PATH" && rmdir "$INSTALL_DTBS_PATH"/broadcom 2018-06-19 14:25:21 } 2018-06-19 14:25:21 2018-06-19 14:25:44 clandmeter: i think if $CARCH is not aarch64, the function will return false 2018-06-19 14:26:08 i pushed a fix 2018-06-19 14:26:24 correct fix. 2018-06-19 14:26:26 thanks 2018-06-19 14:26:29 :) 2018-06-19 14:39:54 ncopa, http://tpaste.us/aMyZ 2018-06-19 14:40:29 or better http://tpaste.us/qoea 2018-06-19 14:44:07 beside rpi, anything else we need to fix for 3.8 ? 2018-06-19 14:44:28 clandmeter: yes, looks good 2018-06-19 14:44:38 then it will work even if we rename linux-rpi to something else 2018-06-19 14:45:02 or if some other kernel also includes brcm driver and firmware 2018-06-19 14:46:33 few weeks ago, azarus noticed problem with mdocml man pages. If he is here he could better explain problem. 2018-06-19 14:47:11 I think it should be resolved, but I'm not sure if it is blocker for release 2018-06-19 14:48:25 azarus: ^ 2018-06-19 15:25:22 tmh1999: i think we only need to write release notes 2018-06-19 15:25:36 :) 2018-06-19 15:43:36 http://tpaste.us/xeqD 2018-06-19 15:43:47 ncopa: I must miss something 2018-06-19 15:43:57 checking irc log 2018-06-19 15:46:37 i guess we dont need to mention infra changes? 2018-06-19 16:11:21 tmh1999: we could expand the "significant upgrades" section a bit. maybe mention ruby 2.5.1? jirutka might have some further suggestions… 2018-06-19 16:12:08 +1 2018-06-19 16:19:53 mps: yup 2018-06-19 16:20:48 with modcml-apropos (or other mandoc packages), when one issues "man printf" it displays printf(1p), not printf(1) 2018-06-19 16:21:10 also, I got blender to build again 2018-06-19 16:22:05 I'll send that patch 2018-06-19 16:22:22 please review? 2018-06-19 16:22:34 was disabled due to build errors 2018-06-19 16:24:29 i only tested on x86_64. could people please test on i386, and maybe ppc64le? had build errors there before 2018-06-19 16:28:22 i'll only reenable it on x86_64 for now, since I dunno if it builds anywhere elese 2018-06-19 16:28:25 else* 2018-06-19 16:29:05 https://patchwork.alpinelinux.org/patch/4013/ 2018-06-19 16:36:53 azarus: thanks for memo 2018-06-19 16:45:13 http://tpaste.us/yk6g 2018-06-19 16:53:22 \o/ 2018-06-19 17:02:29 hi, regarding release notes, should we mention something about grsec/PaX being dropped? 2018-06-19 18:01:32 oooh congratz on the release guys! 2018-06-19 18:02:59 <_ikke_> PureTryOut[m]: ? 2018-06-19 18:20:03 _ikke_, ? 2018-06-19 18:20:27 HRio: yes we should mention pax/gresc. good point 2018-06-19 18:21:02 New rc release ;) 2018-06-19 18:21:04 i did rc6 so we can test the latest rpi firmware changes 2018-06-19 18:21:34 I forgot my rpi 2018-06-19 18:24:51 tmh1999: great! thanks! 2018-06-19 18:25:43 i added a line about end of support for grescurity: http://tpaste.us/YvPw 2018-06-19 18:25:54 unofficial* grsec 2018-06-19 18:26:05 rpi are 2 diff things 2018-06-19 18:26:23 aarch64 can also be regular rpi3 and even some rpi2 2018-06-19 18:26:36 azarus: testing repos will have to wait til after release 2018-06-19 18:42:39 ncopa: OK, no problem 2018-06-19 18:53:15 so rc6 is using same 4.14.50 kernel as rc5? 2018-06-19 18:53:24 or did my upgrade not work 2018-06-19 18:56:26 yes 2018-06-19 18:58:50 thanks 2018-06-19 19:29:08 yes clandmeter please rewrite the rpi3, aarch64 thing. I was not so sure. 2018-06-19 19:51:56 ncopa: rc6 images for ppc64le + s390x may need your touch to be online 2018-06-19 19:53:12 tmh1999, http://tpaste.us/5YqM 2018-06-19 19:53:30 beautiful 2018-06-19 21:02:47 tmh1999: you could also add vim 8.1.XXX to the significant package updates section, the previous release shipped vim 8.0.XXX maybe also R 3.5? 2018-06-19 21:30:50 nmeum: you could add it and post it here and everyone can see. I'm not specifically in charge of it so latest version will probably be picked up :D 2018-06-19 22:12:11 is ssh_key supported in 3.8 as a kernel boot arg? we can only ssh in when the ssh key is in the apkovl 2018-06-19 22:15:39 i see it in init, in my_opts it has ssh_key but does it actually use the key anywhere? 2018-06-19 22:19:10 sorry, myopts 2018-06-19 22:31:10 seems like firstboot is not getting the kernel options so we are forced to stick the priv key into the apkovl 2018-06-19 22:32:46 mickibm: so I use it to netboot s390x : http://tpaste.us/v785. vmlinuz-vanilla and initramfs-vanilla are downloaded from rc5, same like modloop url. 2018-06-19 22:33:03 I don't use apkovl. 2018-06-19 22:33:11 *don't have to 2018-06-19 22:33:27 the purpose of ssh_key is to eliminate the use of apkovl for ssh keys. 2018-06-19 22:33:40 which is considered more flexible. 2018-06-19 22:33:46 imho 2018-06-19 22:35:33 absolutely agree. here is our boot args: https://gist.github.com/mtarsel/b4166dfcce07df2dc92f4e591ec4c42a 2018-06-19 22:37:09 we are using a python server as the webserver and not even seeing the request made to get the ssh key. seems to me that firstboot is not starting 2018-06-19 22:37:41 is ppc64le vmlinux not shipping firstboot somehow? 2018-06-19 22:38:18 does ppc64le support download kernel and initrd from remote ? That seems cool. ssh_key only accepts https and ftps. ftp and http are not accepted. 2018-06-19 22:38:57 ahhh, ok. we are using http and yes ppc64le def supports netboot 2018-06-19 22:38:58 https://git.alpinelinux.org/cgit/aports/tree/main/openrc/firstboot.initd#n24 2018-06-19 22:39:50 soo why? its a public key 2018-06-19 22:41:06 probably because of mitm ? 2018-06-19 22:42:37 not supporting http/ftp might be a little trouble for local installation, I agree. 2018-06-19 22:43:30 if you or your users poke the core team enough, maybe it can be changed :D 2018-06-19 22:49:12 but like, this just changed recently...? thank you very much 2018-06-19 22:49:59 ...trying to git blame but console is being crappy 2018-06-19 22:50:05 yes, 7 days ago : https://git.alpinelinux.org/cgit/aports/log/main/openrc/firstboot.initd. 2018-06-19 22:50:25 maaannnn 2018-06-19 22:50:31 :D 2018-06-19 22:50:52 -__- 2018-06-19 22:51:00 desperate time, desperate measure. 2018-06-19 22:51:55 well I developed a habit to monitor git log at git.a.o, and #alpine-commits ... 2018-06-19 22:52:30 sweet, that will be helpful. thank you :) 2018-06-19 22:52:35 +1 2018-06-20 03:55:30 Hi all 2018-06-20 03:56:02 This is my first time here, and I'd like to have some details about Alpine Linux 2018-06-20 04:19:13 did you already check the website? https://alpinelinux.org/about/ is there anything specific you would like to know? 2018-06-20 04:34:43 hi nmeum, thanks for attention. In fact, I tried to check about this distro at distrowatch 2018-06-20 04:35:10 now, I'm going to have a check throughout this linke you've passed me. Really thank you ! 2018-06-20 04:35:51 basically I'd like to know if alpine is based on debian or red hat or any other well known linux distro 2018-06-20 04:36:37 no, it's not. Alpine is its own thing. 2018-06-20 04:37:27 fine, skarnet. Can I use it both in servers and desktop ? 2018-06-20 04:37:37 Yes, you can. 2018-06-20 04:38:06 I'm not sure exactly what desktops are supported on Alpine, though. I know about xfce; not sure about others. 2018-06-20 04:38:23 ok, please, where does this Linux distro project comes from ? USA ? 2018-06-20 04:38:40 no, it's mostly EU-based. 2018-06-20 04:38:44 Where does it come from ? 2018-06-20 04:38:56 you mean Europe ? 2018-06-20 04:38:58 from people's heads? :) 2018-06-20 04:39:04 yes, Europe. 2018-06-20 04:39:25 oh, people from Europe... very far away from here.... 2018-06-20 04:39:32 The project lead is from Norway, for instance, and there are a lot of EU contributors. A few from the USA as well. 2018-06-20 04:39:52 Norway ? My God.... 2018-06-20 04:40:07 very Beautiful Land ! 2018-06-20 04:40:41 ok, I intend to use it with kernel linux 4.16,0 2018-06-20 04:40:51 with btrfs 2018-06-20 04:41:39 one more question, if possible, please: is that possible using mate de in alpine ? 2018-06-20 04:42:40 using what? 2018-06-20 04:42:59 it's in the repos 2018-06-20 04:43:04 oh, a desktop environment 2018-06-20 04:45:55 <_ikke_> https://pkgs.alpinelinux.org/package/edge/community/x86_64/mate-desktop 2018-06-20 04:56:30 ok skarnet, thanks ! Thanks too, TBB and _ikke_ ! I'll check it, for mate-desktop is my preference for de 2018-06-20 05:09:09 bye all, and thanks for attention ! 2018-06-20 05:58:39 tmh1999, did you try ssh_key? 2018-06-20 05:58:49 yes 2018-06-20 05:59:05 solo? 2018-06-20 05:59:09 or did you add more boot opts? 2018-06-20 05:59:42 here is what I use : http://tpaste.us/Q4gz 2018-06-20 06:00:05 ok 2018-06-20 06:00:21 it doesnt work without ip and repo 2018-06-20 06:00:55 ip and repo are a must for netboot I guess 2018-06-20 06:01:15 yes but ssh_key can also be nice for non netboot 2018-06-20 06:01:42 I see. Not sure how to append kernel cmdline with iso boot ? 2018-06-20 06:01:59 i guess if we request network related functions from cmdline we should default to dhcp 2018-06-20 06:02:27 you can boot from usb 2018-06-20 06:02:42 who uses cdrom anyway :) 2018-06-20 06:03:12 for instance headless installs its nice to have. 2018-06-20 06:04:33 i guess we could init network when ssh_key is found. 2018-06-20 06:05:28 hum. let me think. 2018-06-20 06:06:03 house mates decide to move furnitures in 2 am... 2018-06-20 06:07:16 that's many logic to check 2018-06-20 06:07:39 say, I only add ssh_key but no ip, it should default to ip=dhcp 2018-06-20 06:08:07 if ssh_key and ip=, then configure_ip() . 2018-06-20 06:08:22 we alraedy default to dhcp 2018-06-20 06:08:41 i think adding configure_ip to the current check would be enough. 2018-06-20 06:09:07 okay sounds like a plan 2018-06-20 06:09:33 ncopa never said anyting regarding the default http repo patch 2018-06-20 06:09:58 i dont think i can spend much time on it today. 2018-06-20 06:10:11 so im going to close my irc window :) 2018-06-20 06:10:14 ttyl 2018-06-20 06:10:18 you mean hard code alpine_repo ? 2018-06-20 06:10:22 okay :) 2018-06-20 06:10:40 yes have a default so you dont have to append it to cmdline 2018-06-20 06:10:47 my guess ncopa will make release today. 2018-06-20 06:11:05 probably 2018-06-20 06:11:14 we will see. 2018-06-20 06:11:43 I once proposed hard code alpine_repo in init before, but it was not so nice. maybe you can make it fit in better. 2018-06-20 06:31:05 do we want to upgrade ffmpeg to 4.X before 3.8 is released? The latest ffmpeg release fixes various integer overflows and since 4.X introduces an soname bump upgrading to it before 3.8 is released might make it easier to backport fixes in the future 2018-06-20 11:01:43 nmeum there's some changes in ffmpeg that needs review https://github.com/alpinelinux/aports/pull/4079 2018-06-20 11:02:44 main question is libressl & non-free stuff 2018-06-20 15:15:18 502 Bad Gateway on https://git.alpinelinux.org/ ... 2018-06-20 15:15:38 Yes we are working on it 2018-06-20 15:15:56 clandmeter: K, good. 2018-06-20 17:25:25 Hrio: hi 2018-06-20 17:28:54 im available here if you wanna discuss the http ssh_key PR 2018-06-20 17:55:23 HRio: ^ 2018-06-20 18:19:41 mickibm: tmh1999 sorry AFK 2018-06-20 18:21:13 mickibm: if only one key, can it not be provided directly with the KOPT or do you run in to problems with maximum cmdline size? 2018-06-20 18:25:09 I don't understand the "check that the ssh_key file is only 1 line" part. I think the proposal of ssh_key_plain or ssh_key_http or http_enabled is pretty good. 2018-06-20 18:25:30 mickibm ^ 2018-06-20 18:27:56 ill try using the cmdline arg with a single key now 2018-06-20 18:29:58 tmh1999: the idea being that only one key exists in the public file. if you cannot ssh in due to MITM there will be a host key verifcation error 2018-06-20 18:30:27 mkickibm: how about this: http://tpaste.us/jDB5 2018-06-20 18:30:44 mickibm: type sorry 2018-06-20 18:32:04 i think the ssh_key_http arg would be best because it will still keep it secure. is that a patch for using the public key right in the cmdline? 2018-06-20 18:32:52 ..keep it secure and still be flexible to allow http 2018-06-20 18:33:20 yes, it uses https/ftps by default, but if ssh_key_plain is detected, it uses http/ftp 2018-06-20 18:33:26 updated, a little simpler: http://tpaste.us/De5a 2018-06-20 18:40:26 tmh1999: i think that looks ok, with a patch here https://github.com/alpinelinux/mkinitfs/blob/master/initramfs-init.in for $KOPT_ssh_key_plain and it would like like 'ip=dhcp ssh_key_plain=http://mykey 2018-06-20 18:40:35 look like* 2018-06-20 18:40:50 HRio: any thoughts? 2018-06-20 18:45:44 http://tpaste.us/7NJO 2018-06-20 18:47:50 I paste in that pr 2018-06-20 18:50:46 tmh1999: thank you! 2018-06-20 18:51:05 +1 2018-06-20 18:51:57 you need to create another pr to http://github.com/alpinelinux/mkinitfs/ though 2018-06-20 18:53:50 sure thing 2018-06-20 18:57:18 clandmeter: could you send me your aarch64 image for the RPi3? 2018-06-20 18:57:40 PureTryOut[m]: you can try the latest on mirror 2018-06-20 18:57:45 latest 3.8 rc 2018-06-20 18:58:02 clandmeter: do you agree with ssh_key_plain ? 2018-06-20 18:59:11 clandmeter: oh, but don't the "regular" Alpine RPi installs use that diskless setup? and where would I find that mirror? 2018-06-20 18:59:35 dl-cdn.alpinelinux.org 2018-06-20 18:59:40 (found the mirror btw) 2018-06-20 18:59:53 yes it runs from memory 2018-06-20 19:01:41 ok well I won't keep using it then, but I guess it's fine for testing 😛 so just extract it to a fat32 filesystem? 2018-06-20 19:02:09 yes 2018-06-20 19:06:20 does it have sshd enabled btw (before initial setup)? 2018-06-20 19:06:35 no 2018-06-20 19:10:14 ok so replugging my keyboard and monitor it is... 2018-06-20 19:14:51 well I get no monitor output 2018-06-20 19:14:52 I'm not sure if it actually booted 2018-06-20 19:15:07 which tarball did you try? 2018-06-20 19:15:13 ah shit I forgot to mark the partition as bootable, hold on 2018-06-20 19:15:33 im not sure thats needed 2018-06-20 19:17:18 well, that didn't make a difference 2018-06-20 19:17:23 I used https://dl-4.alpinelinux.org/alpine/v3.8/releases/aarch64/alpine-rpi-3.8.0_rc6-aarch64.tar.gz 2018-06-20 19:18:27 rpi3? 2018-06-20 19:19:02 yes, the non + one 2018-06-20 19:19:29 same as mine which boots fine. 2018-06-20 19:19:35 it booted our aarch64 pmOS image fine before 2018-06-20 19:19:44 you have all the files in the root of sd? 2018-06-20 19:19:51 and you are sure its fat32? 2018-06-20 19:20:15 yeah, just extracted the image normally 2018-06-20 19:20:17 yes I'm sure, `mkfs.fat -F32 /dev/mmcblk0` 2018-06-20 19:21:12 then idk 2018-06-20 19:21:17 should work 2018-06-20 19:25:57 tmh1999: https://github.com/alpinelinux/mkinitfs/pull/29 2018-06-20 19:26:34 recreated the image, again no luck 2018-06-20 19:27:04 but I can boot a pmOS image using the Alpine testing repos though. maybe you can help me out with the networking issue there? 2018-06-20 19:29:38 not sure how i would be helpful 2018-06-20 19:31:45 oh well too bad. why did you want me to boot the 3.8 image then? 2018-06-20 19:32:30 because i know i dont have network issues. 2018-06-20 19:32:57 ah yeah ok. too bad it won't boot 😞 2018-06-20 19:34:32 sorry :| 2018-06-20 19:35:32 I have some free time to offer to help but I don't have a rpi. Will get one soon... 2018-06-20 20:07:09 fixed my commits, thanks: https://github.com/alpinelinux/mkinitfs/pull/30 2018-06-20 20:35:28 1 2018-06-20 20:37:02 hi, trying to mount vfat with fmask=0027 but it will not change from 0022. fstab: /dev/sda1 /media/sda1 vfat ro,relatime,fmask=0027,dmask=0022,errors=remount-ro 0 0 does not work either. 2018-06-21 01:55:08 UUID="4FAE-7F8B" /mnt/usb vfat user,umask=000,utf8,flush,noauto 0 0 same here. Still Operation not permitted 2018-06-21 01:56:15 ill just make that stick a rootfs. should eventually be the same with some work 2018-06-21 01:56:24 I think 2018-06-21 06:13:51 morning 2018-06-21 06:13:59 tmh1999: xorriso : FAILURE : Cannot find in ISO image: -boot_image ... bin_path='/boot/merged.img' 2018-06-21 06:13:59 stat: can't stat '/home/buildozer/packages/releases/s390x/alpine-standard-3.8.0_rc6-s390x.iso': No such file or directory 2018-06-21 06:15:19 morning ncopa 2018-06-21 06:18:15 ncopa: should i upgrade to 3.8rc6 in regard to that vlan thing i'm currently on 3.7 2018-06-21 06:18:35 if it effects 3.7 probably effects 3.8 and it would be nice to fix it before final release of 3.8 2018-06-21 06:20:36 i'll do my bets to fix it 2018-06-21 06:20:39 best* 2018-06-21 06:21:02 need to debug the recent update-kernel breakage and iso generation for s390x 2018-06-21 06:21:11 right 2018-06-21 06:21:26 just pm me when you want me to try something :) 2018-06-21 06:22:04 i guess when 3.8 comes out 3.7 would still be supported 2018-06-21 06:22:27 least if https://en.wikipedia.org/wiki/Alpine_Linux#Version_history that is anything to go by :P 2018-06-21 06:22:58 yes, v3.7 will still be supported 2018-06-21 06:53:37 >>> mkimage-s390x: Creating alpine-standard-3.8.0_rc6-s390x.iso 2018-06-21 06:53:38 scripts/mkimage.sh: line 282: mk-s390-cdboot: not found 2018-06-21 06:53:48 this is broken on so many levels... 2018-06-21 07:13:37 clandmeter: did you check if the nvram *.txt got included in the armhf rc6? 2018-06-21 07:29:09 No 2018-06-21 07:38:31 I missed the context, but "No" sounds right 2018-06-21 07:38:52 " did you check if the nvram *.txt got included in the armhf rc6? " 2018-06-21 07:39:24 I was pretty happy supporting clandmeter's "No" without context! 2018-06-21 07:40:59 context addendum: yes its included. 2018-06-21 07:41:03 yeah, but now you can support it with context 2018-06-21 07:44:36 ncopa, i was having issues yesterday with ipxe. 2018-06-21 07:44:41 not sure you tried it recently? 2018-06-21 07:44:54 something with OCSP verification. 2018-06-21 07:45:05 i wonder if i should simply disable it. 2018-06-21 07:48:50 i havent tried ipxe lately 2018-06-21 07:49:48 tmh1999: iso generate for s390x is broken. scripts/mkimage.sh: line 282: mk-s390-cdboot: not found 2018-06-21 08:20:35 parted tests fails on s390x 2018-06-21 08:20:53 the bsd label support does not seem to support big endian 2018-06-21 08:21:14 i searched for patch in fedora for s390x 2018-06-21 08:21:34 and they have 81(!) patches for parted... 2018-06-21 08:21:48 lots of them seem to be related dasd 2018-06-21 08:22:00 <_ikke_> fun times 2018-06-21 08:22:55 i have been thinking of rewrite setup-disk in lua and make a libparted lua module 2018-06-21 08:23:01 but i think that will not work :) 2018-06-21 08:23:11 libparted is just broken apparently 2018-06-21 08:23:38 some of the patches looks really scary, like "prevent segfault when resize vfat" 2018-06-21 08:26:28 jirutka: The WSL Version is now in the store (unlisted, only accessible by link): https://www.microsoft.com/en-us/p/alpine-wsl/9p804crf0395 so if you want to have a look ;-) 2018-06-21 08:29:44 agowa338: thats pretty cool 2018-06-21 08:31:08 ncopa: Thanks, have you a windows device/vm by hand to test? 2018-06-21 08:32:04 i have windows in vmware and my alpine workstation is also dualboot windows 2018-06-21 08:32:27 the only thing i use windows for in practice is to run updates and antivirus 2018-06-21 08:32:33 :) 2018-06-21 08:33:21 ncopa: Ok, but if you have some time to spare, I would like to hear your opinion on how it looks and feels compared to native alpine ;-) 2018-06-21 08:34:24 "time to spare" is an exceptionally rare animal around here.... 2018-06-21 08:35:40 ncopa: I know exactly what you mean. Than let me say it different: "If you feel like not doing what you're supposed to do and waste some time on something else". Does that sound better? 2018-06-21 08:36:03 lol! it does :) 2018-06-21 08:38:54 ncopa: I'm awaiting you're all feedback until I flip the switch to make it public (as in appears in the sore if you search Linux or Alpine) 2018-06-21 08:40:30 ncopa: Hi. The APKBUILD for docker seems to want to enable seccomp support, but doesn't actually. 2018-06-21 09:19:29 need help with APKBUILD, abuild rootpkg wants to make -dev subpackage but it is not needed 2018-06-21 09:19:44 how to disable that 2018-06-21 09:19:57 you should have a line in the APKBUILD, subpackages=... 2018-06-21 09:20:08 remove $pkgname-dev from that line 2018-06-21 09:20:42 huh, I don't have subpackage in APKBUILD 2018-06-21 09:22:10 <_ikke_> mps: MIght be that there are files that require a -dev package? 2018-06-21 09:22:20 could you point me to some package in aports, I can look at it as sample 2018-06-21 09:23:07 _ikke_: no, it is simple user space utility, simple-mtpfs 2018-06-21 09:23:20 https://github.com/phatina/simple-mtpfs 2018-06-21 09:24:33 here is the APKBUILD http://tpaste.us/WP8B 2018-06-21 09:29:34 there is no some flag/var for APKBUILD to abuild 'do not make -dev' subpackage? 2018-06-21 09:30:10 s/to abuild/to tell abuild/ 2018-06-21 09:30:27 <_ikke_> mps: -dev is also used for things like headers 2018-06-21 09:31:37 undertand, but in this case (simple-mptfs) it is not needed 2018-06-21 09:32:10 <_ikke_> mps: usually when you don't have subpackages, it will not try to create it, just complain about it when required 2018-06-21 09:32:34 can you put the output of abuild in tpaste.us? 2018-06-21 09:32:47 oh wait 2018-06-21 09:32:56 subpackages="$pkgname-dev $pkgname-doc" 2018-06-21 09:32:59 make that 2018-06-21 09:33:04 subpackages="$pkgname-doc" 2018-06-21 09:33:52 awilfox: that is. It works. 2018-06-21 09:36:03 another question, simple-mtpfs.tar.gz is arhived with it's name twice in root dir 2018-06-21 09:36:33 i.e. tar -tvf shows simple-mtpfs-simple-mtpfs-0.3.0 2018-06-21 09:36:52 simple-mtpfs two times 2018-06-21 09:38:00 so the unpacked it in aports it is src/simple-mtpfs-simple-mtpfs-0.3.0 2018-06-21 09:38:45 should it be renamed after abuild unpack to src/simple-mtpfs-0.3.0 2018-06-21 10:20:58 mercury^: do you have suggestion to a fix? 2018-06-21 10:21:34 mercury^: can you file a bug on bugs.alpinelinux.org with explanation how to reproduce what you see 2018-06-21 10:34:50 clandmeter: I think i'm gonna push this to make it more clear what the intention is: http://tpaste.us/O4pV 2018-06-21 10:43:26 go ahead. 2018-06-21 10:43:36 i still dont 100% those scripts. 2018-06-21 10:43:42 understand* 2018-06-21 10:47:16 ncopa, I also dont like the current way the rpi fw is selected. it has a tight relation to the kernel but this relation is split in two places. 2018-06-21 10:48:34 maybe we should store the hash in the kernel apkbuild and update it when we bump kernel. 2018-06-21 11:00:09 ncopa: in short: docker info does not show seccomp under security options, although the kernel has CONFIG_SECCOMP=y; I have not tried to fix it myself, but I suppose that _runc_buildtags (with value "seccomp") is supposed to be used in building runc. 2018-06-21 11:00:26 But instead that variable is set and then never used. 2018-06-21 11:04:02 (I also cannot get apparmor to work with docker; unlike seccomp it is shown as enabled by "docker info", but docker neither loads its default profile, nor does it want to apply any profile to a process. But that seems to be more of an upstream bug.) 2018-06-21 11:05:11 apk info -R docker shows that so:libseccomp.so.2 is linked 2018-06-21 11:05:26 so i'd think its a config problem? 2018-06-21 11:06:21 Perhaps, but I did not find any indication that one would have to manually enable seccomp. As far as I could gather it should work automatically as long as the kernel has seccomp support. 2018-06-21 11:17:03 Hmm, runc has a BUILDTAGS variable in its Makefile that defaults to 'seccomp'; so perhaps the unused _runc_buildtags is a red herring. 2018-06-21 11:39:44 clandmeter: it looks like it is possible to buy an rtc for rpi 2018-06-21 11:40:04 https://wiki.alpinelinux.org/wiki/Saving_time_with_Hardware_Clock 2018-06-21 11:54:06 ncopa: ok? 2018-06-21 11:54:53 meaning that we cannot assume that if kernel is rpi then there is no rtc 2018-06-21 11:55:03 how did the rdate thing go? 2018-06-21 11:55:09 did we do that? 2018-06-21 11:55:36 i dont remember we selected it specifically for rpi 2018-06-21 11:56:17 i did a small test with rdate 2018-06-21 11:56:24 i think we didnt, it just confirms it was correct thing to not do it 2018-06-21 11:56:26 it seems it fails most of the time. 2018-06-21 11:57:09 i wanted to test it with ipxe, but then i bumped into the next issue. 2018-06-21 11:59:01 ncopa: didnt you test ipxe recently with fetching an iso over http? 2018-06-21 12:00:14 no 2018-06-21 12:01:42 ok ipxe seems to work again. 2018-06-21 12:07:35 ncopa: 2018-06-13 14:31:11 qemu-system-x86_64 --enable-kvm -m 1024 -cdrom http://boot.alpinelinux.org/alpine-ipxe/x86_64/ipxe.iso 2018-06-21 12:09:13 i got error 2018-06-21 12:09:18 permission denied 2018-06-21 12:09:36 probably the same as i had 2018-06-21 12:09:45 im going to disable OCSP 2018-06-21 12:15:50 ok, we can do rc7 now? 2018-06-21 12:17:31 do you think we can apply t hat patch tho hwclock? 2018-06-21 12:18:23 ok 2018-06-21 12:18:30 can you please push it? 2018-06-21 12:18:35 with bumped pkgrel 2018-06-21 12:18:39 yes one min 2018-06-21 12:18:53 ill send it also upstream see what they say 2018-06-21 12:19:00 good! 2018-06-21 12:19:07 hwclock is a dep right? 2018-06-21 12:19:21 for some other serivce? 2018-06-21 12:19:26 yeah 2018-06-21 12:19:26 i think so 2018-06-21 12:19:31 don remember 2018-06-21 12:19:57 looks like it isnt 2018-06-21 12:20:05 i think you can simply rc-update del hwclock 2018-06-21 12:21:07 food is ready and i wanted tag before lunch... 2018-06-21 12:21:35 clandmeter: can you instead just rc-update del hwclock or do you still want push the patch? 2018-06-21 12:21:35 i cant do magic, sorry wrong channel :) 2018-06-21 12:21:54 i can test it 2018-06-21 12:21:59 but i dont think it will work? 2018-06-21 12:22:10 why wouldnt it? 2018-06-21 12:22:10 doesnt initramfs put it back? 2018-06-21 12:22:21 or where does it come from anyways? 2018-06-21 12:22:31 only first boot or if you dont have apkovl 2018-06-21 12:23:04 if you are sure then go ahead. 2018-06-21 12:23:18 it comes from initramfs init 2018-06-21 12:23:26 im 95% sure 2018-06-21 12:23:30 :) 2018-06-21 12:23:33 ok i'll tag it 2018-06-21 12:23:49 ill call your cell if it aint working! 2018-06-21 12:24:09 remember ignore it ;-) 2018-06-21 12:24:37 i'll put my cell on silent :) 2018-06-21 12:25:03 ok. lunchtime 2018-06-21 12:32:39 ACTION rings ncopas cellphone 2018-06-21 12:35:14 ncopa: http://tpaste.us/JgD1 2018-06-21 12:36:44 http://tpaste.us/8x88 2018-06-21 12:38:00 lol i just downloaded rc6 :P 2018-06-21 12:38:52 ah it provides clock and syslog and klogd depend on clock 2018-06-21 12:39:26 hmm yeah and i am still having issues with assigning ipv6 addresses to VLANs 2018-06-21 12:39:38 ncopa: has fixed the script from bitching 2018-06-21 12:39:49 but it seems to still not make link local addresses like it should 2018-06-21 12:40:03 https://dpaste.de/TuPL 2018-06-21 12:40:09 so im thinking its still not working properly 2018-06-21 12:41:07 the only error i see now when eth0.3 starts is 2018-06-21 12:41:20 Error: either "local" is duplicate, or "/64" is a garbage. 2018-06-21 12:41:52 eth0.4 comes up with a link local though and that's exactly the same as eth0.2 and eth0.3 (just with a different address) 2018-06-21 12:43:55 for eth0.3 it didn't even assign the primary address 2018-06-21 12:50:17 how should i get more debug information? 2018-06-21 12:52:32 on that script /etc/network/if-pre-up.d/vlan 2018-06-21 12:53:25 okay that is weird, i tried the same thing on my workstation (network wise) and i am getting link locals on every interface 2018-06-21 13:02:39 ncopa: it seems openrc provides swclock, adding that to runlevel instead of hwclock fixes it. 2018-06-21 13:02:47 its even on the wiki :) 2018-06-21 13:15:50 i wonder if we should try detect /dev/rtc from init.d and use swclock if its missing 2018-06-21 13:16:19 from initramfs i mean 2018-06-21 13:16:24 yeah 2018-06-21 13:17:22 hwclock does have some logic for module loading. 2018-06-21 13:17:28 ncopa: can not add links to the wiki... 2018-06-21 13:17:39 HRio: new account? 2018-06-21 13:17:44 yes 2018-06-21 13:17:47 its normal 2018-06-21 13:17:51 need to wait for x hours. 2018-06-21 13:17:52 i think its a feature 2018-06-21 13:18:01 i think 6 or so 2018-06-21 13:18:16 was trying to add a warning about mdadm part types: https://raid.wiki.kernel.org/index.php/Partition_Types (i.e. add a link) 2018-06-21 13:18:32 looks like rc7 didnt work 2018-06-21 13:18:45 oven is broken? 2018-06-21 13:20:15 K, I will do it an other day. 2018-06-21 13:20:49 HRio: or add it content without links and i can copy them. 2018-06-21 13:21:17 i think there is some feature to trust you, but mediawiki is such a pita. 2018-06-21 13:24:06 0xda is a phonenumber according to media wiki as well :-0 2018-06-21 13:25:36 i wonder if we can manually whitelist some users 2018-06-21 13:25:50 i don tknow what broke with the rc7 2018-06-21 13:28:46 `/54 2018-06-21 13:28:51 scuzi 2018-06-21 13:29:07 Please read up on [https://raid.wiki.kernel.org/index.php/Partition_Types partition types], and why you should consider using 0xda instead of 0xfd. in chapter "Creating the partitions" on https://wiki.alpinelinux.org/wiki/Setting_up_a_software_RAID_array 2018-06-21 13:34:56 clandmeter: can you help in adding that text? 2018-06-21 13:35:13 ncopa: when I specify a seccomp profile manually, I get the error message from here: https://github.com/yongtang/docker/blob/master/daemon/seccomp_disabled.go 2018-06-21 13:35:23 so the daemon is built without seccomp support. 2018-06-21 13:35:56 mercury^: what version is it? 2018-06-21 13:36:07 alpine version and docker version 2018-06-21 13:36:20 alpine 3.7, docker 17.12.1-ce 2018-06-21 13:36:22 HRio: can you add the txt and add replaceme which i need to replace with a link. 2018-06-21 13:37:00 ah you cant save existing urls iu guess? 2018-06-21 13:37:34 then edit the part and tpaste it. ill replace it. 2018-06-21 13:38:56 i'll tag 3.8.0_rc8 now 2018-06-21 13:39:33 clandmeter: do you think we should hold rc8 for the rpi swclock issue? 2018-06-21 13:39:45 not really 2018-06-21 13:39:48 By the way, if I want to contribute a package, should it be based on the master branch? 2018-06-21 13:40:00 its a feature. i dont think its important. 2018-06-21 13:40:12 mercury^: yes 2018-06-21 13:41:27 clandmeter: anything I write it complains its a phone number... 2018-06-21 13:41:35 at this rate rc9 will be out :) 2018-06-21 13:42:03 And is it alright if I leave the Maintainer field empty? 2018-06-21 13:42:12 HRio: when you write? 2018-06-21 13:43:23 cant you edit the part you want to edit, copy the text to tpaste edit it and paste it to me. 2018-06-21 13:45:01 when I do "Save page" 2018-06-21 13:45:19 "Please read up on [https://raid.wiki.kernel.org/index.php/Partition_Types partition types], and why you should consider using 0xda instead of 0xfd." is the text 2018-06-21 13:47:44 hmm does anyone know what happened to the bcm2708-rng module? 2018-06-21 13:48:00 HRio: sorry i dont understnad what you want me to do. 2018-06-21 13:49:04 i think it's built into the kernel now 2018-06-21 13:51:19 clandmeter: sorry was AFK for bit 2018-06-21 13:51:47 I am trying to add the text above in the chapter "Creating the partitions" on this page https://wiki.alpinelinux.org/wiki/Setting_up_a_software_RAID_array 2018-06-21 13:52:43 then click edit, copy the text, edit it and pastbin it for me. 2018-06-21 13:53:38 https://pastebin.com/tW4J3THF 2018-06-21 13:54:28 ok? 2018-06-21 13:54:54 perfect! thx 2018-06-21 13:57:59 clandmeter: most mdadm howtos I have seen are lacking that ref, and then people risk getting them self into a bit of trouble when they later try to do an emergency recovery. 2018-06-21 14:01:18 nice, thx for adding it. 2018-06-21 14:03:42 ncopa: will you tag a stable apk-tools? 2018-06-21 14:08:58 ncopa: re s390x iso, please upgrade s390-tools packages on the builder, it needs r4 to build. currently it's r3. 2018-06-21 14:12:55 i think its ok now 2018-06-21 14:14:42 ncopa: re parted, yes dasd disk devices are bitches. 2018-06-21 14:15:12 rc8 s390x images are uploaded 2018-06-21 14:15:13 is it okay? I just check builder, its s390-tools is still r3. 2018-06-21 14:15:21 let me check if it works 2018-06-21 14:15:32 i made them manually 2018-06-21 14:15:37 so something may still be broken 2018-06-21 14:15:46 why dont upgrade s390-tools ? it's already built. 2018-06-21 14:16:47 s390-tools are only installed when doing release and removed afterwards 2018-06-21 14:16:58 so s390-tools is not installed 2018-06-21 14:18:33 3.8.0 does not boot in vmware for some reason 2018-06-21 14:18:45 Has there been any consideration of reproducible builds for Alpine? 2018-06-21 14:18:55 I don't understand why we need to remove s390-tools. It contains the bootloader. If some how the machine is turned off, it can't boot again. 2018-06-21 14:19:39 s390x iso rc8 works. 2018-06-21 14:20:21 mercury^: i have been thinking of it but not had time to actually work on it 2018-06-21 14:20:43 tmh1999: i remove as much as possible from builders 2018-06-21 14:21:02 but to be specific, we used to have mkinitfs installed 2018-06-21 14:21:19 which is only needed when creating the iso, when making releases 2018-06-21 14:21:41 even bootloader ? do you want me to create s390-tools-zipl subpackage ? 2018-06-21 14:21:50 it caused problems because it was linked to cryptsetup library 2018-06-21 14:22:08 and when cryptsetup upgrade broke abi, things got problematic 2018-06-21 14:22:51 so i removed everything not needed to boot and run the builder container, and only pull in the deps needed to generate the iso when the release i made 2018-06-21 14:22:51 <_ikke_> mercury^: someone was experimenting with reproduducable builds a few days back 2018-06-21 14:23:44 understood. still above question about s390-tools-zipl, which will contains the zipl binary only for bootloader. 2018-06-21 14:24:57 tmh1999: what was the question? 2018-06-21 14:25:51 ncopa: do you want me to split s390-tools with s390-tools-zipl package, which will only contain the zipl binary for the bootloader? Just to be safe. 2018-06-21 14:26:30 or maybe later. anytime. 2018-06-21 14:27:38 i dont understand why not ship it with s390-tools? 2018-06-21 14:28:10 ncopa: in setup-disk, you might want to move the part that deals with a mounted root below the EFI configuration and remove the part where it installs syslinux. 2018-06-21 14:29:46 mercury^: does it install syslinux on EFI installs? 2018-06-21 14:29:55 ncopa: yes. 2018-06-21 14:30:06 does it need syslinux for soemthing? 2018-06-21 14:30:12 i guess it doesnt 2018-06-21 14:30:12 ncopa: I don't think so. 2018-06-21 14:30:30 ncopa: and it refuses to install GRUB. 2018-06-21 14:30:59 ncopa: Ahhh, my bad. I thought zipl/bootloader binary must be installed in order to boot. My bad. It already wrote booting info (kernel, initrd, etc.) on the disk. So everything's cool :) 2018-06-21 14:31:22 ncopa: when I had fixed it for my installation it worked. 2018-06-21 14:31:37 (without syslinux) 2018-06-21 14:32:00 ncopa: also, why does setup-disk install GNU acct? 2018-06-21 14:34:42 It would be nice also if you could specify that no bootloader be installed at all. Currently there is no efibootmgr so I have to configure the boot process from another system anyway. 2018-06-21 14:35:03 i think acct is used by mkinitfs for some boot performance measuring 2018-06-21 14:35:31 Ah. I had removed it because I could not figure it what it was there for. 2018-06-21 14:35:41 figure out* 2018-06-21 14:35:49 i dont think we need install it by default 2018-06-21 14:36:36 but would prefer not touch any of that til after v3.8 2018-06-21 14:37:09 dealing with bootloader for setup-disk may need som more work 2018-06-21 14:37:36 what worries me a bit more is that the iso does not boot in vmware 2018-06-21 14:38:23 Ah, the 3.7 iso also did not boot on a MacBook Pro 5,3 for me. But that is probably unrelated? 2018-06-21 14:39:08 I just created a bootable image and copied over the files. 2018-06-21 14:43:43 That MacBook by the way has some hardware which is not supported by the shipped kernels. I do not (terribly) mind compiling my own kernels anyway, but for the installer it may be convenient to add as many drivers as possible. (I would not have been able to adjust the backlight brightness before installing my own kernel, for example.) 2018-06-21 15:00:01 ncopa: is the docker issue on your agenda or should I create a issue on the bugtracker? (Can I do that without creating an account there?) 2018-06-21 15:04:45 i think you can create bug anonymous via email 2018-06-21 15:06:37 Category Security or Aports? 2018-06-21 15:54:21 ncopa: shall this be included before release you think? https://github.com/alpinelinux/aports/pull/4565 2018-06-21 15:55:26 or shall we hold it until right after? 2018-06-21 17:00:37 thanks jirutka. 2018-06-21 18:23:58 @ncopa: something is fishy with ppc64le console access. it actually seems that in order to get a login prompt, i have to provide a apkovl. without and apkovl, the console=hvc0 works instead of ttyS0... something must be missing but the apkovl has it? 2018-06-21 18:32:44 Using these kernel commands with rc8, i did not get a login console: modules= ip= powersave=off alpine_repo=dl-cdn.. modloop= ... so is the use case for booting on bare metal ppc64le just suppose to also include console=hvc0 ? 2018-06-21 18:55:56 @ncopa: I've shared my ppc64le test results more clearly in https://github.com/alpinelinux/aports/pull/4566 2018-06-21 20:01:41 ppc64le console works fine for me on bare metal fwiw 2018-06-21 20:37:52 mickibm ppc64le console works fine for me on bare metal fwiw 2018-06-21 20:42:59 @kaniini: using rc8? what were your kernel commands? 2018-06-21 20:44:07 mickibm on an ibm s822l, i just put the ISO in and booted with petitboot. kernel commands were the default on the ISO. 2018-06-21 20:44:42 (this is PowerNV though, maybe it is broken on KVM) 2018-06-21 20:45:12 kaniini: interesting... i have been doing a net boot on bare metal - adding a new boot option in petitboot and using these: http://dl-master.alpinelinux.org/alpine/v3.8/releases/ppc64le/netboot-3.8.0_rc8/ 2018-06-21 20:46:25 weird, i don't even know why one would want to netboot, since you have virtual media on the bmc 2018-06-21 20:46:55 i guess for automation reasons 2018-06-21 22:21:04 Why does heirloom-doctools conflict with util-linux? 2018-06-21 22:21:22 kinda want to have both installed :/ 2018-06-21 23:50:26 Hola compadres. I have a question about the apkbuild file. I have a package that has various installation targets for supporting different programming languages. I want to split them all off as subpackages. The main package is for c++ support. One subpackage is for go support. It would seem silly to make the main package depend on go, but it would make sense for the subpackage to depend on go. Is that possible with the current A 2018-06-21 23:58:02 Hello all, I'm fairly new to Alpine linux, and I'm trying to get `apk` to install `x86` and `x86_64` versions of `musl` side-by-side on the same system, but when I convince `apk` to install a different arch version of `musl`, it removes the original arch version. Is `apk` not meant to be used with multiple architectures at once? If so, is there a 2018-06-21 23:58:02 commonly-accepted way to configure a system that can run prebuilt `i686` and `x86_64` binaries at the same time? Thanks! 2018-06-22 00:00:43 staticfloat: multilib is not supported; you need to make a 32-bit chroot and run 32-bit softwares in there 2018-06-22 00:01:30 cfriedt: subpackages can define depend= in their functions (i.e. go() { depend="go" .... }), but if it already requires go for a .so file abuild will find that automatically 2018-06-22 00:02:14 swilfox: thanks! 2018-06-22 00:02:56 glad to help :) 2018-06-22 00:08:34 Thanks awilfox. I guess the easiest way for me to get what I want is to just download and extract `/lib/ld-musl-i386.so.1` and `lib/libc.musl-x86.so.1` from the `.apk` files directly. 2018-06-22 00:09:29 I don't want to have to live in a chroot, I just want to be able to run `i686` and `x86_64` binaries within the same system. This seems to work just fine, and as I'm not planning on installing many other libraries, it should be fine. 2018-06-22 00:10:23 whatever works for you :) dunno how you will get the libs to coexist though, since there is no /lib32 or /lib64 2018-06-22 01:41:37 The `musl` libraries are named differently for different architectures (because the interpreter that gets baked into ELF executables must exist at a predefined location; so they have had a solution to this multilib/multiarch problem for a long time) 2018-06-22 01:42:08 So you get things like `/lib/ld-musl-i386.so.1` and `/lib/ld-musl-x86_64.so.1` 2018-06-22 01:44:42 So those co-exist fine. For libraries that are loaded by the system dynamic linker, it's not normal for them to have the architecture embedded within the filename, but the system dynamic linker (In this case, `musl` itself) is smart enough to know about multiple search paths, so it will keep looking through the paths that are defined within the sy 2018-06-22 01:44:42 stem to try and find one that it can link into the requesting binary. So if I try to run `foo-` which is an `i686` executable and which relies on `libz.so.1`, but `/lib/libz.so.1` is of architecture `x86_64`, it will skip over it, and move on. So I just have to add my own `/lib32` or similar to the default search paths and drop all my 32-bit libr 2018-06-22 01:44:43 aries within there, and things should work "just fine" 2018-06-22 01:45:21 At least, that's my understanding. I hope to not need too many 32-bit libraries. Probably just `libz` and that's it, as most of the binaries I use should be pretty self-contained. 2018-06-22 01:45:22 Thanks! 2018-06-22 12:24:37 anyone around with wiki admin access? 2018-06-22 13:21:59 What Mailing List Manager does alpine use? Mailman? 2018-06-22 13:22:18 I do intend to host an mailing list myself on an alpine-based server 2018-06-22 14:55:15 There's alternatives, e.g. sympa, ezmlm 2018-06-22 14:55:34 I guess most offer similar features, but e.g. sympa performs well for large lists 2018-06-22 14:55:41 large numbers of lists, rather 2018-06-22 15:10:07 a barebones solution is librelist 2018-06-22 15:45:18 lists.alpinelinux.org uses hypermail 2018-06-22 16:30:35 ncopa: ffmpeg 4.0.1 changelog has lots of UB and int overflow fixes. 2018-06-22 16:32:05 https://git.ffmpeg.org/gitweb/ffmpeg.git/shortlog/n4.0.1 2018-06-22 19:33:03 kaniini: on you ppc64le box, have you gotten debug_init to work? doing a net boot and using debug_init I get a kernel panic and initramfs cannot load 2018-06-22 19:33:19 i have tested this on 3 ppc boxes, 2 p8s and a p9 and no dice 2018-06-22 21:22:54 i can give it a try, 2018-06-22 21:45:38 mickibm: have you tried injecting 'set -x' into initramfs-init and rebuilding initramfs ? 2018-06-23 18:20:18 is there a better way to do this 2018-06-23 18:20:21 https://wiki.alpinelinux.org/wiki/Saving_time_with_Hardware_Clock#Binding_the_hardware_clock_device 2018-06-23 18:20:44 normally raspberry pi does not have a hwclock, mine does because installed one 2018-06-23 18:21:16 however i think the binding is happening too late 2018-06-23 18:22:08 because i am still seeing those annoying messages: 2018-06-23 18:22:18 Clock skew detected with '(null)' 2018-06-23 18:22:20 Adjusting mtime of '/run/openrc/deptree' to 2018-06-23 19:17:21 tya99: try adding hwclock service at boot or init runlevel ? 2018-06-23 19:17:44 yeah that might be a good idea 2018-06-23 19:20:05 can i force abuild to run as root 2018-06-23 19:20:24 going to reboot anyway without saving 2018-06-23 19:25:08 oh nm, added a user :P 2018-06-23 19:36:11 tmh1999: yeah hwclock is in boot i might try putting it in init 2018-06-23 19:36:58 beware that I'm not sure it's correct thing to do :p 2018-06-23 19:38:29 no it might not be 2018-06-23 20:04:07 what are all these commits to aports? 3.8 isn't released, is it? 2018-06-23 20:04:15 even in testing/ ...? 2018-06-23 20:04:30 nope it's in rc 2018-06-23 20:04:35 very close to being released 2018-06-23 20:04:59 exactly. why are there commits in testing/? ncopa said it'll wait til after release 2018-06-23 20:13:47 packages in testing are not included in releases those are only available when using edge 2018-06-23 20:30:39 ah, ok 2018-06-24 07:54:30 hey il making an aport i noticed this however 2018-06-24 07:54:48 >>> WARNING: ndisc6*: APKBUILD does not run any tests! 2018-06-24 07:54:51 Alpine policy will soon require that packages have any relevant testsuites run during the build process. 2018-06-24 07:54:53 To fix, either define a check() function, or declare !check in $options to indicate the package does not have a testsuite. 2018-06-24 07:55:19 do i just run check() in build()? 2018-06-24 07:55:33 very small package in c that only depends on perl 2018-06-24 07:55:51 and makedepends of linux-headers so it's pretty trivial 2018-06-24 07:56:06 Disabling check() requires either (1) a comment (#) stating next to options="!check" that there is no test suite/unit tests or (2) functioning working check() function. 2018-06-24 07:56:28 is there some place the check() should be? 2018-06-24 07:57:11 oh here we go 2018-06-24 07:57:13 https://wiki.alpinelinux.org/wiki/APKBUILD_Reference#check.28.29 2018-06-24 08:02:37 i think i need options="!check" 2018-06-24 08:18:14 actually make check works so this is what i have 2018-06-24 08:18:58 https://dpaste.de/er4m 2018-06-24 08:19:22 though i am seeing these errors. https://dpaste.de/kcGV i haven't dealt with the docs correctly i don't think 2018-06-24 08:21:19 https://dpaste.de/dkh4 should i use, install -D -m644 2018-06-24 08:21:22 for each doc file? 2018-06-24 08:23:33 all the documents are in there http://git.remlab.net/gitweb/?p=ndisc6.git;a=tree;f=doc;h=d46a5b8f01bb760a6d09ba864829088dffbb103a;hb=HEAD 2018-06-24 08:24:21 and AUTHORS, COPYING, NEWS, README in the main root 2018-06-24 08:26:05 i guess i could do it like https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/ndisc6 2018-06-24 22:52:59 If anybody got experience with https://cloud-init.io/ could I then get you to review https://github.com/alpinelinux/aports/pull/4596 2018-06-25 04:13:45 there we go 2018-06-25 13:45:26 is it just me or does firefox segfault if dbus isn't installed on the first start? 2018-06-25 13:45:30 *firefox-esr 2018-06-25 13:55:43 i have no dbus running 2018-06-25 13:55:58 while ffox-esr is. 2018-06-25 15:12:11 does this look ok? http://tpaste.us/05VE 2018-06-25 15:12:24 i suppose we have forgotten something 2018-06-25 15:13:00 libressl 2.7? 2018-06-25 15:15:30 ncopa: Would be great if Dovecot 2.3.1 could make the cut 2018-06-25 16:01:30 drats 2018-06-25 16:01:49 TBK[m]: dovecot 2.3.1 testsuite fails on s390x 2018-06-25 16:03:06 TBK[m]: care to have a look? http://build.alpinelinux.org/buildlogs/build-edge-s390x/main/dovecot/dovecot-2.3.1-r0.log 2018-06-25 16:03:10 I'll check it now 2018-06-25 16:03:16 check if code support big-endian 2018-06-25 16:03:24 might be fedora has patches 2018-06-25 16:04:05 Will check, the issue is with MurmurHash3 2018-06-25 16:04:36 ha 2018-06-25 16:04:40 https://src.fedoraproject.org/cgit/rpms/dovecot.git/commit/?id=8a7475f62a0ef6e3ec0fa8dc363f4cb5380e9fcd 2018-06-25 16:04:49 i bet that is it 2018-06-25 16:05:14 hehe, yes that must be it :P 2018-06-25 16:05:50 should I make a PR or? 2018-06-25 16:06:02 nah, i fix it now 2018-06-25 16:07:07 👍 2018-06-25 16:15:11 Has anybody tried to setup a build env with a s390x emulate? 2018-06-25 16:23:14 https://wiki.alpinelinux.org/wiki/S390x 2018-06-25 18:47:33 wow, a 2 RC's in 2 hours? strange. 2018-06-25 18:58:47 <_ikke_> Probably noticed an issue 2018-06-25 19:12:22 tmh1999: thanks for your help with getty consoles on ppc64le 2018-06-25 19:12:41 just posted a new PR with recommendation from petitboot dev, jk-ozlabs 2018-06-25 20:31:33 yes i broke something :| 2018-06-25 20:58:47 mickibm: is hvc0 always available on ppc64le? 2018-06-25 21:03:45 ncopa: it is available on power9 and power8 but i can double check it is always available... let me ping someone 2018-06-25 21:04:02 does this look ok? http://tpaste.us/05VE ---> looks good. Thanks for dovecot fix. I was out today, prob next 2 days... 2018-06-25 21:14:34 tmh1999: you removed my rpi addition? 2018-06-25 21:14:45 no sir 2018-06-25 21:15:04 i dont see it anymore 2018-06-25 21:15:19 oh ncopa might have picked the old one. let me dig the irc log. 2018-06-25 21:19:24 tmh1999: http://tpaste.us/5YqM 2018-06-25 21:20:26 clandmeter: I saw that. But http://tpaste.us/05VE seems updated, he made it that way so please update too. 2018-06-25 21:21:19 ncopa: the person with the answer is in Perth, Australia so not online yet 2018-06-25 21:22:10 ncopa: edited relnotes: http://tpaste.us/YvLw 2018-06-25 21:46:10 ncopa: "you definitely want hvc0 instead of ttyS0 though" from out petitboot developer 2018-06-25 21:46:46 our* 2018-06-25 22:31:23 ncopa: chatting with the right people about hvc0 now. 2018-06-25 22:41:44 ncopa: thanks for double checking. looks like i will be submitting another PR due to zaius systems. the UART is passed though to the OS directly and there's no hvc0 2018-06-25 22:48:05 ncopa: we all decided to wait until our developer in Perth is online and then move forward. when is the cutoff for 3.8? 2018-06-26 05:08:30 so in busybox-extras.pre-deinstall it calls --list --full to get the list of applets, but it should be --list-full. the way it is now, a bunch of dangling symlinks are left behind :/ 2018-06-26 05:08:55 checked on 3.7 and edge 2018-06-26 05:29:44 ncopa: running some more tests with different hardware for ppc64le login and will post a new PR soon 2018-06-26 06:34:01 ncopa: third time is the charm... https://github.com/alpinelinux/aports/pull/4626 2018-06-26 06:37:59 Has alpine looked into ppc32be? 2018-06-26 06:39:59 <[[sroracle]]> Adelie supports it i think 2018-06-26 06:40:04 <[[sroracle]]> ^ awilfox 2018-06-26 06:40:59 ppc32 is a tier-1 arch in Adélie 2018-06-26 06:41:22 vanilla aports isn't quite all there, it needs some tweaking in some of the arch bits (openssl, gcc) 2018-06-26 06:41:51 Ah, cool 2018-06-26 06:42:04 Tier-1? 2018-06-26 06:42:12 Is it be or le 2018-06-26 06:42:27 BE 2018-06-26 06:42:55 ppc32le is a very very unique beastie; I haven't seen any machines that ran ppc32 in LE on purpose 2018-06-26 06:45:52 Good 2018-06-26 06:53:56 What about mips ||| 2018-06-26 06:54:18 we don't have MIPS going yet, but MIPS III will likely be our target ISA for mips64 2018-06-26 06:54:32 alpine has some mips stages I think? I think they are targeting the MIPS64 ISA though 2018-06-26 06:55:02 Awesome 2018-06-26 06:55:44 PS2 2018-06-26 06:56:29 awilfox: if you need any help with testing MIPS III just let me know 2018-06-26 06:56:43 opendata: definitely will. 2018-06-26 08:22:21 <_ikke_> clandmeter: ^ still security issues 2018-06-26 08:22:37 yes i didnt have time to look at it. 2018-06-26 08:22:58 we could tmp disable it. 2018-06-26 08:23:34 anyone know what nick Sören goes by? 2018-06-26 08:24:41 you mean nmeum? 2018-06-26 08:25:00 not sure how many we have :) 2018-06-26 08:25:39 I figured that was a pretty unique name, probably just the american in me :P 2018-06-26 08:25:40 Sören Tempel 2018-06-26 08:26:15 I personally know some people with the Tempel surname 2018-06-26 08:26:28 (unrelated, but yup, regional name) 2018-06-26 08:26:32 we have more ppl from that area. 2018-06-26 08:27:40 mepholic, if you need tempel nmeum is the one. 2018-06-26 08:28:37 awesome thanks :) 2018-06-26 08:29:14 https://git.alpinelinux.org/cgit/aports/tree/main/chrony/APKBUILD#n32 2018-06-26 08:29:19 was wondering about this 2018-06-26 08:29:49 it seems the upstream for pps-tools is dead, and the only mirrors I can really find are sketchy github mirrors 2018-06-26 08:30:54 ncopa might be able to help, but tempel's name is very close to the git blame on that 2018-06-26 08:46:53 mepholic: timepps.h was added in https://git.alpinelinux.org/cgit/aports/commit/?id=a29630d69eda6434a8bfe5490f548c7baa623082 by nangel 2018-06-26 08:47:18 I only changed the path in 4311f61b56a1ba41ee617a143f2e67ce23a987b7 2018-06-26 08:47:54 ah, thank you nmeum 2018-06-26 08:48:12 was wondering why specifically pps-tools wasn't pulled in 2018-06-26 08:52:57 > If a timepps.h header is available (e.g. from the LinuxPPS project), chronyd will be built with PPS API reference clock driver. 2018-06-26 08:53:20 looks like an optional dependency. I wonder if we really want to use a header file from a dead upstream project 2018-06-26 08:54:14 I don't know if it's dead so much as in maintenance 2018-06-26 08:54:25 the linux kernel still has PPS support 2018-06-26 08:54:46 i mean, the upstream site itself is dead... i wonder if kernel.org mirrors it somewhere 2018-06-26 08:56:08 has somebody installed sentry on alpine? i got the feeling that it fails for me just because of libessl/openssl -.- 2018-06-26 08:57:53 tboerger[m]: error logs would be helpful. 2018-06-26 08:59:18 https://gist.github.com/tboerger/03c81bafe73a649cd42982ddd831ec9b that's the whole output of pip install sentry 2018-06-26 08:59:46 ah, the ol py-cryptography 2018-06-26 09:00:59 tboerger[m]: try apk add py2-cryptography 2018-06-26 09:01:10 looks like we have a patch for libressl 2018-06-26 09:01:54 thanks, will try it 2018-06-26 09:02:06 yu[ 2018-06-26 09:02:16 p: https://git.alpinelinux.org/cgit/aports/tree/main/py-cryptography/libressl-2.7.patch 2018-06-26 09:02:18 :) 2018-06-26 09:02:29 yay, at least a different error :) 2018-06-26 09:04:30 damn... already had `src/lxml/includes/etree_defs.h:14:31: fatal error: libxml/xmlversion.h: No such file or directory` for a different tool even if libxml2-dev is installed -.- 2018-06-26 09:08:48 ah, looks like installing also libxslt-dev solves the issue 2018-06-26 09:09:02 i really love python errors :( https://gist.github.com/tboerger/c6ec1ecc5f8fb1425d434f14ef5685f0 what the heck is wrong with that? 2018-06-26 09:14:55 ncopa: also, according to archive.org linuxpps.org was not dead as of 10 days ago 2018-06-26 09:15:00 might be bad timing 2018-06-26 09:15:53 tboerger[m]: any way you can make that more verbose? 2018-06-26 09:24:50 ncopa: did you see my above comment about busybox? I can file a bug if it'd be easier to keep track of 2018-06-26 09:32:40 i saw it but i forgot it 5min later 2018-06-26 09:33:06 i will forget again unless you are lucky and i do it right now :) 2018-06-26 09:33:17 so, yes, please file a bug 2018-06-26 09:33:21 ok 2018-06-26 09:35:24 ^ :) 2018-06-26 09:40:51 ok, i think i won't package sentry on alpine... it got crazy dependencies like rust and cargo, even if it's a python tool -.- 2018-06-26 09:42:53 wtf why?! 2018-06-26 09:42:57 o_o 2018-06-26 09:43:00 that reminds me of the time I looked at 389ds (ldap server) and it needs perl, python, rust, ruby, and C++ at the same time :) 2018-06-26 09:43:14 WTF WHY 2018-06-26 09:43:15 O_O 2018-06-26 09:43:18 lmao 2018-06-26 09:46:23 sounds like their team could not agree on what language to use for implementation so they use as many languages as there are developers on the team :) 2018-06-26 09:49:07 ACTION starts a drum roll 2018-06-26 09:53:57 BA-DUM-TSSSSSS 2018-06-26 10:01:26 https://github.com/getsentry/semaphore/blob/master/py/setup.py and the funny thing is it just failes with no such file or directory 2018-06-26 10:01:51 not any information about which file does not exist -.- 2018-06-26 10:40:32 tboerger[m]: looks like it tries to execute #!/usr/bin/env python 2018-06-26 10:40:34 and cargo 2018-06-26 11:59:06 @ncopa after installing cargo/rust it successfully installed... but still weired stuff. 2018-06-26 12:04:36 no, its normal. the script tries to execute "cargo" which is not there so you get error "file does not exist" 2018-06-26 12:05:31 tboerger[m]: look at line 48 and 73 2018-06-26 12:07:14 i agree that it's stupid that it doesn't inform you which file it couldn't find 2018-06-26 12:07:15 i'd like to run alpine aarch64 in qemu, but I'm not getting any output with this cmdline: 2018-06-26 12:07:34 qemu-system-aarch64 -M virt -m 1024 -kernel boot/vmlinuz -initrd boot/initramfs-vanilla -monitor stdio -append "console=ttyAMA0" 2018-06-26 12:08:12 @mepholic yeah i got that, that's why i installed it... but initially the error was just https://gist.github.com/tboerger/74dfaec369b4bb622c0fa5cc788a0f89#file-gistfile1-txt-L17 which wasn't clear to me that it tried to call cargo. i just found it while i inspected the setup.py 2018-06-26 12:08:59 \o/ 2018-06-26 12:09:06 rpi netbooted :D 2018-06-26 12:09:12 congrats! 2018-06-26 12:10:03 clandmeter: what is this witchcraft!? 2018-06-26 12:10:12 did you have to shove ipxe and uboot together? 2018-06-26 12:10:19 no 2018-06-26 12:10:30 the bootloaders supports it 2018-06-26 12:10:35 -s 2018-06-26 12:10:39 really!? 2018-06-26 12:10:47 yes sir 2018-06-26 12:10:48 the stock crap on the rpi? 2018-06-26 12:10:50 wow 2018-06-26 12:11:01 I am honestly shocked 2018-06-26 12:11:19 lets see if i can shove it some ipxe love :) 2018-06-26 12:11:36 inital booting is pretty slow 2018-06-26 12:12:54 does this look ok? http://wwwtest.alpinelinux.org/posts/Alpine-3.8.0-released.html 2018-06-26 12:13:11 i will add a commit stats at the end 2018-06-26 12:13:20 no 2018-06-26 12:13:30 i modified it twice already and you ignore me. 2018-06-26 12:13:59 aw sorry, it was unintentional 2018-06-26 12:14:12 yeah yeah, ive heard that before :) 2018-06-26 12:14:35 http://tpaste.us/YvLw 2018-06-26 12:15:11 clandmeter: isn't the date wrong on htat 2018-06-26 12:15:13 that 2018-06-26 12:15:35 my eyes saw that but my brain didn't register it till you mentioned it azarus 2018-06-26 12:15:45 http://tpaste.us/KdJn 2018-06-26 12:15:53 yes i didnt touch the date. 2018-06-26 12:16:17 hmm 2018-06-26 12:16:28 that should be B+ 2018-06-26 12:17:17 pushed 2018-06-26 12:17:25 ncopa, make it B+ please. 2018-06-26 12:17:32 i did 2018-06-26 12:17:33 ah ok 2018-06-26 12:17:34 thx 2018-06-26 12:19:24 crap aarch64 only does efi :| 2018-06-26 12:19:51 efi ipxe 2018-06-26 12:23:42 i am about to tag 3.8.0 now, please hold your commits... 2018-06-26 12:34:52 ACTION finishes the drum roll 2018-06-26 12:36:58 guys: please hold your commits 2018-06-26 12:37:27 ncopa, jirutka hasnt been active on irc for weeks. 2018-06-26 12:37:39 he is lurking 2018-06-26 12:37:47 he is active on github 2018-06-26 12:37:59 well he doesnt reply to my msgs 2018-06-26 12:38:13 so lurking or ignoring... 2018-06-26 12:38:40 he cares enough to give sarcastic comments when he gets a chance 2018-06-26 12:39:23 i dont know why s390x failed 2018-06-26 12:47:30 clandmeter: damn that was a long drum roll 2018-06-26 12:47:38 :P 2018-06-26 12:48:01 yeah still had to do the bug t racker :) 2018-06-26 12:49:45 are we good to push this? http://wwwtest.alpinelinux.org/posts/Alpine-3.8.0-released.html 2018-06-26 12:49:57 i have a feeling we have forgotten something 2018-06-26 12:50:55 you removed the libressl upgrade? 2018-06-26 12:51:27 a preflight checklist can be handy :P 2018-06-26 12:51:35 and commit stats will be added i guess. 2018-06-26 12:53:05 TBK[m]: I've literally started making checklists for common adelie procedures, like updating/creating APKBUILDS: https://paste.ee/p/7BZnf 2018-06-26 12:53:35 checklists are helpful for complex operations, they also help with consistency 2018-06-26 12:54:53 that may not be fully applicable to alpine fwiw 2018-06-26 12:56:18 ok, we are good to do git pushes again 2018-06-26 12:56:24 i do have a checklist 2018-06-26 12:56:27 release checklist 2018-06-26 12:56:45 checklists are underrated :) 2018-06-26 12:56:59 mepholic: 2018-06-26 12:57:20 TBK[m]: 2018-06-26 12:57:21 mepholic: that's a pretty comprehensive list. i always forget running checkapk at the end. 2018-06-26 12:57:46 prspkt: i've been updating it as i see things that I need to do frequently 2018-06-26 12:57:52 i think it's just about settled out though 2018-06-26 12:57:59 mepholic: it is good practice. I have used a ton of them at sea for all sorts of procedures 2018-06-26 12:58:57 TBK[m]: yeah, that's because the military realized that they're _REALLY_ important after the initial test flight, and crash, and crew death of the B-17 2018-06-26 12:59:32 that's one of the reasons they're standard operating procedure for pilots 2018-06-26 12:59:50 and tier1 mirrors are up 2018-06-26 12:59:58 \o/ 2018-06-26 13:11:37 is the Twitter announcement in the works? 2018-06-26 13:14:00 im on this step: Manually sign the releases with gpg key 2018-06-26 13:14:20 then its: "publish release notes" 2018-06-26 13:14:50 dl-master is slow 2018-06-26 13:15:06 i wonder if its due to we removed hpn patches 2018-06-26 13:23:57 master is indeed slow. 2018-06-26 13:24:24 looks like it didnt get any faster after we added tier mirrors 2018-06-26 13:25:15 re release notes 2018-06-26 13:25:21 we shoudl mention LLVM 5 2018-06-26 13:25:45 jirutka had some comments on github regarding releasenotes. 2018-06-26 13:27:56 ncopa, cant your fake a few commits for me? its getter lower and lower.... 2018-06-26 13:28:29 hehe xD 2018-06-26 13:30:01 prspkt, you are the highest climber i think. real alpine style :) 2018-06-26 13:32:34 clandmeter: yeah, i hope i can keep up, while improving the quality of my commits 2018-06-26 13:33:01 prspkt, im sure you will. 2018-06-26 13:33:08 prspkt, thanks a lot for your help. 2018-06-26 13:33:30 clandmeter: thank you, i'll do my best. 2018-06-26 13:34:09 +1 2018-06-26 13:34:26 prspkt: great job! 2018-06-26 13:35:03 ncopa: thank you sir, appreciate it! 2018-06-26 13:35:51 and thank you for being patient with us... 2018-06-26 13:35:58 i wonder if I'm on the list as well :P 2018-06-26 13:36:11 likely not 2018-06-26 13:37:38 i wonder why the page is not refreshed 2018-06-26 13:46:09 mepholic, http://dev.alpinelinux.org/~clandmeter/other/rpi-netboot.mp4 2018-06-26 13:46:27 you probably cant see it, but it doesnt have a sd card inserted. 2018-06-26 13:46:52 clandmeter: i was reading an artivle about how it works without an sd card :) 2018-06-26 13:47:29 pretty cool though 2018-06-26 13:47:56 dont laugh about my cool pi case :p 2018-06-26 13:48:06 also, nice WASD keys, is that painters tape? 2018-06-26 13:48:09 :P 2018-06-26 13:48:21 is that an rpi 2 2018-06-26 13:48:22 ? 2018-06-26 13:48:27 3 2018-06-26 13:48:29 ah 2018-06-26 13:48:38 i dont think 2 is supported to do netbooting? 2018-06-26 13:48:40 clandmeter: re: case. whatever works tbh 2018-06-26 13:48:57 clandmeter: i think not, and thats what i have :< 2018-06-26 13:49:03 i had some carton laying around, it seems to work :) 2018-06-26 13:49:31 do you give it an address to boot from via dhcp or so? 2018-06-26 13:49:35 clandmeter: you might wanna coat it with antistatic on the inside if that's that plastic carton stuff I'm thinking of 2018-06-26 13:49:39 i'm genuinely interested to how this works 2018-06-26 13:49:45 it's probably fine if it's just cardboard though 2018-06-26 13:50:09 its just regular 2018-06-26 13:50:15 before i didnt even use one :) 2018-06-26 13:50:49 the keyboard is one of our own lower grade ones. 2018-06-26 13:51:40 azarus, yes just like regular pxe boot. 2018-06-26 13:51:53 except it doesnt look for a boot file, it looks for the rpi bootloader 2018-06-26 13:52:16 you can use the serial number to seperate configs and files. 2018-06-26 13:52:26 that's cool :D 2018-06-26 13:52:46 but you need to program it 2018-06-26 13:53:42 OTP has to be set to support usb booting. 2018-06-26 13:54:28 too bad the initial loading of the bootloader/firmware takes most of the time. 2018-06-26 13:56:40 ACTION remembers the dark NOOBS times 2018-06-26 13:56:43 ACTION shudders 2018-06-26 14:00:20 ncopa, is there a reason you didnt include the rpi flavor for netbooting? 2018-06-26 14:00:38 was not intentional 2018-06-26 14:00:53 ok, i guess we can add it with 3.8.1 2018-06-26 14:01:05 yay for honesty :) 2018-06-26 15:41:20 i am tweeting the 3.8.0 release 2018-06-26 15:41:31 is something like this good: #alpinelinux 3.8.0 is released with better s390x support, better rpi support and netboot. 2018-06-26 15:41:31 https://alpinelinux.org/posts/Alpine-3.8.0-released.html 2018-06-26 15:49:28 only two more items in my release checklist 2018-06-26 15:51:10 final item is "celebrate!" 2018-06-26 15:51:13 \o/ 2018-06-26 15:52:16 :D 2018-06-26 15:52:23 ncopa: congratulations! 2018-06-26 15:52:45 i know this one was quite a long road 2018-06-26 16:34:42 \o/ 2018-06-26 17:07:03 anybody experienced with running alpine (armhf/aarch64) on qemu? are there supported machine types? 2018-06-26 18:22:55 the wiki mentions this cmdline: qemu-system-arm -M vexpress-a9 -kernel zImage -initrd initramfs-grsec -dtb vexpress-v2p-ca9.dtb -hda hda.img -serial stdio 2018-06-26 18:23:19 but as of 3.8.0, there's no zImage anymore, so I substituted zImage with vmlinuz-vanilla. 2018-06-26 18:27:40 but still, no luck. init fails somewhere. 2018-06-26 18:29:52 http://cdn.imgpaste.net/2018/06/27/Gfd2a.png 2018-06-26 19:44:12 azarus: few months ago I tried to boot aarch64 with qemu 2018-06-26 19:44:53 I had some success but never managed run it fully 2018-06-26 19:45:40 mps: ah cool. i've been struggling with this for a long while already :< 2018-06-26 19:47:26 I had it booted but it didn't started properly, forgot exact message 2018-06-26 19:47:58 but remember it didn't mount root fs 2018-06-26 19:48:26 I had rescue console and some utils from initramfs working 2018-06-26 19:48:56 yup had that too 2018-06-27 08:58:24 ncopa, I would like to add edge support for boot.a.o but with the current structure its not possible. 2018-06-27 08:59:25 having periodic signed releases would be nice. 2018-06-27 09:01:25 and a way to be able to sign and verify modloop would be nice as well. 2018-06-27 09:05:56 clandmeter: lets fix that 2018-06-27 09:06:19 you mentioned apk already can do something similar? 2018-06-27 09:07:21 im thinking, lets fix boot.a.o so we have versions there 2018-06-27 09:07:32 i alraedy fixed that. 2018-06-27 09:07:36 aha 2018-06-27 09:07:37 local 2018-06-27 09:07:46 kind of 2018-06-27 09:07:47 :) 2018-06-27 09:07:57 but now i only have stable 2018-06-27 09:08:04 "kind of" :) 2018-06-27 09:08:09 that was what i was fearing :) 2018-06-27 09:08:45 dont fear, its a challenge ;-) 2018-06-27 09:08:46 i also think we should fix edge releases 2018-06-27 09:09:08 i have the version included now 2018-06-27 09:09:10 so we do edge releases once a month 2018-06-27 09:09:33 the ipxe script is now a mustache tpl 2018-06-27 09:09:40 ha 2018-06-27 09:09:41 so its easy to hook things in 2018-06-27 09:09:50 i put config parts in yaml 2018-06-27 09:09:59 which build the ipxe 2018-06-27 09:10:08 and some shell script the verify releases and create sigs 2018-06-27 09:10:37 if i can use upstream releases, i have remove all of my local image generation crap. 2018-06-27 09:10:52 have/can 2018-06-27 09:17:07 ncopa, would it be much work to get a signature of the modloop in the initramfs? 2018-06-27 09:21:56 i guess it needs to live outside of initramfs 2018-06-27 09:22:30 and add the logic to modloop initd 2018-06-27 09:26:19 https://git.alpinelinux.org/cgit/aports/tree/main/apk-tools/APKBUILD#n64 2018-06-27 09:27:20 that is how we can generate the signature 2018-06-27 09:27:39 then we can use the /etc/apk/keys/*.pub to verify it 2018-06-27 09:28:06 right, but it needs to happen on the builder? 2018-06-27 09:28:14 correct 2018-06-27 09:28:44 i was thinking that we can do it while we do releases 2018-06-27 09:28:56 thats the only way i guess 2018-06-27 09:39:10 ipxe boot gives errors on boot 2018-06-27 09:39:23 libc-utils signature error 2018-06-27 09:40:17 hmm 2018-06-27 09:40:32 how are you trying it? 2018-06-27 09:41:00 ah its post boot 2018-06-27 09:41:06 apk gives that error? 2018-06-27 09:49:27 yes when installing from initramfs 2018-06-27 09:49:31 it is latest-stable 2018-06-27 09:50:13 yes looks like it 2018-06-27 09:51:01 which is 4.9.65 2018-06-27 09:53:44 i have a new boot script 2018-06-27 09:54:13 the current one is kind of a hack. 2018-06-27 10:04:14 AL (or is it musl) doesn't have mktime? right? 2018-06-27 10:05:11 musl does have mktime(), it's POSIX 2018-06-27 10:05:32 trying to make curlftpfs aport and it pauses waiting to check if mktime exists on build system 2018-06-27 10:06:44 skarnet: yes, I see it in man pages but wonder why it pauses during configure phase 2018-06-27 10:07:22 checking for working mktime... 2018-06-27 10:09:42 weird 2018-06-27 10:21:30 skarnet: yes, it waits there more than 30 seconds but finishes eventually 2018-06-27 10:23:01 another question: how can I add extra CC options to APKBULD make? 'make CC=-D__off_t=off_t' maybe? 2018-06-27 10:24:06 you mean CFLAGS 2018-06-27 10:24:26 yes 2018-06-27 10:24:41 how to put it in APLBUILD file 2018-06-27 10:24:44 whatever gets your package building :P 2018-06-27 10:27:16 skarnet: after make in APKBUILD? huh, this mktime waiting is really annoying 2018-06-27 10:27:42 it really depends on the package and what the build script is. 2018-06-27 10:27:58 there's no single right way to fix a build 2018-06-27 10:28:05 it's all package-dependent... 2018-06-27 10:29:06 understand, but don't know how to put it to make to be passed to CC 2018-06-27 10:29:36 either export CFLAGS=... before the make command, or make CFLAGS=... 2018-06-27 10:30:09 but generally speaking if there's a configure option to achieve what you want, and that works, then it's better to use that 2018-06-27 10:30:17 because using make variables is a big hammer 2018-06-27 10:33:15 aha, could you give a hint (or exact option) what configure option should be used in this case 2018-06-27 10:34:11 I have no idea... if what you want is really -D__off_t=off_t then I don't think there's a configure option for that 2018-06-27 10:34:18 and a CFLAGS variable is your best bet 2018-06-27 10:34:43 because it's not about configuring things but about fixing a glibcism in the software :P 2018-06-27 10:36:11 oh, what I wouldn't give for a universal --make-upstream-portable option in ./configure 2018-06-27 10:36:29 ok, understand. it is glibcism problem, of course. tnx, I will try to find how to do that with abuild becasue I did it from cli 2018-06-27 10:37:20 awilfox: --dwim 2018-06-27 10:39:53 ^ 2018-06-27 14:14:53 any word on my patches for upgrading gimp and blender? :) 2018-06-27 16:57:09 hmm, how to package a noarch packge that runtime depends on a package that does not exist for armhf? 2018-06-27 16:57:29 arch="noarch !armhf" ? 2018-06-27 17:01:32 yes, seems that worked fine 2018-06-27 20:42:49 hmm cppcheck update failed on aarch64 and s390x but was OK on other arches, is check() that fails on the same TC. Revert? 2018-06-27 20:43:04 s/is/its/ 2018-06-27 20:45:13 we should really catch up with open pull requests now that 3.8.0 is out 2018-06-27 20:45:52 thats what I was trying to do :-) 2018-06-27 20:46:17 Would be nice to have a possibilty to test build on non x86 arches before merge.... 2018-06-27 20:46:49 I will merge some PRs now as well 2018-06-27 20:58:46 HRio: what about travis + qemu to emulate the archs? 2018-06-27 21:02:12 is there an howto for that? or was it a thought for future improvement? 2018-06-27 21:03:42 suggestion for future improvement of CI pipeline. There are guides for setting up qemu envs - e.g. https://wiki.alpinelinux.org/wiki/S390x 2018-06-27 21:04:48 so whats the general thing to do when one test case fails for two arches in edge? revert the hole merge or disable tests? 2018-06-27 21:06:33 my suggestion: try to fix it, patch, bump pkgrel 2018-06-27 21:09:19 will try to disable that TC first, to make sure 2018-06-27 21:12:03 HRio: depends on the packages. Disabling the test suite is usually fine 2018-06-27 21:12:17 even though the proper way would be fixing the test suite which is hard to do if you don't have access to the arch 2018-06-27 21:12:57 you can try to submit the error upstream and see if they can fix it. 2018-06-27 21:12:59 will try to disable only that TC 2018-06-27 21:13:01 you could also notify upstream about the test failure, they might have an idea how to fix it 2018-06-27 21:13:05 yeah 2018-06-27 21:13:06 sometimes other distros have already fixed the issue and you can just use their patch. 2018-06-27 21:13:41 I got myself a list of places to look :P 2018-06-27 21:13:42 was digging in master for cppcheck and could not find a fix merged as of yet 2018-06-27 21:15:00 HRio: if you do submit the issue upstream, make a note in the commit if you disable the test. 2018-06-27 21:18:14 i remember ncopa made some script to check if aport has a github PR. does anybody have it around? 2018-06-27 21:22:53 clandmeter: http://tpaste.us/N7Pk 2018-06-27 21:23:36 would like to test on s390x, before reporting upstream possibly? 2018-06-27 21:24:20 I dont have access to this arch. you could ask ncopa 2018-06-27 21:25:03 can I push to master? the failing code line is in the disabled TC 2018-06-27 21:25:19 do you have aarch64? 2018-06-27 21:25:55 yes i have 2018-06-27 21:26:47 if it is solved there, we know 100% we have the right TC 2018-06-27 21:27:17 ok let me test it 2018-06-27 21:28:12 HRio: is that patch on current head? 2018-06-27 21:29:05 armhf failed as well 2018-06-27 21:29:09 1.84 2018-06-27 21:29:22 curreny head in aports 2018-06-27 21:29:30 doesnt apply for me. 2018-06-27 21:30:55 http://tpaste.us/xeYJ 2018-06-27 21:31:16 ? 2018-06-27 21:31:49 https://github.com/HRio/aports/commits/misery-cpp 2018-06-27 21:33:35 ok thats better 2018-06-27 21:36:56 HRio: its fine now. 2018-06-27 21:37:00 on aarch64 2018-06-27 21:38:21 going to bed. gnite. 2018-06-27 21:38:40 thanks, trying to reach upstream 2018-06-27 21:39:01 they are not using github for issue but a trac instance... 2018-06-27 21:39:06 so trying irc now 2018-06-27 21:50:58 the builders http://build.alpinelinux.org/ seem to have activity failed, to you have to ping them to try again? 2018-06-27 22:01:31 algitbot: retry master 2018-06-28 02:05:51 Great! 3.8 is out. Now shooting for gcc upgrade and java. 2018-06-28 02:25:07 is it a known issue that alpine does not boot on power9 2018-06-28 05:26:47 oh wow, installing Alpine on a machine with Nvidia graphics was tedious... 2018-06-28 05:27:06 never could get Xorg to start until I added this line: https://patchwork.alpinelinux.org/patch/4022/ 2018-06-28 05:27:17 (also, maybe review? ;) ) 2018-06-28 06:09:01 (superseded, check https://patchwork.alpinelinux.org/patch/4023/ ) 2018-06-28 13:24:43 strangely quiet today 2018-06-28 13:26:01 The weather is nice atleast at my local 😅 2018-06-28 13:27:18 Time to stop coding and get a cold beer 2018-06-28 13:29:36 ah fair enough ;) 2018-06-28 14:01:53 i'm trying to add boto3 to container postgres:alpine, but getting py-boto3 (missing) when I attempt apk add 2018-06-28 14:02:46 I'm adding other packages fine (gcc, postgresql-dev) but this is failing, not sure why? 2018-06-28 14:05:18 possibly because it's only in edge? 2018-06-28 14:09:19 nevermind - I was looknig for py-boto3 when py-boto is in main 2018-06-28 14:29:42 hm, scratch that as well 2018-06-28 15:19:29 curious about openjdk10 on alpine?? You guys waiting for 11? 2018-06-28 15:25:03 should I go to the email list as opposed to chat about the openjdk question? 2018-06-28 15:26:42 been quiet in here 2018-06-28 15:27:01 was waiting to have me question discussed as well 2018-06-28 15:42:15 though I just figured out my issue 2018-06-28 17:52:35 It is the IcedTea project that dictates the OpenJDK versions that can be packaged. 2018-06-28 19:05:43 tmh1999[m]: strace update fails to build for s390x 2018-06-28 19:05:56 http://build.alpinelinux.org/buildlogs/build-edge-s390x/main/strace/strace-4.23-r0.log 2018-06-29 02:09:22 HRio: Thanks. I'm on the road, will be back soon... 2018-06-29 10:34:08 ncopa: regarding the docker package – I also noticed that it is significantly larger than the statically linked executables that one can get from https://download.docker.com , despite those executables including all features. 2018-06-29 14:01:40 I am just using it wrong or is `ap builddirs` broken on edge? always fails with `attempt to index local 'db' (a nil value)` here 2018-06-29 16:15:38 nmeum: regarding your comment on my gegl upgrade: no pkgrel bumps are required, as only gimp 2.8 (which is being upgraded to 2.10) is linking against it 2018-06-29 16:16:15 (should I bump the pkgrel of gimp 2.8 anyways?) 2018-06-29 16:17:22 (referring to https://github.com/alpinelinux/aports/pull/4430 ) 2018-06-29 16:44:23 I'd like to have this in: https://patchwork.alpinelinux.org/patch/4029/ , as it is necessary for building/developing OpenWrt. 2018-06-29 17:41:18 azarus: didn't know that the upgrade only affects gimp but gimp 2.10 is upgraded in a separate pr which means it would be neccessary to merge both at once then 2018-06-29 19:07:51 nmeum: yeah, I intend them both to be merged simultaneously 2018-06-29 19:08:23 I dunno if the new gegl is even compatible with gimp 2.8... :/ 2018-06-30 09:36:19 nmeum: right. do you want me to bump the pkgrel of gimp 2.8 for https://github.com/alpinelinux/aports/pull/4430 ? personally, I wouldn't do it, but since it carries 'S-changes-requested'... 2018-06-30 09:52:55 azarus: I can remove that label later on 2018-06-30 12:01:01 OK. 2018-06-30 16:35:31 any progress on working groups / special interest groups in alpine by the way? 2018-06-30 21:27:09 danieli: good question. didn't kaniini work on this?