2019-01-01 00:50:38 fcolista: now, yes 2019-01-01 00:59:56 happy new year, everyone! 2019-01-01 01:00:07 godt nyttår @ ncopa 2019-01-01 12:05:53 hleo 2019-01-01 12:13:46 I've submitted an update to a patch in patchworks but it didn't pick up the previous patch from the reply-to message id. Can someone take a look and tell me what I did wrong? The patch set is [alpine-aports] Initial commit of rEFInd package 2019-01-01 22:56:58 luckily, it *is* edge, which is prone to breaking 2019-01-01 22:57:05 anyway, you might wanna check that ncopa ^ 2019-01-01 23:52:06 what is lua-apk used for? it doesn't seem to be very complete 2019-01-02 00:56:03 just realized my patches adding syncplay to testing were overlooked 2019-01-02 00:56:11 can I get an alpine dev to take a look at this? sent to aports via email 2019-01-02 00:56:28 http://lists.alpinelinux.org/alpine-aports/5209.html 2019-01-02 08:33:51 ddevault: things to testing is postponed for now. we need get v3.9 out 2019-01-02 08:34:31 ddevaul: changes like this need bump pkgrel: http://lists.alpinelinux.org/alpine-aports/5214.html 2019-01-02 08:36:46 ddevault: im pushing this: http://tpaste.us/Vavd 2019-01-02 08:38:00 ugh... 2019-01-02 08:38:09 i cannot push that, py-incremental is in testing 2019-01-02 08:39:17 ddevault: is py-incremental and py-constantly hard dependencies to py-twisted? 2019-01-02 08:43:34 fcolista, hiredis has soname change. 2019-01-02 08:52:25 ncopa, i vaguely remember we discussed this before, but should we implement a simple post build soname check in abuild? 2019-01-02 08:56:00 <[[sroracle]]> clandmeter: doesn’t checkapk already do that? 2019-01-02 08:56:39 it does, but its a secondary action. 2019-01-02 08:57:35 i think checkapk works a bit different though. 2019-01-02 08:58:19 <[[sroracle]]> checkapk works by comparing newly built soname/sover against those from packages already uploaded 2019-01-02 08:58:25 i only want to check for soname change with apk when a aport has libs. 2019-01-02 08:59:02 <[[sroracle]]> it would be great to integrate that as an abuild warning though i agree 2019-01-02 08:59:32 <[[sroracle]]> and maybe even generate list of reverse dependencies that would need rebuilding 2019-01-02 09:00:09 i think thats out of the scope of abuild. 2019-01-02 09:00:19 some external tool would be better. 2019-01-02 09:00:36 include the cmd in the warning. 2019-01-02 09:00:42 <[[sroracle]]> sure 2019-01-02 09:07:20 soname check? 2019-01-02 09:07:33 to find unresolved deps? 2019-01-02 09:07:40 we have apk dot --errors 2019-01-02 09:08:31 we should probably set up some web page which displays current apk index errors 2019-01-02 09:11:10 ncopa, i mean when you bump a package and soname has changed. it will break deps so a warning post build would be nice. 2019-01-02 09:19:46 that requires that abuild understand what previous version was 2019-01-02 09:20:02 where should it get previous version from? 2019-01-02 09:20:05 http? 2019-01-02 09:20:08 local repository? 2019-01-02 09:20:09 or both 2019-01-02 09:20:35 should it give warning if http version of previous packages change abi but local package does not? 2019-01-02 09:21:10 what if there are 10 different versions in local repo? should it give warning i only a few of the older packages has different abi? 2019-01-02 09:21:27 if you build it local you will have a package in your local repo and one from remote. 2019-01-02 09:21:41 that is what checkapk compares 2019-01-02 09:22:07 yes but as i said its an extra tool, not everybody uses it. 2019-01-02 09:22:12 or sometimes forget it 2019-01-02 09:22:37 i think what we should do is improve the external tool 2019-01-02 09:22:51 and potensially make abuild call the external tool 2019-01-02 09:24:24 ok, i dont mind how its implemented. i think we should try to catch these mistakes. 2019-01-02 09:24:38 yes, i agree 2019-01-02 09:24:41 things pushed to github are already checked for it. 2019-01-02 09:24:54 not sure how to implement it though 2019-01-02 09:25:01 but we have more and more devs with access to aports directly 2019-01-02 09:25:14 yes, i understand the problem 2019-01-02 09:25:17 sometimes libs are not obvious 2019-01-02 09:26:10 i dont think adding more logic to abuild is the solution 2019-01-02 09:26:16 it needs to be an external tool 2019-01-02 09:26:32 we could improve checkapk 2019-01-02 09:26:44 or we could use `apk dot --errors` 2019-01-02 09:26:57 apk dot -errors will also reveal circular deps etc 2019-01-02 09:27:03 morning+happy new year! coming in late — what's the problem? 2019-01-02 09:27:12 yes, im also in favor of not adding more logic to abuild 2019-01-02 09:27:20 good morning mort___! 2019-01-02 09:27:34 morning mort___ 2019-01-02 09:28:14 mort___: problem at had is to make it difficult for devs to push broken stuff, like package update that breaks abi without rebuilding all the needed packages 2019-01-02 09:28:44 but tbh... I really want get v3.9 out ASAP at this point 2019-01-02 09:28:52 hmm, am i holding apkgrel wrong? it increases pkgrel by 2? 2019-01-02 09:29:06 ah- so ideally want a reverse dependency build? 2019-01-02 09:29:09 ah yes im holding it wrong. 2019-01-02 09:29:46 mort___: possibly. apk can actually detect those things with `apk dot --errors` 2019-01-02 09:30:08 and generate a dot graph of it 2019-01-02 09:30:26 ncopa: i guess that detects logical dependencies but not physical dependencies (making up terms wildly) 2019-01-02 09:30:38 that is, a<-b<-c<-a gets caught 2019-01-02 09:30:51 but someone breaking a when a <- b doesn't? 2019-01-02 09:30:58 (not knowing what apk dot actually does) 2019-01-02 09:31:12 well, it will also detect missing dependencies 2019-01-02 09:31:29 which is what happens if you break ABI 2019-01-02 09:31:40 ah right - when you say ABI, which ABI do you mean? 2019-01-02 09:31:49 shared objects 2019-01-02 09:31:51 shared libs 2019-01-02 09:32:26 we add a provides=so:libfoo.so.1 in the package to libfoo 2019-01-02 09:32:50 and things that is linked to libfoo.so.1 gets a depends=so:libfoor.so.1 2019-01-02 09:33:00 apk will resolve the deps 2019-01-02 09:33:29 if someone update libfoo so it provides libfoo.so.2 2019-01-02 09:33:41 packages that is linked to libfoo.so.1 needs to be rebuilt 2019-01-02 09:34:00 but its not automatically detected. you need to manually check that it does not break things when you update your package 2019-01-02 09:34:15 that is the problem clandmeter is talking about 2019-01-02 09:34:42 we have a tool that will run a diff of old and new apk: `checkapk` 2019-01-02 09:35:16 the problem is that its not always obvious you are upgrading a lib. libs need special care like ncopa mentioned. 2019-01-02 09:35:53 travis does it by running checkapk post build 2019-01-02 09:38:07 speaking of 2019-01-02 09:38:09 hm. sorry, just to clarify (i'm still on coffee#1 of the day!) so if a sounds correct 2019-01-02 09:40:05 what happens is that 'b' gets a new SONAME in the elf header 2019-01-02 09:40:28 old had libb.so.1 and new has libb.so.2 2019-01-02 09:40:57 when running application 'a', dynamic linker will look for libb.so.1 (b.1) 2019-01-02 09:41:11 but since b was upgraded, it will not find it 2019-01-02 09:41:57 mort___, take a look into the apkindex format. would make things a bit more clear. it shows the relation between depends and provides. 2019-01-02 09:42:13 clandmeter: will do (also apkcheck :) 2019-01-02 09:42:37 is the problem to make sure things are consistent in the repos at any point, or to help maintain running systems as consistent? 2019-01-02 09:43:12 to keep the repo in a working state. 2019-01-02 09:43:13 make sure things are consistent in the repos 2019-01-02 09:43:27 as an example 2019-01-02 09:43:36 we bumped hiredis 2019-01-02 09:43:41 problem at hand was the hiredis upgrade 2019-01-02 09:43:42 soname changed 2019-01-02 09:44:19 so all pkgs depending on it will fail, cause it depends on the soname xxx.13 while its how on xxx.14 2019-01-02 09:44:21 ncopa-desktop:~$ apk info --provides hiredis 2019-01-02 09:44:21 hiredis-0.14.0-r0 provides: 2019-01-02 09:44:21 so:libhiredis.so.0.14=0.14 2019-01-02 09:44:36 s/how/now 2019-01-02 09:44:36 clandmeter meant to say: so all pkgs depending on it will fail, cause it depends on the soname xxx.13 while its now on xxx.14 2019-01-02 09:45:04 got it (neat bot :) 2019-01-02 09:45:25 ncopa-desktop:~$ apk list --depends so:libhiredis.so.0.13 | tpaste 2019-01-02 09:45:25 http://tpaste.us/Rgx9 2019-01-02 09:46:46 ack 2019-01-02 09:47:20 clandmeter: are you working on rebuild those? 2019-01-02 09:47:29 should be done 2019-01-02 09:47:33 ok 2019-01-02 09:47:37 thanks! 2019-01-02 09:49:31 ncopa, why doesnt --depends work with info? 2019-01-02 09:49:40 just noticed that too 2019-01-02 09:50:11 $ apk info --depends so:libhiredis.so.0.13 2019-01-02 09:50:11 hiredis-0.13.3-r1 depends on: 2019-01-02 09:50:11 so:libc.musl-x86_64.so.1 2019-01-02 09:51:25 sorry ignore me 2019-01-02 09:51:37 hiredis is linked to libc 2019-01-02 09:53:47 ncopa, i mean rdepends 2019-01-02 09:54:01 it doesnt show any results 2019-01-02 09:54:59 dunno 2019-01-02 09:55:28 ok so i should use list instead of info. 2019-01-02 09:55:41 but i think i used info before and worked. 2019-01-02 09:56:13 i previously used apk search 2019-01-02 09:56:38 but i think apk search will not find the unresolved 2019-01-02 10:04:14 what's the reason that `apk dot —errors PKG` is not enough to show these things? 2019-01-02 10:29:39 seems like the PKG there is PKGMASK... 2019-01-02 10:29:50 not sure how that works tbh 2019-01-02 11:53:32 ncopa: i posted fix for community/volatility build https://patchwork.alpinelinux.org/patch/4356/ 2019-01-02 12:12:24 mps, thx 2019-01-02 12:22:56 clandmeter: you beat me to it :) 2019-01-02 12:23:00 mps: thanks! 2019-01-02 12:23:20 man, the only thing chromium doesnt pull in "yet" is the kernel. 2019-01-02 12:25:13 ncopa, are all builders running vanilla kernels now? 2019-01-02 12:25:41 yes 2019-01-02 12:26:42 does that allow us to remove grsec hacks from apkbuilds? 2019-01-02 12:27:04 yes, if needed 2019-01-02 12:27:43 i guess its not really needed, but it would clean things up a bit. 2019-01-02 12:27:53 things like restarting builds after paxmark 2019-01-02 12:28:09 for example? 2019-01-02 12:29:13 i think ive seen things like make || paxmark..; make 2019-01-02 12:29:29 yes, things like that can be removed 2019-01-02 12:30:16 and there are some smarter hacks that first run a specific makefile and then the rest. 2019-01-02 12:30:33 good, I thought to ask to remove paxmark dependencies from APKBUILD 2019-01-02 12:31:14 paxmark is not needed anymore? 2019-01-02 12:31:33 paxmark was/is for grsec kernels. 2019-01-02 12:31:38 i want keep them if they don't "hurt" 2019-01-02 12:31:51 things like make || paxmark can be removed 2019-01-02 12:32:10 i know people who runs old alpine on lxc host and newer alpine in containers 2019-01-02 12:32:35 understand, ok 2019-01-02 12:32:58 but if paxmark gets in your way, then don't bother to paxmark 2019-01-02 12:33:09 or maybe somebody wants to run on a recent grsec patch set. 2019-01-02 12:33:18 ppl who can afford it :) 2019-01-02 12:33:34 yeah, but i don't think we can support that 2019-01-02 12:33:41 btw, to help with 3.9 should i put 3.9 or edge in /etc/apk/repositories 2019-01-02 12:33:55 you can do so if you want 2019-01-02 12:33:56 yes 2019-01-02 12:34:02 i think that would be helpful 2019-01-02 12:34:11 3.9? 2019-01-02 12:34:20 3.9 yes 2019-01-02 12:35:00 ok, and is there updated list of failed builds 2019-01-02 12:35:28 what arch? 2019-01-02 12:36:06 x86_64, aarch64 and armv7 2019-01-02 12:36:32 im currently building rust for x86_64 so the list is not fully updated tehre 2019-01-02 12:36:35 for them i have build environments 2019-01-02 12:38:29 armv7: http://tpaste.us/nMVx 2019-01-02 12:38:42 im looking into chromium 2019-01-02 12:38:48 its not just missing headers 2019-01-02 12:38:54 yes 2019-01-02 12:39:01 i tried bild it last week 2019-01-02 12:39:12 two missing headers could be symlinked 2019-01-02 12:39:35 i am currently building chromium here locally with libva 2019-01-02 12:39:48 i am hoping it will solve the issues we have with chromium 2019-01-02 12:40:12 apparently is it only alpine that has problem with chromium. seems to work fine in void linux with musl 2019-01-02 12:42:15 i am aware of 3 differences in our build 2019-01-02 12:42:26 we dont enable libva 2019-01-02 12:42:51 we have smaller default thread stack size (but should be big enough) 2019-01-02 12:42:56 chromium will be hard :( 2019-01-02 12:43:24 will look at void linux template 2019-01-02 12:43:24 we implement a secure_getenv instead of falling back to getenv 2019-01-02 12:43:32 i have looked at it 2019-01-02 12:43:35 and at their patches 2019-01-02 12:43:42 i think those 3 things are different 2019-01-02 12:43:50 it may also be something in our toolchain? 2019-01-02 12:43:54 but i doubt that 2019-01-02 12:44:12 i am currently building with libva 2019-01-02 12:44:14 oh, one thing more 2019-01-02 12:44:17 ncopa, you want me to fix the build issue? 2019-01-02 12:44:28 or you have it covered? 2019-01-02 12:44:29 they have a chromium wrapper script 2019-01-02 12:44:40 clandmeter: i dont have it covered. yet 2019-01-02 12:45:14 ok ill try to get it in a building state 2019-01-02 12:45:27 rest is up to you. 2019-01-02 12:45:28 there will likely be a commit soonish, which enables libva 2019-01-02 12:45:39 good. thanks! 2019-01-02 12:46:27 ncopa: clandmeter: fzf is disabled on armv7, and armhf and aarch64 2019-01-02 12:46:37 but even with 96 cores this is taking time... 2019-01-02 12:46:51 mps: ok. i'll clear that then 2019-01-02 12:46:52 community/fzf i mean 2019-01-02 12:48:45 hmm 2019-01-02 12:48:49 this doesnt look good 2019-01-02 12:49:14 failing builds on x86: http://tpaste.us/zBQ9 2019-01-02 12:50:05 ncopa, i dont like this error on aarch64 builder 2019-01-02 12:50:37 segfault and dmesg reports [Wed Jan 2 12:47:20 2019] Synchronous External Abort: synchronous parity or ECC error (0x96000018) at 0x000000003b953af0 2019-01-02 12:52:08 heh 2019-01-02 12:52:13 does not sound good 2019-01-02 12:52:25 we upgraded the kernel 2019-01-02 12:53:37 Synchronous/Asynchronous ECC: This happens if an ECC error is detected at TCM interfaces or in the cache. 2019-01-02 12:55:41 we could try to reboot it with that setting packet mentioned 2019-01-02 12:55:52 acpi force iirc 2019-01-02 12:58:00 i think we should try that 2019-01-02 12:58:23 mps: can you investigate if there are anything that uses llvm4? 2019-01-02 12:58:40 grep llvm4 does not show anything 2019-01-02 13:00:46 not found llvm4 but maybe somewhere it is in llvm$ver 2019-01-02 13:01:07 i couldnt find anything 2019-01-02 13:01:32 nor do I 2019-01-02 13:01:53 rust, crystal, mesa, ponyc uses llvm5, 2019-01-02 13:01:58 ok 2019-01-02 13:02:03 lets move llvm4 to unmaintained 2019-01-02 13:05:01 we didnt implement some logic to adjust grub.cfg? 2019-01-02 13:09:57 i dont think we implemented it 2019-01-02 13:10:00 it was just talk 2019-01-02 13:10:13 ok i just added it manually 2019-01-02 13:10:16 going to reboot it now 2019-01-02 13:11:00 ncopa: looks like it is safe to move llvm4 in unmaintained 2019-01-02 13:14:49 ddevault: is py-incremental and py-constantly hard dependencies to py-twisted? 2019-01-02 13:14:52 ncopa: as far as I can tell, yes 2019-01-02 13:37:32 ncopa, looks like it doesnt segfault again (not sure im just lucky). But i think we still need to ask packet about http://tpaste.us/lZVX 2019-01-02 14:20:21 ddevault: can you please prepare a couple of patches where py-incremental and py-constantly are moved to main? and dependencies if they have any not already in main 2019-01-02 14:20:32 sure 2019-01-02 14:20:36 thanks! 2019-01-02 14:20:42 I'll take care of it after $dayjob 2019-01-02 14:21:47 why is it 'dayjob'? does FOSS only happen at night? 2019-01-02 14:23:58 AinNero: "dayjobs" are commonly also known as "9-to-5"s, even if they don't happen in that timespan. The word was also chosen (way back when) to invoke moonlighting. 2019-01-02 14:24:41 TIL moonlighting 2019-01-02 14:27:17 ncopa: gst-plugin-bad patch is here https://patchwork.alpinelinux.org/patch/4369/ 2019-01-02 14:27:57 build passed on x86_64, aarch64 and armv7 2019-01-02 14:35:01 awesome 2019-01-02 14:36:59 thanks, but you are awesome with your idea to build AL 2019-01-02 15:25:33 ruby-rmagick fails because of wrong .so linkage. Anyone here who knows Ruby to look at the build log? 2019-01-02 15:26:28 it builds but check fail 2019-01-02 15:41:47 LoadError: 2019-01-02 15:41:47 Error relocating /usr/lib/libgomp.so.1: __cxa_finalize: initial-exec TLS resolves to dynamic definition in /usr/lib/libgomp.so.1 - /home/buildozer/aports/community/ruby-rmagick/src/rmagick-RMagick_2-16-0/dist/gems/rmagick-2.16.0/lib/RMagick2.so 2019-01-02 15:42:08 is that the error you see? 2019-01-02 15:42:23 yes 2019-01-02 15:44:24 'ldd src/rmagick-RMagick_2-16-0/dist/gems/rmagick-2.16.0/lib/RMagick2.so' finds all libs 2019-01-02 15:49:17 i think this is related: https://bugs.freedesktop.org/show_bug.cgi?id=35268 2019-01-02 15:57:48 from the description there looks similar, but i'm not sure. someone with better knowledge should look at it 2019-01-02 16:01:43 here is something about libgomp on musl problem: https://github.com/void-linux/void-packages/issues/3924 2019-01-02 16:02:43 from void linux, and looks like they fixed it 2019-01-02 16:05:18 do you think it is worth to try their patch to gcc on AL? 2019-01-02 16:06:00 yes 2019-01-02 16:06:05 i think i have kodi building now 2019-01-02 16:07:26 ok, will try after coffee ;) 2019-01-02 16:10:17 b stew 2019-01-02 16:10:20 disregard 2019-01-02 17:39:19 fyi github is having issues right now - https://www.githubstatus.com/ 2019-01-02 17:42:13 aaand it's back 2019-01-02 17:44:20 ncopa: i patched gcc and build it. with the new /usr/lib/libgomp.so.1.0.0 ruby-rmagick passed 'abuild check' 2019-01-02 17:45:04 there is no 'Error relocating /usr/lib/libgomp.so.1:' with patched gcc/libgomp 2019-01-02 17:47:06 should I post patch for gcc APKBUILD to be reviewed? 2019-01-02 18:22:36 ncopa: fix for libgomp is here https://patchwork.alpinelinux.org/patch/4370/ 2019-01-02 18:22:57 please review before applying 2019-01-03 00:20:03 frbml, I have a missing symbol when I'm trying to play with PHP extension on Alpine is there anyone around knowledgeable on the topic to give me a hand? 2019-01-03 00:20:40 (the logs are here: https://gitlab.com/jvoisin/snuffleupagus/-/jobs/140818692 ) 2019-01-03 00:20:59 the symbol being `ps_globals` 2019-01-03 08:03:48 jvosin: i get 404 Page Not Found 2019-01-03 08:04:05 i think something may need a rebuild 2019-01-03 09:22:49 ncopa: do you have time to look at gcc/libgomp patch https://patchwork.alpinelinux.org/patch/4370/ 2019-01-03 09:28:37 oh, yes, thats a priority 2019-01-03 09:42:21 oh, forgot to tell that i disabled ada build during building gcc, not sure if there is problem in makedepends_* 2019-01-03 10:15:54 ncopa, looks like i got chromium to build, but linking is broken. http://tpaste.us/dk4y -lz is passed. 2019-01-03 10:19:31 gcc 'abuild -r' fails locally with 'configure: error: GNAT is required to build ada' 2019-01-03 10:29:24 clandmeter: i think chromium uses its own fork of zlib 2019-01-03 10:29:39 yes it does 2019-01-03 10:29:45 it seems that the buildscripts for arm is broken 2019-01-03 10:29:54 the -lz may be needed for libpng 2019-01-03 10:30:01 or... hm 2019-01-03 10:30:16 no 2019-01-03 10:30:55 it looks like the chromium build scripts does not autodetect that it should build the arm optimizations for zlib 2019-01-03 10:31:27 you mean for armv8? 2019-01-03 10:31:53 so i think we either need to change the zlib code to use the arm specific optimizations, or we need make chromium build scripts detect arch specific optimization and add the needed files 2019-01-03 10:31:56 yes 2019-01-03 10:32:05 it looks like arch specific optimizations for arm 2019-01-03 10:32:29 i read it has crc32 optimizations for armv8 2019-01-03 10:33:05 so it detects armv8? 2019-01-03 10:33:14 maybe we should force it disable that and use armv7 2019-01-03 10:37:27 heh 2019-01-03 10:37:37 it looks like chrommium sources ships 4 copies of zlib 2019-01-03 10:37:42 and build 2 2019-01-03 10:38:07 im building for aarch64 2019-01-03 10:38:21 so i think we want armv8 optimalization? 2019-01-03 10:39:15 i was wrong, thwy only ship one copy of zlib. 2019-01-03 10:39:27 oh, its for aarch64 2019-01-03 10:39:48 yeah, i think we may want armv8 optimization then 2019-01-03 10:41:47 why do they bundle it anyway? 2019-01-03 10:41:52 zlib? 2019-01-03 10:43:02 i thikn they have some patches 2019-01-03 10:43:35 see the third_party/zlib/README.chromium 2019-01-03 10:44:29 can you: grep current_cpu out/Release/* 2019-01-03 10:44:35 what is current_cpu defined as? 2019-01-03 10:45:28 out/Release/gn: current_cpu = "x86" 2019-01-03 10:45:28 out/Release/gn: current_cpu = "x64" 2019-01-03 10:45:48 hmm 2019-01-03 10:46:27 http://tpaste.us/4yo4 2019-01-03 10:47:06 current_cpu=\"arm64\" 2019-01-03 11:04:18 clandmeter: i think I know what is wrong 2019-01-03 11:06:13 :) 2019-01-03 11:06:22 can you please try this? http://tpaste.us/M5km 2019-01-03 11:08:54 ok let me first install the 333 makedepens 2019-01-03 11:11:32 i wonder if anyone ever tried to build this on an raspberry pi 2019-01-03 11:12:52 restarting the build breaks it. 2019-01-03 11:13:05 clandmeter: does it makes sense to try on exynos with 4GB RAM and micro SD card? 2019-01-03 11:13:29 this is 96 core and 128GB ram 2019-01-03 11:13:32 and its still slow 2019-01-03 11:13:59 i think you can make it before 2020 :) 2019-01-03 11:14:50 let's try, just for fun 2019-01-03 11:18:32 on armv7 chromium depedns on 184 packages 2019-01-03 11:20:21 you probably have lots of stuff installed already? 2019-01-03 11:21:47 right, because I prefer 'abuild deps' to not always download deps on ADSL link 2019-01-03 11:22:02 use cache d ir 2019-01-03 11:23:21 will look for a guide on wiki where cache explained. will be of the help. 2019-01-03 11:23:33 thanks for hint 2019-01-03 11:23:42 create a dir somewhere and link it to /etc/apk/cache 2019-01-03 11:23:48 voila 2019-01-03 11:24:11 that's all, nice 2019-01-03 11:24:46 its a feature of the diskless system 2019-01-03 11:24:57 err i mean tmpfs system :) 2019-01-03 11:25:24 i'm on the 'sys' mode installs 2019-01-03 11:25:34 yes, it will work just as well 2019-01-03 11:26:01 just caching apks you install 2019-01-03 11:28:51 should that dir be word writeable 2019-01-03 11:29:47 or set group to abuild, probably :| 2019-01-03 11:33:17 you can apk update and apk cache sync/download 2019-01-03 11:33:38 works now, thanks 2019-01-03 11:34:19 ncopa, ../../third_party/zlib/crc32_simd.c:233:1: error: pragma or attribute 'target("crc")' is not valid 2019-01-03 11:52:38 clandmeter: try this: http://tpaste.us/0LW6 2019-01-03 12:15:54 ncopa, ../../third_party/zlib/names.h:181:28: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'Cr_z_armv8_crc32_little' 2019-01-03 12:38:29 sorry for annoyance, but. 'abuild -r' in main/gcc fails with 'configure: error: GNAT is required to build ada' 2019-01-03 12:39:14 if i add gcc-gnat manually it works 2019-01-03 12:41:05 but, in the APKBUILD (line 135) there is gcc-gnat in 'makedepends_build="$makedepends_build gcc-gnat gcc-gnat$_cross"' 2019-01-03 12:41:52 is this is a bug or I missed something 2019-01-03 12:53:57 i think it needs to be added manually on each builder 2019-01-03 12:54:10 probably a circdep? 2019-01-03 12:58:35 what about to add it in makedepends_build at the top of APKBUILD? 2019-01-03 13:00:55 clandmeter: http://tpaste.us/aR0o 2019-01-03 13:01:34 if that does not work, then I think we need to either use clang or disable arm optimizations 2019-01-03 13:19:57 AinNero: what do you think about this? http://lists.alpinelinux.org/alpine-devel/6229.html 2019-01-03 13:20:03 looks ok to me 2019-01-03 13:22:53 ncopa: i dont see a reason why it could break, so its alright with me 2019-01-03 13:24:05 i consider that a useful feature 2019-01-03 13:24:29 +1 2019-01-03 13:24:55 it does not update the manpage, if you push it as it is, i'll append a PR with manpage update 2019-01-03 13:25:29 it was pushed 2019-01-03 13:27:10 do you consider the isoloop a feature we want? 2019-01-03 13:28:17 where? 2019-01-03 13:28:26 mkinitfs 2019-01-03 13:28:45 aka, make nlplug-findfs search iso images named on the kernel command line 2019-01-03 13:28:55 i remember something about isoloop but i dont remeber the exact details 2019-01-03 13:29:00 wasnt that a PR? 2019-01-03 13:29:26 https://github.com/alpinelinux/mkinitfs/pull/18 2019-01-03 13:30:29 i have a way how it could work fine in my head, but i'd like to know first if its wanted 2019-01-03 13:33:16 i think its a useful feature 2019-01-03 13:33:26 i mean, it does not seem to be too intrusive 2019-01-03 13:34:03 it may actually be enough to simply do losetup before calling nlplug-findfs 2019-01-03 13:34:43 i think we want it unless it break other things for us, or makes things too complicated 2019-01-03 13:34:44 "may", there might be invalid paths ending up in the repository locations, so i'd rather test this first 2019-01-03 13:35:29 so if it can be implemented cleanly, then im ok with it 2019-01-03 13:35:39 alright 2019-01-03 13:36:06 i think what will happen is that /dev/loop0 gets mounted as /media/loop0 or /media/$UUID 2019-01-03 13:36:22 and /media/loop0/apks gets added to /etc/repositories file 2019-01-03 13:36:25 which i think would be ok 2019-01-03 13:36:47 but yes, it should be tested first 2019-01-03 13:38:29 Another thing, PR aports#5926 is relevant for go compatibility on less common architectures, so i'd like to see it included in 3.9 2019-01-03 13:38:57 there were two guys who had this issue with 3.8 on powerpc 2019-01-03 13:40:14 mh, fabled's code 2019-01-03 13:48:09 aports#5926 2019-01-03 13:48:52 aports#5926 2019-01-03 14:27:02 $ git diff mkinitfs-bootparam.7.in | tpaste 2019-01-03 14:27:02 http://tpaste.us/qKa9 2019-01-03 14:27:09 AinNero: does that look ok? 2019-01-03 14:27:44 ye 2019-01-03 14:28:59 dont need to ask me for changes on documentation 2019-01-03 14:29:26 im no good at writing docs, so i need feedback ;) 2019-01-03 14:29:40 nor is english my native language 2019-01-03 14:29:47 same 2019-01-03 14:30:03 as you might have seen by the manpages spelling fix PR by someone else 2019-01-03 14:30:14 :) 2019-01-03 14:31:33 im tagging mkinitfs 3.4.0_rc1 2019-01-03 14:32:33 okay 2019-01-03 14:39:22 and it boots in my vm 2019-01-03 14:39:27 so i'll push the update 2019-01-03 14:39:31 and reboot my laptop 2019-01-03 14:45:07 grep for that assertion in GDK and find out under what conditions it happens 2019-01-03 14:45:14 gah, wrong -devel again 2019-01-03 14:48:29 :) 2019-01-03 14:49:03 I got used to typing /b devel to switch to that channel 2019-01-03 14:49:06 bad habit 2019-01-03 14:51:06 ncopa, its builds again but fails to link again http://tpaste.us/NKO6 2019-01-03 14:51:44 ok. so the arm optimizations does not work with gcc 2019-01-03 14:51:53 i think we need to disable them 2019-01-03 14:52:01 or use clang 2019-01-03 14:56:21 right 2019-01-03 14:56:31 fedora also uses clang 2019-01-03 15:21:30 clandmeter: do you have any work inprogress patch for chromium? 2019-01-03 15:21:40 i'll try rebuild it with clang 2019-01-03 15:22:25 i had to use one patch 2019-01-03 15:22:41 i think fedora has a similar patch 2019-01-03 15:23:10 this is what i intend to push: http://tpaste.us/xp5w 2019-01-03 15:23:25 https://src.fedoraproject.org/cgit/rpms/chromium.git/tree/chromium-71.0.3578.98-skia-aarch64-buildfix.patch 2019-01-03 15:23:51 i had had to symlink that header 2019-01-03 15:30:25 re cert 2019-01-03 15:30:49 ln -s /etc/ssl/certs/ca-certificates.crt /etc/ssl/cert.pem 2019-01-03 15:30:55 fixes wget 2019-01-03 15:34:13 yes, but that file is not packaged 2019-01-03 15:34:59 isn't it generated post-install (or something along those lines)? 2019-01-03 15:35:07 it is 2019-01-03 15:35:15 having a dangling symlink for ~10 seconds (until generation happens) shouldn't be a big deal 2019-01-03 15:37:39 we dont want bb wget to depend on ca-certificates 2019-01-03 15:38:01 previously libressl prpvided cacert.pem 2019-01-03 15:38:34 so now we need to generate our own as we cannot simply copy it from aports as its not available yet. 2019-01-03 15:39:21 aha 2019-01-03 15:39:43 but generating it is a bit complicated from the ca-certificates aport. and creating an independed aport to makedpend on ca-certificates also sounds like a bad idea. 2019-01-03 15:40:51 if one of the builders would have some cert artifact it would end up inside of the cacert.pem. 2019-01-03 15:42:46 re: clang - I ran gentoo with CC=clang at some point, most issues come from packages that explicitly depend on gcc internals (similar to musl's issues) 2019-01-03 15:43:13 but I had trouble getting it working under musl (but that was a pretty long time ago) 2019-01-03 15:43:34 if we're going to go and use clang on arm, it might make sense to use it everywhere (since we'll need to patch all problematic arm packages anyway) 2019-01-03 16:35:45 As i continue to try to familiarise myself with alpine, i was looking at https://bugs.alpinelinux.org/issues/7105 as it's marked for 3.9. There seem to be two obvious ways to go about resolving this one: either install from the static builds maintained by the author, or install via cabal. What would be the preferred route? (Or did I miss other options?) 2019-01-03 16:35:53 ncopa: ^^ 2019-01-03 16:44:56 mort___: i dont know to be honest. I have too little experience with haskell 2019-01-03 16:45:09 it seems like arch linux builds it 2019-01-03 16:45:22 https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/shellcheck 2019-01-03 16:52:36 they also have a -static package i think? 2019-01-03 16:52:45 https://aur.archlinux.org/packages/shellcheck-static/ 2019-01-03 16:52:56 https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=shellcheck-static even 2019-01-03 16:55:26 i'll see how things work out anyway (assuming it's still useful) 2019-01-03 17:03:07 Seems like static is a precompiled binary. I think we want compile it ourselves 2019-01-03 17:06:41 ncopa: ok, i'll look into that then 2019-01-03 17:12:55 is there new list of failed builds 2019-01-03 17:13:31 I have some time to look if can fix something 2019-01-03 18:09:55 fix for libcoro on armv7 is here https://patchwork.alpinelinux.org/patch/4374/ 2019-01-03 20:09:17 mps, why did you disable CORO_ASM on x86? 2019-01-03 20:14:41 it looks suspicious to me, not sure if ASM code works well on any arch 2019-01-03 20:16:53 maybe it is faster with asm code but is a lot harder to debug and test 2019-01-03 20:18:59 from the source coro.h "Fastest choice, if it works." 2019-01-03 20:20:59 for SJLJ "Coroutine creation is much slower than UCONTEXT, but context switching is a bit cheaper" 2019-01-03 20:21:50 and for SJLJ "It should work on almost all unices." 2019-01-03 20:22:23 so it looks as safest choice although maybe not fastest 2019-01-03 20:22:59 and builds and tests without warnings 2019-01-03 20:32:22 ncopa: you're around ? 2019-01-03 20:33:39 https://gitlab.com/jvoisin/snuffleupagus/-/jobs/141179332 no 404 anymore :) 2019-01-04 07:36:39 ncopa, did clang fix it? 2019-01-04 08:22:15 clang needs more work :-/ 2019-01-04 08:22:47 clang (LLVM option parsing): Unknown command line argument '-instcombine-lower-dbg-declare=0'. Try: 'clang (LLVM option parsing) -help' 2019-01-04 08:22:47 clang (LLVM option parsing): Did you mean '-instcombine-maxarray-size=0'? 2019-01-04 08:22:47 [77/1080] ACTION //v8:js2c(//build/toolchain/linux/unbundle:default) 2019-01-04 08:24:26 clandmeter: in case you'd like to work on it: http://tpaste.us/5wkN 2019-01-04 08:24:47 i need to be afk today 2019-01-04 08:26:41 how about we disable chromium on arm* and aarch64 for now? 2019-01-04 08:26:50 so we can get 3.9_rc1 out 2019-01-04 08:27:01 im ok with that 2019-01-04 08:27:24 not sure i really have time to dig into it. 2019-01-04 08:28:23 maybe mps can take a look. as he uses arm*. 2019-01-04 10:10:06 clandmeter: good morning. I will if it would work on 4GB of ram 2019-01-04 10:50:24 hi ! i have installed alpine-virt in an virtualbox 2019-01-04 10:51:11 and i have seen that in the virt kernel there is the serial module pl2303 not inkluded 2019-01-04 10:52:12 what is the easy way to make this module available in this virt kernel 2019-01-04 10:56:56 clandmeter: I started chromium build on aarch64, waiting to see results 2019-01-04 10:57:07 kristoferus75, what is the name of the module? 2019-01-04 10:57:41 CONFIG_USB_SERIAL_PL2303=m 2019-01-04 10:58:29 kristoferus75: is that needed on VM 2019-01-04 10:58:29 pl2303.ko 2019-01-04 10:58:39 yes 2019-01-04 10:59:11 USB passtrough? 2019-01-04 10:59:25 kristoferus75, ok i found it. please create an issue for it on bugs.alpinelinux.org. 2019-01-04 10:59:47 yes but i dont think that is a bug ! 2019-01-04 11:00:13 i said craete an issue :) 2019-01-04 11:00:15 not a bug 2019-01-04 11:00:19 ok 2019-01-04 11:00:36 clandmeter: such 'bugs' will end with every module to be added to -virt 2019-01-04 11:01:02 mps, ncopa can decide if he wants to add it. 2019-01-04 11:01:15 thats why we need an issue for it. 2019-01-04 11:01:55 of course, but then the difference between vanilla and virt will vanish 2019-01-04 11:02:25 its not decided yet, so its not yet the end of the world. 2019-01-04 11:02:50 you can append your thoughts to the issue ones its created. 2019-01-04 11:03:20 no, but it begins ;) . sorry for OT. 2019-01-04 11:04:28 kristoferus75: btw, you can add linux-vanilla to your VM and try with it, it should work 2019-01-04 11:04:28 i think, if people use passthrough in the VM, they should just use the vanilla kernel 2019-01-04 11:05:10 AinNero, +1 2019-01-04 11:07:17 AinNero: yes, I did it but with some other modules 2019-01-04 11:35:23 clandmeter: chromium build failed with APKBUILD from aports. should I try with a patch ncopa posted here https://tpaste.us/5wkN 2019-01-04 11:35:43 mps, yes you need to build it with clang. 2019-01-04 11:35:52 catch the error and try to find a soluition 2019-01-04 11:36:54 aha, ok. 2019-01-04 11:37:04 hi ! with the vanilla kernel ist works but the vm is than bigger :-( 2019-01-04 11:37:40 kristoferus75, yes thats the downside. 2019-01-04 11:37:40 i only want to know how to compile my own kernel with this spez module 2019-01-04 11:38:24 kristoferus75, this is development channel. for support we sue alpine-linux 2019-01-04 11:38:32 s/sue/use 2019-01-04 11:38:32 clandmeter meant to say: kristoferus75, this is development channel. for support we use alpine-linux 2019-01-04 11:38:48 ok 2019-01-04 11:46:35 clandmeter: chromium-71.0.3578.98-skia-aarch64-buildfix.patch is missing in community/chromium 2019-01-04 11:46:46 should I remove it from sources? 2019-01-04 11:56:29 clandmeter: sorry, just had network outage after sent my question 2019-01-04 11:57:37 you didnt miss anything 2019-01-04 11:58:20 there is no chromium-71.0.3578.98-skia-aarch64-buildfix.patch file in community/chromium and it is added in APKBUILD which ncopa posted 2019-01-04 11:58:51 do you have that file? 2019-01-04 12:31:50 clandmeter: never mind, found it fedora site 2019-01-04 15:34:39 ncopa: chromium with your new APKBUILD from tpaste url fails with: clang (LLVM option parsing): Unknown command line argument '-instcombine-lower-dbg-declare=0' 2019-01-04 15:36:10 will try on x86_64 because on aarch64 with micro sd is slow 2019-01-04 15:38:03 yes, i found out the same 2019-01-04 15:38:17 we used to have this: https://git.alpinelinux.org/aports/plain/community/chromium/chromium-clang-r2.patch?id=0ed5524b742b317bdcc9b7b26dd4033369e6c2f8 2019-01-04 15:38:26 bit it appears to be applied upstream 2019-01-04 15:39:44 i guess we can search for that flag in the same file 2019-01-04 15:40:46 already found in src/chromium-71.0.3578.98/third_party/llvm/lib/Transforms/InstCombine/InstructionCombining.cpp 2019-01-04 15:41:32 commented that out to see what will happen 2019-01-04 15:42:40 but build such 'monster' require time :/ 2019-01-04 15:58:52 ncopa: reached to: Unknown command line argument '--target=aarch64-alpine-linux-musl' 2019-01-04 16:00:29 what to put instead? 2019-01-04 16:36:56 i have no clue :) 2019-01-04 16:40:48 reached to remove -O2 flags. build system is for gcc not clang, will see maybe will have luck 2019-01-04 16:41:59 this is what I have come up with so far: http://tpaste.us/vbyQ 2019-01-04 16:42:03 removing one by one to see next and next after next 2019-01-04 16:43:41 this will help, I will remove also these you posted 2019-01-04 16:44:59 rm build/config/compiler/BUILD.gn :D 2019-01-04 16:46:07 ok, going to coffee, [obligatory xkcd url about compiling here] 2019-01-04 16:46:25 mps: got you covered https://xkcd.com/303/ 2019-01-04 16:46:25 http://xkcd.com/303 | Compiling | Alt-text: 'Are you stealing those LCDs?' 'Yeah, but I'm doing it while my code compiles.' 2019-01-04 16:47:28 SpaceToast: you catch-ed me :) 2019-01-04 16:47:39 Cx-Mx-Net 2019-01-04 19:02:03 ncopa: clandmeter: I give up :( it 2019-01-04 19:02:57 chromium is a monster package and switch to clang need more time and testing 2019-01-04 22:22:46 mps, yes it is. it took me a lot of time go get it into alpine, and it took ncopa even more time to maintain it :| 2019-01-04 22:42:45 clandmeter: I don't even use it for some years, just sometimes when need to check if the firefox have bug 2019-01-04 22:45:49 i tried to build it only to have it for users who are accustomed to it 2019-01-04 22:51:19 I keep switching between the two (at random intervals, for various reasons) 2019-01-04 22:51:43 mps: while I'm certainly for CC=clang, why are we building chromium with it (in this case specifically)? 2019-01-04 22:52:45 well, ncopa tried with gcc but failed and then swithed in hope that the clang could help 2019-01-04 22:53:03 s/swithed/switched/ 2019-01-04 22:53:03 mps meant to say: well, ncopa tried with gcc but failed and then switched in hope that the clang could help 2019-01-04 22:53:03 once I have my new builder I'll take a look (might need reminding though) 2019-01-04 22:53:53 and, fedora and archlinux also builds with clang, IIRC 2019-01-04 22:54:06 and freebsd 2019-01-04 22:54:11 and certain gentoo weirdos :) 2019-01-04 22:54:33 last time I actually built chromium with clang was ... 2ish years ago though? 2019-01-04 22:54:39 (and on glibc, at the time) 2019-01-04 22:55:05 looks like upstream prefers clang too, but we at Alpine have a loot of cruft from gcc 2019-01-04 22:55:33 I personally prefer clang, but that might just be my bias in favor of BSD-style licenses over GNU 2019-01-04 22:56:00 would be fun to try and tackle that eventually, but even if I went for it it's very low on the priority list (read: likely not in 2019, even if planned for) 2019-01-04 22:56:19 I looked at void linux and it looks most cleaner of all, but don't have time to 'port' it in day or two 2019-01-04 22:57:24 and, 3.9 needs to be released in a few days, 3.9-rc1 i think 2019-01-04 22:59:06 will see later at slower pace if someone with more knowledge do that hard work 2019-01-04 23:02:05 oh, sorry, last sentence is ambiguous, I mean if someone do that hard work and manage to build it then I will not have to work on it 2019-01-04 23:02:23 :) 2019-01-04 23:03:41 I'm self taught in English and never been in any country where English is native language 2019-01-04 23:04:33 you're not doing too badly - it's relatively obvious that you're not native, but you're not hard to understand most of the time 2019-01-04 23:07:51 thanks, I have spellchecker active :) 2019-01-05 03:37:55 ncopa, workaround for php-msgpack aarch64 build https://github.com/alpinelinux/aports/pull/5969 2019-01-05 03:38:25 it is slow in chroot but once test fails the builder does the same 2019-01-05 19:50:19 libcoro builds locally on armv7 with patch https://patchwork.alpinelinux.org/patch/4374/ 2019-01-05 19:52:30 ruby-rmagick alsy builds on armv7 locally. does the build machine have nevest gcc and libs upgraded? 2019-01-05 20:05:20 mps, please try https://build.alpinelinux.org/buildlogs/build-edge-armv7/community/php7-pecl-msgpack/php7-pecl-msgpack-2.0.3-r1.log 2019-01-05 20:05:30 too many tests failed 2019-01-05 20:06:10 maybe better just disable it for armv7? 2019-01-05 20:08:18 andypost: ok, in a hour or two will try 2019-01-05 20:10:50 btw, i noticed it fails but hesitate to try because I'm bad with php 2019-01-05 20:15:58 there should be logs and diffs in src...tests 2019-01-05 20:17:16 will see and post results for you to check and help 2019-01-05 20:17:40 I did comment out a test for aarch64 and reported upstream in https://github.com/alpinelinux/aports/pull/5969 2019-01-05 20:19:12 I can try on aarch64 too 2019-01-05 20:25:13 andypost: php7-pecl-msgpack failed with one test, Profiling perf test. [tests/035.phpt] 2019-01-05 20:25:30 what is proper way to build package from svn sources? 2019-01-05 20:25:34 svn co in prepare()? 2019-01-05 20:26:25 milek7: svn/git/etc sources are strongly discouraged right now, especially ones without a release (e.g by the linter) - please use release tarball 2019-01-05 20:28:56 andypost: looking at source src/msgpack-2.0.3/tests/035.phpt but don't know what to do, i.e. what to change 2019-01-05 20:30:04 mps, which numbers you get? in https://github.com/msgpack/msgpack-php/issues/123#issuecomment-451620789 2019-01-05 20:31:23 mps, this test ensures that arch can do at least 400 serialisations in second 2019-01-05 20:34:30 it just tell that that test failed, could I run somehow just this one test 2019-01-05 20:35:28 ah, found it 2019-01-05 20:35:50 mps, yes, just append make test TESTS=tests/035.phpt 2019-01-05 20:36:02 tests/035.sh shows: 4000 iterations took 10.393772 seconds: 384/s (BAD) 2019-01-05 20:36:12 oh... 2019-01-05 20:36:39 384 is less then 400 - that's why it fails 2019-01-05 20:36:58 i thought that 2019-01-05 20:37:19 so for armv7 this line should be commented as well 2019-01-05 20:37:36 no, this one was on aarch64 2019-01-05 20:38:41 didn't yet tried on armv7 2019-01-05 20:45:19 SpaceToast: release tarball is much older than svn repo (splix) 2019-01-05 20:45:26 anyway, i don't need to have this in official repository, just wanted my printer to work 2019-01-05 20:45:30 how to keep apk installed from local file persistent in diskless mode? 2019-01-05 20:45:55 you use lbu to backup your world file, and have it in the apkcache 2019-01-05 20:45:59 (or in a repo) 2019-01-05 20:48:15 but it needs to be manually placed in cache? apk cache sync doesn't copy it here 2019-01-05 20:48:52 andypost: on armv7 tests/035.sh tell: 4000 iterations took 10.746334 seconds: 372/s (BAD) 2019-01-05 20:54:59 andypost: on armv7 also tests/034.phpt failed 2019-01-05 20:56:29 message from 'abuild check': FAIL Unserialize invalid random data [tests/034.phpt] 2019-01-05 20:57:16 mps, so looks it does not work "mostly" for armv7 2019-01-05 21:01:00 well, I don't know, maybe these speed test are not well designed for slow machines 2019-01-05 21:01:50 php is made and tuned for servers mostly 2019-01-05 21:12:58 could ccache be added to aport builds 2019-01-05 21:13:15 I mean, in local build 2019-01-05 22:35:41 andypost: are you here? 2019-01-05 22:38:42 I forgot to activate all cpu's on armv7 during test, and now php7-pecl-msgpack fails with just one test, FAIL Profiling perf test. [tests/035.phpt] 2019-01-05 22:56:53 is Stuart Cardall here? 2019-01-05 23:01:14 im testing out wireguard, but i dont like it pulling in all these deps. 2019-01-05 23:03:25 clandmeter: "all those deps"? 2019-01-05 23:04:09 i tneeds bash, procps, iproute2 and coreutils... 2019-01-05 23:04:40 not really? 2019-01-05 23:04:46 you might be thinking of the convenience script "wg-quick" 2019-01-05 23:04:57 yes its bundled 2019-01-05 23:05:05 and jason doesnt want to unbundle it 2019-01-05 23:07:23 he added a hack to not need to install bash, but i think i have something better. 2019-01-05 23:08:11 clandmeter: you could just separate out wg-quick 2019-01-05 23:08:20 my understanding is that that's the only thing that actually cares 2019-01-05 23:08:37 wg(1) is ELF, and wireguard is a kernel module 2019-01-05 23:08:41 thats what i did 2019-01-05 23:09:16 :) 2019-01-05 23:09:49 it makes sense too - it's pretty hard to use wireguard without wg(1) 2019-01-05 23:09:54 but you don't need wg-quick at all 2019-01-05 23:10:00 correct 2019-01-05 23:10:07 im using regular networking scripts 2019-01-05 23:10:21 its pretty simple to setup :) 2019-01-05 23:10:25 yes it is :) 2019-01-05 23:10:34 I've been running wireguard at home for... half a year now? 2019-01-05 23:10:45 and its really fast. 2019-01-05 23:10:46 and in production at work for longer 2019-01-05 23:10:50 (so I can VPN in from laptop) 2019-01-05 23:10:59 that one does use wg-quick though 2019-01-05 23:11:17 but yeah you basically just need two pre-ups and one post-down 2019-01-05 23:11:27 yup 2019-01-05 23:12:20 i couldnt find a debug option. i guess its non existent? 2019-01-05 23:13:30 well for kernel modules it's complicated, but I bet you could just not strip debug symbols from wg(1) 2019-01-05 23:13:42 wg-quick is just a wrapper script, so if something goes wrong you basically see what it was that went wrong 2019-01-05 23:13:47 (it's relatively verbose as-is) 2019-01-05 23:13:55 i mean the actual connection 2019-01-05 23:14:01 it doesnt log anything 2019-01-05 23:14:16 you mean like tcpdump? 2019-01-05 23:14:29 like any other vpn tech i used 2019-01-05 23:14:38 but those are mostly userspace 2019-01-05 23:14:42 wireguard doesn't have the concept of a "connection" 2019-01-05 23:14:46 so there isn't really much to log 2019-01-05 23:15:08 if you want to see what happens over it, you can always just tcpdump the interface 2019-01-05 23:15:46 https://git.alpinelinux.org/aports/commit/testing/wireguard-tools?id=16a4a9c1c7a1b50a313a3a70efaf324189ae0d00 2019-01-05 23:16:05 i wonder if coreutils is a mistake 2019-01-05 23:16:25 wait I'm confused 2019-01-05 23:16:27 or does sysctl -r need coreutils? 2019-01-05 23:16:29 that commit message makes no sense 2019-01-05 23:16:45 they add depends to get wg-quick working... 2019-01-05 23:16:50 but don't add bash 2019-01-05 23:16:54 despite the fact that wg-quick requires it 2019-01-05 23:17:03 yes there is a pr for it 2019-01-05 23:18:35 the right approach is to split both tools and make wireguard-tools depend on both. 2019-01-05 23:19:02 so im able to install just wireguard-tools-wg without the rest. 2019-01-05 23:19:48 looked at the two PRs 2019-01-05 23:19:50 this is so confusing 2019-01-05 23:20:00 but that sounds good to me 2019-01-05 23:20:10 so package() both, then subpackage() both (1)s 2019-01-05 23:24:14 heh 2019-01-05 23:25:02 still find the attitude... strange - worried about a file not being present (when you can `apk add cmd:wg-quick`), but not worried about "it errored out" (due to bash being missing) 2019-01-05 23:25:44 the kernel module also uses an install if 2019-01-05 23:26:11 its actually broken as its out of sync with the userland tools 2019-01-05 23:26:22 oh my 2019-01-05 23:26:29 that's strange 2019-01-05 23:26:30 not sure we even want that 2019-01-05 23:26:49 I was under the assumption wg(1) was relatively set in stone now 2019-01-05 23:26:52 use should install both kernel module and tools manually 2019-01-05 23:27:02 s/use/user 2019-01-05 23:27:02 clandmeter meant to say: user should install both kernel module and tools manually 2019-01-05 23:27:13 you can't really use the wireguard module without wg(1) though, can you? 2019-01-05 23:27:24 correct 2019-01-05 23:27:29 I think it should be the other way around 2019-01-05 23:27:35 wg(1) should have an install_if on the module, then 2019-01-05 23:27:41 (because people might use the go implementation) 2019-01-05 23:28:02 ah i see now 2019-01-05 23:28:21 (I don't think we need to package it, upstream strongly recommends the module, but it still is a thing that exists) 2019-01-05 23:29:04 it has i was looking wrong. 2019-01-05 23:29:14 but its still broken 2019-01-05 23:53:03 building chromium on aarch64 segfaults, g++ compiling some files 2019-01-05 23:53:52 does make sense to lower -jX flag, maybe -j2 2019-01-06 02:01:40 hey i am trying to get a bit of help debugging sound on a fresh alpine linux virtualbox desktop install... i tried asking in #alpine-linux but haven't gotten a response in a few minutes and am impatient. is it ok to ask in here? 2019-01-06 02:02:26 electricityZZZZ: this is the development channel, so no; it's pretty late for me, but let me see if I can help 2019-01-06 02:02:41 electricityZZZZ: note: I'm detached from #alpine-linux, but if I'm needed, just light the bat signal (aka mention my nick, it auto-reattaches :) ) 2019-01-06 11:45:13 Hi, I'm running Alpine 3.7 with python3 and sqlite3. There was a security bug in SQLite, which has been solved in Alpine Git 6 days ago: https://git.alpinelinux.org/aports/commit/main/sqlite?h=3.7-stable&id=63ebe94564a865e66f3ee37fa683ce8edd3d19c6 2019-01-06 11:45:52 However the sqlite package is still at 3.21.0: https://pkgs.alpinelinux.org/package/v3.7/main/x86_64/sqlite 2019-01-06 11:47:28 I'm maintaining a mail distribution and our stable version is stuck on alpine 3.7. Hence, we have a user group exposed to this CVE and we wish to uprade as soon as possible. 2019-01-06 12:01:22 Can somebody trigger a build? 2019-01-06 12:31:56 How are major version upgrades handled for packages that are in main? Do they coexist with the old version in main and the new version in testing? For example if I wanted to upgrade package foo from version 0.1.0 to version 3.2.1 should I create a new foo directory in testing and update the APKBUILD there or would I just edit the version in main? 2019-01-06 13:03:46 emolitor, I think you have to upgrade your package in the main folder of the main branch. Did you check if other packages depend on the package you want to upgrade and if they can handle the new version? 2019-01-06 13:13:27 thanks hjaekel, there are about fourteen packages from our worktree that I want to upstream. I'm going to start with the ones with no dependencies first. :) 2019-01-06 13:23:25 emolitor, that might be easier :) 2019-01-06 13:54:38 ncopa: I have some success with chromium, compiled about two thirds of it, but it startded to fail because my build machine doesn't have enough RAM 2019-01-06 13:55:26 to often compiler is killed with 'out of memory' 2019-01-06 13:56:31 set 'ninja -j4' instead of default -j8 but without luck 2019-01-06 13:57:36 I could post changed APKBUILD so you or clandmeter could try on the build box 2019-01-06 15:22:09 clandmeter, sorry I was sick...just read the backlog re: hiredis 2019-01-06 15:22:10 x86_64-edge:~/aports/main/hiredis$ checkapk 2019-01-06 15:22:10 >>> No soname differences for hiredis. 2019-01-06 15:22:10 >>> No soname differences for hiredis-dev. 2019-01-06 15:22:30 i've done this check so I went ahead 2019-01-06 15:44:03 fcolista, np 2019-01-06 15:59:07 should I bump pkgrel? to fix package https://github.com/alpinelinux/aports/pull/5969 2019-01-06 16:23:27 if the pakcage never build for that arch you can skip it 2019-01-06 16:23:37 andypost, ^ 2019-01-06 16:24:29 else it will rebuild for all arches 2019-01-07 07:57:24 ncopa, why does edge builder still have libressl2.7-libcrypto installed? 2019-01-07 08:06:17 ncopa: any chance we could temporarily disable the chromium build that is blocking armhf, armv7, aarch64? these arches did not build the Qt upgrade yet, which is kind of important for us. 2019-01-07 08:07:36 ollieparanoid[m], im on it :) 2019-01-07 08:08:22 clandmeter: thanks :) 2019-01-07 08:10:30 ollieparanoid[m], done 2019-01-07 08:12:01 clandmeter: what did you do exactly, has it built the qt packages now? 2019-01-07 08:12:24 ollieparanoid[m], you are not in #alpine-commits channel? 2019-01-07 08:13:02 https://git.alpinelinux.org/aports/commit/?id=40635ea8 2019-01-07 08:13:19 not anymore it seems, I'll join again 2019-01-07 08:17:47 clandmeter: joined. thanks for disabling chromium 2019-01-07 08:23:43 ncopa: do we want to upgrade firefox-esr before the 3.9 is released (the current version is EOL)? The rust arches issue has not been fixed yet though so we can only build it for x86 and x86_64 2019-01-07 08:24:05 only x86_64 in fact 2019-01-07 08:24:07 nmeum, i got a pm from somebody with a patch 2019-01-07 08:24:14 for rust or for firefox? 2019-01-07 08:24:16 i didnt look into it 2019-01-07 08:24:26 forwaded the user to ncopa 2019-01-07 08:24:40 https://tpaste.us/DLBd 2019-01-07 08:25:11 ah, ok. a firefox patch 2019-01-07 08:25:33 https://build.alpinelinux.org/ shows that armhf and aarch64 are building testing/* now - that means, that all community packages - including qt - have been built and will appear in the repos soon, right? 2019-01-07 08:27:22 clandmeter: the patch looks okish. the patches seem to be copied from testing/firefox. ncopa: what's your opinion on this? the obvious issue of cause being that firefox only supports x86_64 now 2019-01-07 08:28:00 but I think we can go with that for now and maybe fix it as soon as community/rust supports more arches? The alternative is shipping an eol firefox-esr version with 3.9 2019-01-07 08:28:10 ollieparanoid[m], i think they are already on the mirror? 2019-01-07 08:28:17 5.12.0? 2019-01-07 08:29:27 clandmeter: yes, 5.12.0. oh, so this page is not live? https://pkgs.alpinelinux.org/packages?name=qt5-qtbase&branch=edge 2019-01-07 08:31:37 clandmeter: but yes, 5.12.0 packages are in the repos \o/ thanks again! 2019-01-07 08:31:49 (best feature of algitbot) 2019-01-07 08:31:50 ollieparanoid[m], it takes some time 2019-01-07 08:31:54 probably 15min to udpate 2019-01-07 08:31:57 well a bit more 2019-01-07 08:32:06 x minutes for the other mirrors so sync 2019-01-07 08:32:13 and x minutes for pkgs to pick it up 2019-01-07 08:38:36 I see, thanks! 2019-01-07 09:29:10 fabled, why is it that uname -p displays unknown? 2019-01-07 09:30:15 some project is using https://cmake.org/cmake/help/latest/variable/CMAKE_SYSTEM_PROCESSOR.html to determine the cpu 2019-01-07 09:30:39 On systems that support uname, this variable is set to the output of uname -p 2019-01-07 09:40:11 ah its non posix 2019-01-07 10:00:41 clandmeter: community/ruby-rmagick builds and passes check locally on my armv7 and it is stuck on builders. are gcc and libs upgraded on build machine 2019-01-07 10:01:13 im checking that atm :) 2019-01-07 10:05:48 mps, gcc didnt get build with your patch 2019-01-07 10:06:15 on armv7, you mean 2019-01-07 10:06:26 nod 2019-01-07 10:06:48 ok, will try again now 2019-01-07 10:07:18 i wonder why it didnt first build gcc 2019-01-07 10:08:12 hmmm, I forgot what happened. will try to build gcc and see 2019-01-07 10:08:39 its build already 2019-01-07 10:08:41 https://build.alpinelinux.org/buildlogs/build-edge-armv7/main/gcc/gcc-8.2.0-r2.log 2019-01-07 10:09:03 but, from the head I think it was ok :/ 2019-01-07 10:10:03 im not sure what the logic of builders world is. 2019-01-07 10:11:07 could be its only upgraded after a complete cycle 2019-01-07 10:11:26 that is the question. i thought it first builds main and after all is finished then go to community 2019-01-07 10:11:45 im talking about the base world 2019-01-07 10:11:54 gcc is always installed 2019-01-07 10:12:12 its part of alpine-sdk 2019-01-07 10:12:39 err build-base 2019-01-07 10:12:59 abuild will always install new packages from local repo 2019-01-07 10:13:13 iirc, gcc is pulled by alpine-sdk 2019-01-07 10:13:14 but it doesnt seem to have upgraded the base system 2019-01-07 10:13:24 buidlers dont use sdk 2019-01-07 10:14:50 hmm seems more weirdness on this builder. 2019-01-07 10:15:45 fabled, did you install ncurses-dev on build-edge-armv7? 2019-01-07 10:15:47 iirc, i did 'apk update' 'apk upgrade' and gcc is upgraded 2019-01-07 10:16:00 will see in a few minutes 2019-01-07 10:16:33 i'm talking for local machine 2019-01-07 10:16:48 i have no idea what you are talking about :) 2019-01-07 10:18:09 heh, i think on my local machine gcc is upgraded to gcc-8.2.0-r2 from the alpine v3.9 repo 2019-01-07 10:18:36 im going to upgrade edge armv7 2019-01-07 10:18:54 give me few minutes to check 2019-01-07 10:21:41 mps, it build now 2019-01-07 10:21:58 gcc? 2019-01-07 10:22:31 huh? 2019-01-07 10:22:45 gcc was long time build, read my msg :) 2019-01-07 10:23:47 on local armv7 'apk version gcc' shows: gcc-8.2.0-r2 = 8.2.0-r2 2019-01-07 10:24:08 mps, https://build.alpinelinux.org/buildlogs/build-edge-armv7/main/gcc/gcc-8.2.0-r2.log 2019-01-07 10:25:32 next error is php7-pecl-msgpack 2019-01-07 10:26:11 it is on mirror https://nl.alpinelinux.org/alpine/v3.9/main/armv7/gcc-8.2.0-r2.apk 2019-01-07 10:26:40 thats 3,9 2019-01-07 10:26:45 edge was stuck 2019-01-07 10:30:20 aha, understand now. but does edge block v3.9 build 2019-01-07 10:36:16 clandmeter: looks like gcc build on edge was successful or i'm blind 2019-01-07 10:38:30 yes its ok now 2019-01-07 10:38:52 nice :) 2019-01-07 10:39:08 but still some package broken 2019-01-07 10:40:31 for php7-pecl-msgpack armv7 and aarch64 are slow to pass some tests 2019-01-07 10:41:55 andypost have more info, i talked with him about that few days ago 2019-01-07 10:42:10 armv7 just fails the tests 2019-01-07 10:42:14 a lot of them 2019-01-07 10:43:12 for php7-pecl-msgpack it fails just one, something about speed calcution some number, or what 2019-01-07 10:43:44 Tests failed : 35 ( 30.7%) ( 31.8%) 2019-01-07 10:45:50 i run test number 35 locally and andypost told me that it is slow and because that test failed 2019-01-07 10:46:34 number 35? 2019-01-07 10:46:43 35 tests in total fail 2019-01-07 10:47:12 better to ask him, he is maintainer (iirc) and will give right answer. I just guessing 2019-01-07 10:47:34 i think we can disable it for now. 2019-01-07 10:50:02 however you feel, i told andypost that having php on arvm7 is not important because php intended for servers and not small and slow machines like arm32 2019-01-07 10:53:25 anyway, just run 'abuild check' again and got: Tests passed : 110 ( 95.7%) ( 99.1%) 2019-01-07 11:00:53 hmm, andypost pushed patch for php7-pecl-msgpack which disable tests on armv7 and aarch64 2019-01-07 11:01:15 so, it is fixed, probably 2019-01-07 11:03:15 clandmeter, no, at least not intentionally. i don't think i logged into it at all. 2019-01-07 11:23:24 fabled, ok, then it must be ncopa 2019-01-07 11:23:55 ncopa, i removed ncurses-dev from world on build-edge-armv7 2019-01-07 11:32:38 ncurses source url is broken, need change 2019-01-07 11:49:06 mps, I did disable only perf test (35) but builder still reports other tests failed for armv7 2019-01-07 11:49:20 andypost[m], hi 2019-01-07 11:49:28 can we disable it on arm? 2019-01-07 11:49:43 until you find a more perm fix. 2019-01-07 11:50:37 clandmeter only on armv7 but mps reported that it builds & pass check locally 2019-01-07 11:51:12 I dud test in chroot and it failed for me 2019-01-07 11:51:25 yes for armv7 2019-01-07 11:52:32 Imo better to disable tests on it cos package mostly works except randdom data generation for tests 2019-01-07 11:52:59 did you verify it works on armv7? 2019-01-07 11:53:28 It looks like something weird with random data generator for armv7 2019-01-07 11:53:39 Yes, in chroot 2019-01-07 11:54:20 i would prefer to disable the aport and ask upstream to fix the tests. 2019-01-07 11:54:47 i dont have time to figure it out. 2019-01-07 11:54:48 andypost[m]: it fails locally test no. 35 on both armv7 and aarch64 2019-01-07 11:54:50 Guts tells that something happens with edge armv7 builder 2019-01-07 11:55:16 I did disable this test 2019-01-07 11:55:50 seen already and tested on armv7 with 'abuild -r'. all is ok 2019-01-07 11:55:51 ive bumped into a few issues which are causes by upstream wrongly detecting cpu 2019-01-07 11:56:06 https://github.com/alpinelinux/aports/pull/5969 2019-01-07 11:57:00 In mentioned issue there's details about 35.phpt 2019-01-07 11:58:05 I tested on v3.9 only 2019-01-07 11:58:45 But only edge fails! 2019-01-07 12:00:46 ah, I converted my build machine from edge to v3.9 few days ago (about one week) so only can test on v3.9 2019-01-07 12:23:37 andypost[m], i think it never build for v3.9? 2019-01-07 12:33:30 clandmeter I will check in 1h 2019-01-07 12:36:04 Btw clandmeter I did add yesterday extra dependencies to mapserver looks like gdal did not provide dependency on sqlite and only on x86-64 2019-01-07 12:37:29 https://git.alpinelinux.org/aports/commit/?id=7d2432fb also will need revert 2019-01-07 12:38:01 yes its a hack 2019-01-07 12:38:03 just tried php7-pecl-msgpack on aarch64 v3.9 and it build without error 2019-01-07 12:38:19 andypost[m], something is wrong with gdal, but i dont know what. 2019-01-07 12:38:38 Tests passed : 110 ( 96.5%) (100.0%) 2019-01-07 12:39:09 speaking of php and bugs on Alpine: https://gitlab.com/jvoisin/snuffleupagus/-/jobs/141215983 I have some issues with my module not being able to find the ps_globals symbol, any idea why? 2019-01-07 12:39:26 jvoisin, is it in test phase? 2019-01-07 12:40:44 what do you mean by "in test phase" ? 2019-01-07 12:41:05 abuild check 2019-01-07 12:41:22 there isn't a package yet 2019-01-07 12:41:22 or make test 2019-01-07 12:41:39 I'm only doing a `make; make test` in the source of the extension, on a AL system 2019-01-07 12:41:51 thats what im saying 2019-01-07 12:42:09 you've got the results on the page that I pasted 2019-01-07 12:42:41 i have no time to debug. could be related to LD_PRELOAD 2019-01-07 12:43:11 LD_PRELOAD of what? 2019-01-07 12:43:34 (It's ok, I just wanted to know if anyone knew about this issue, before investing time in debugging it myself) 2019-01-07 13:12:26 clandmeter, looks gdal build failed on edge arm7 https://github.com/alpinelinux/aports/pull/5958#issuecomment-451925161 2019-01-07 13:50:13 i have restarted the build-edge-armv7 2019-01-07 13:58:21 ncopa: did you tried https://patchwork.alpinelinux.org/patch/4374/ patch for libcoro 2019-01-07 13:59:06 it disables ASM CFLAGS option and set SJLJ 2019-01-07 14:00:13 although this slowed down libcoro to a about half of the speed of ASM variant 2019-01-07 14:00:38 but solves test problem for armv7 2019-01-07 14:12:04 i havent looked at that yet 2019-01-07 14:30:13 ncopa, why restart? 2019-01-07 14:31:25 clandmeter: because i like restarting the builders :) 2019-01-07 14:31:30 for retry 2019-01-07 14:31:51 there are sometimes test suites that leave prcesses running, like epmd 2019-01-07 14:31:54 you mean the build or the whole container? 2019-01-07 14:31:58 the container 2019-01-07 14:32:04 yes i killed epmd 2019-01-07 14:32:08 and also X... 2019-01-07 14:32:18 i normally reboot it and it cleans it up 2019-01-07 14:32:31 reboot is for windows 2019-01-07 14:32:32 we should run those builds in disposable containers 2019-01-07 14:32:33 "when in doubt, always reboot" ? 2019-01-07 14:33:04 "reboot", is shorter to type than /etc/init.d/mqtt-exec.aports-build 2019-01-07 14:33:38 <_ikke_> lol 2019-01-07 14:33:40 that is the real reason i prefer reboot containers :) 2019-01-07 14:33:48 did you see my 2 msgs? 2019-01-07 14:34:11 or atleast one :) 2019-01-07 14:34:24 regarding ncurses 2019-01-07 14:34:31 ah, possibly 2019-01-07 14:34:57 i may have installed ncurses-dev manually 2019-01-07 14:35:09 it may be leftovers from kernel config 2019-01-07 14:35:11 and i had to upgrade the builder manually 2019-01-07 14:35:16 when does that happen? 2019-01-07 14:35:20 but it sounds weird 2019-01-07 14:35:27 the build-edge-armv7? 2019-01-07 14:35:37 uhm yes i think so 2019-01-07 14:35:43 it had older gcc 2019-01-07 14:35:50 ph 2019-01-07 14:35:51 oh 2019-01-07 14:35:57 so it was stuck 2019-01-07 14:36:04 not good 2019-01-07 14:36:15 it only upgrades system after complete cycle? 2019-01-07 14:36:34 there were like 30 pkgs 2019-01-07 14:36:45 thats why i also asked about libtls 2019-01-07 14:36:52 why its still on the edge builder 2019-01-07 14:37:10 hm 2019-01-07 14:37:12 i noticed when i upgraded that builder it got rid of it. 2019-01-07 14:37:16 its build-edge-armv7, right? 2019-01-07 14:37:30 libtls is also on x86 afaik 2019-01-07 14:37:47 it complained it needed to overwrite certs.pem 2019-01-07 14:37:49 it was on build-edge-armv7 it was not upgraded? 2019-01-07 14:37:55 yes 2019-01-07 14:38:25 yep im sure now 2019-01-07 14:38:27 i think i may know why 2019-01-07 14:38:29 build-edge-armv7 2019-01-07 14:38:46 i think buildozer user is not in sudoers 2019-01-07 14:39:06 it is supposed to work without be in sudoers 2019-01-07 14:39:16 ok, but what about x86 builder? 2019-01-07 14:39:20 same issue? 2019-01-07 14:39:29 probably not. I'll have a look at it 2019-01-07 14:40:09 thx 2019-01-07 14:40:49 i think they still have libressl2.7-libcrypto 2019-01-07 14:42:16 yup 2019-01-07 14:42:28 i think it was leftovers from the libressl -> openssl switch 2019-01-07 14:42:37 build-edge-x86 was rebooted ;) 2019-01-07 14:43:45 would rootbld prevent those lingering processes? 2019-01-07 14:43:59 yes, i think so 2019-01-07 14:44:16 so we could enable that for some problematic builds 2019-01-07 14:44:25 i wonder if we should try make the builders use rootbld by default 2019-01-07 14:44:35 or just enable it completely after 3.9 2019-01-07 14:44:42 and disable on issues 2019-01-07 14:44:50 or if we should spend the time on redesign the build infra 2019-01-07 14:44:53 build it from scratch 2019-01-07 14:45:00 i know there will be issues with rootbld 2019-01-07 14:45:07 yes 2019-01-07 14:45:17 question 1: does it work in lxc? eg. nested containers 2019-01-07 14:45:33 yes it works 2019-01-07 14:45:37 i use it in a container 2019-01-07 14:45:42 ok. good 2019-01-07 14:46:24 i think nested containers are not very relia ble though. i'm afraid its a box of worms 2019-01-07 14:46:58 i havent seen any issue before. except some networking things. 2019-01-07 14:47:13 i think more of us use rootbld 2019-01-07 14:59:49 pushed llvm5 update and firefox-esr update 2019-01-07 15:00:00 what is left for alpine v3.9 rc1 now? 2019-01-07 15:01:28 chromium on arm if we want it. 2019-01-07 15:07:32 do we need it for rc1? 2019-01-07 15:07:43 i think we may need chromium fixed 2019-01-07 15:07:53 win only have firefox on x86_64 now 2019-01-07 15:07:56 we* 2019-01-07 15:08:39 due to rust 2019-01-07 15:11:38 looks like they solved rust issue on adelie: https://code.foxkit.us/adelie/packages/blob/master/user/rust/APKBUILD 2019-01-07 15:11:52 maybe we can borrow their static builds for bootstrap 2019-01-07 15:12:29 https://distfiles.adelielinux.org/source/rust/ 2019-01-07 15:15:39 clandmeter: we had this too: https://patchwork.alpinelinux.org/patch/4374/ 2019-01-07 15:28:00 void has cross-rust working now, but there are still problems with firefox-cross. 2019-01-07 15:54:14 nice 2019-01-07 15:54:35 Gottox: which architectures do you have rust on? 2019-01-07 15:57:04 aarch64 armv6l armv7l i686 x86_64 2019-01-07 15:57:45 maybe powerpc64 too, but we don't have a builder for that port yet. 2019-01-07 15:58:33 ff only compiles on *86 and aarch64. 2019-01-07 16:41:38 clandmeter: regarding your fix for libcoro, I thought to propose it, as I wrote to Timo's mail 2019-01-07 16:42:13 looks fine, will test later, now I have to go out 2019-01-07 21:32:38 Gottox: I see in APKBUILD for rust that it makedepends on llvm6, could it be built with llvm5 because that version is in Alpine 2019-01-08 00:26:55 on aarch64 I got cargo built: src/prebuilt/bin/cargo 2019-01-08 00:27:39 Rust's package manager ^M USAGE:^M cargo [OPTIONS] [SUBCOMMAND] etc... 2019-01-08 09:20:08 nice! 2019-01-08 10:06:08 fcolista: why you removed socat from depends from acme.sh? https://patchwork.alpinelinux.org/patch/4383/ it is useful in standalone mode 2019-01-08 10:14:28 mps, why is it needed? 2019-01-08 10:14:35 useful sound not a requirement 2019-01-08 10:17:00 clandmeter: if you don't have http server on machine where you are run acme.sh it starts socat to listen on http port instead of 'real' server 2019-01-08 10:18:45 that sounds like a useful thing to have, but not really needed for everyone. 2019-01-08 10:19:14 so maybe its better to let the user decide what to use/install. 2019-01-08 10:20:17 the idea with depends is, if it doesnt work without it we add it to depends, else we let the user decide. 2019-01-08 10:21:12 well, yes, apk doesn't have 'recomends' or some similar field 2019-01-08 10:21:26 mps, i have not removed it 2019-01-08 10:21:53 it can be added as optional dependency 2019-01-08 10:21:59 mps, apk doesnt have many things, thats why its so fast :) 2019-01-08 10:22:43 I've not merged your patch 2019-01-08 10:23:01 also, acme.sh needs curl (or wget) 2019-01-08 10:23:16 clandmeter: right, but sometimes I miss some of them 2019-01-08 10:23:47 fcolista: yes, curl is better to have than wget 2019-01-08 10:24:26 wget is actually broken on AL 2019-01-08 10:25:09 mps, broken? 2019-01-08 10:25:17 and, I forgot to put curl 2019-01-08 10:26:15 clandmeter: in my case, yes: wget https://alpinelinux.org 2019-01-08 10:26:26 OpenSSL: error:02FFF002:system library:func(4095):No such file or directory 2019-01-08 10:26:40 is it edge? 2019-01-08 10:26:44 or 3.9? 2019-01-08 10:27:04 wget-1.19.5-r0 = 1.19.5-r0 2019-01-08 10:27:14 v3.8 2019-01-08 10:28:00 havent seen that error before 2019-01-08 10:29:31 on egde or v3.9, it works, I think 2019-01-08 10:29:48 mps: did you apk upgrade? 2019-01-08 10:30:35 ncopa-desktop:~$ docker run --rm -it alpine:3.8 sh -c "apk upgrade -U -a && wget https://alpinelinux.org" | tpaste 2019-01-08 10:30:35 http://tpaste.us/W1xY 2019-01-08 10:32:18 ncopa: busybox wget works fine, I know and I use it instead of wget apk 2019-01-08 10:36:33 for me, it is not a problem, but speak about (well) ordinary users, could be. I thought to check wget 'proper' but didn't had strong incentive 2019-01-08 10:37:31 so its GNU wget thats broken? 2019-01-08 10:37:44 ncopa: right 2019-01-08 10:38:37 ncopa-desktop:~$ docker run --rm -it alpine:3.8 sh -c "apk upgrade -U -a && apk add wget && wget https://alpinelinux.org" | tpaste 2019-01-08 10:38:37 http://tpaste.us/gMgm 2019-01-08 10:38:39 works for me? 2019-01-08 10:39:41 ncopa: edge or v3.9? it doesn't work on v3.8 2019-01-08 10:39:57 that was v3.8 2019-01-08 10:40:01 can you strace it? 2019-01-08 10:40:12 do you have ca-certificates installed? 2019-01-08 10:42:45 huh, just removed .wgetrc and it works. sorry for noise and taking your time :( 2019-01-08 10:43:22 np. thanks for checking 2019-01-08 10:43:53 your advice to run it with strace showed me what is wrong. 2019-01-08 10:44:04 :) 2019-01-08 10:44:51 should write short note for me: before reporting bug first try strace/ltrace! 2019-01-08 10:45:14 well, i think its a good idea to mention it in IRC 2019-01-08 10:45:25 as you may get hints on how to troubleshoot 2019-01-08 10:46:28 i mean, we help each other 2019-01-08 10:46:45 I know that, but we are all ordinary people in the end, so we are tend to forget important things ;) 2019-01-08 10:47:56 ncopa: btw, rust build reached to the point of linking rustlibs (I think) but then it is killed with: Out of memory: Kill process 32004 (rustc) score 766 or sacrifice child 2019-01-08 10:48:02 ncopa, what is still missing for 3.9 ? 2019-01-08 10:48:35 fcolista: we need look over the bugs and PRs and see if there are anything critical 2019-01-08 10:48:50 are the builders completed? 2019-01-08 10:49:03 I've closed all bugs assigned to me. Going to check what else is needed 2019-01-08 10:49:07 i need to check that biulders are done, and set them to halt on first error 2019-01-08 10:49:19 then we do rc1 I suppose 2019-01-08 10:49:38 i am currently building firefox-esr 2019-01-08 10:49:49 https://bugs.alpinelinux.org/issues/9815 2019-01-08 10:49:51 there was a patch that needed update 2019-01-08 10:49:52 cargo and rustc works 2019-01-08 10:50:00 yes this is a must 2019-01-08 10:50:27 cargo and rustc works on aarch64, i mean 2019-01-08 10:50:49 fcolista: firefox-esr was pushed already 2019-01-08 10:51:20 good 2019-01-08 10:51:27 mps: do you think you can provide a patch for cargo+rust on aarch64? 2019-01-08 10:51:35 i think it needs to be bootstrapped somehow 2019-01-08 10:51:52 i would be very happy if we can squeze it in for v3.9 2019-01-08 10:52:52 I used files from adelie, just to try and see if cargo could be built, but reached to the point of building libs 2019-01-08 10:53:23 I made APKBUILD but it is full of hackish tweaks 2019-01-08 10:54:44 fcolista: i would also like to fix the lua-aports buildrepo script a bit 2019-01-08 10:54:55 specifically the error reporting to mqtt script 2019-01-08 10:55:07 is currently part of config 2019-01-08 10:55:08 will put usb ssd disk later, and stop X, firefox and some other apps on box to see if it could pass with a little more free RAM 2019-01-08 10:57:20 and, 'src/prebuilt/bin/rustc --print target-list | grep musl' shows: aarch64-unknown-linux-musl, among others 2019-01-08 12:13:28 i am making the 3.9 builders halt on errors 2019-01-08 12:33:50 current issues: clang does not build on armhf, binaryen fails to build on aarch64 (i think i have a fix coming up), shards fails on x86_64 2019-01-08 14:03:53 beta.3? 2019-01-08 14:03:58 dammit, wrong -devel again 2019-01-08 17:55:06 ncopa: ncurses aport patch is here: https://patchwork.alpinelinux.org/patch/4386/ 2019-01-08 18:00:22 um. 2019-01-08 18:00:29 that is effectively a downgrade 2019-01-08 18:00:42 can we do that without rebuilding everything linked to ncurses? 2019-01-08 18:01:19 maybe we should continue with those release snapshots til next stable release and stay there 2019-01-08 18:01:47 yes, it is downgrade, and I thought about what you ask right now. Not sure of the answer :/ 2019-01-08 18:02:11 I agree, that will be safer 2019-01-08 18:02:12 also, if there are security fixes, will they be fixed in those snapshot releases or properly backported to the stable? 2019-01-08 18:02:48 if you look at the secfixes history 2019-01-08 18:02:55 it seems that 6.0 had some security fixes 2019-01-08 18:03:03 I suspect that they will fix stable, probably distros have to backport 2019-01-08 18:03:20 # 6.0_p20171125-r0: 2019-01-08 18:03:20 # - CVE-2017-16879 2019-01-08 18:03:20 # - CVE-2017-10684 2019-01-08 18:03:20 # 6.0_p20170701-r0: 2019-01-08 18:03:44 it looks like they only released new snapshot release 2019-01-08 18:03:50 and no 6.0.1 2019-01-08 18:04:11 right, I concluded the same 2019-01-08 18:04:18 i think that may be the reason why we started use those 2019-01-08 18:04:31 i sort of though upstream expected distros to do so 2019-01-08 18:04:48 looks like you are right 2019-01-08 18:05:47 ncopa, php5 is eol when this pr could be commited? 2019-01-08 18:06:04 ah 2019-01-08 18:06:10 lets merge that PR 2019-01-08 18:06:20 so we have to find last secfixed release and use it, and keep eye on CVE for it 2019-01-08 18:06:35 right 2019-01-08 18:06:47 we still may have a downgrade problem 2019-01-08 18:07:02 if they introduced new symbols and something compiletiem detected those and use those 2019-01-08 18:07:09 compiletime* 2019-01-08 18:07:27 ok, will try to find release which would be most appropriate 2019-01-08 18:07:51 so i'd say the safest way forward would be to continue with those snapshots til ncurses 6.2 is released, and then we stick to that til a security problem forces us to upgrade 2019-01-08 18:08:03 or you could ask upstream what they advice us to do 2019-01-08 18:08:31 good idea, will try 2019-01-08 18:08:50 ncopa, https://github.com/alpinelinux/aports/pull/5569 2019-01-08 18:08:58 mps: thank you for following that up! 2019-01-08 18:10:00 you are welcome 2019-01-08 18:10:15 (speaking of php, who could I bother with some php7-related compilation issue on alpine?) 2019-01-08 18:11:01 andypost: can you help me rebase PR aports#5569? 2019-01-08 18:11:33 algitbot: thank you for trying.... 2019-01-08 19:14:16 can someone help me with the gdal package? andypost merged my PR aports#5958 but the new version 2.4.0 is not available in edge for armhf, armv7, and s390x. 2019-01-08 19:28:16 ncopa I will rebase tonight 2019-01-09 03:11:59 ncopa, rebased https://github.com/alpinelinux/aports/pull/5569 ready to commit 2019-01-09 07:34:50 andypost: thank you! 2019-01-09 09:25:58 clandmeter: i was just looking at cyrus-sasl 2019-01-09 09:26:16 dont look any further :) 2019-01-09 09:26:20 or you wanted to fix ldap? 2019-01-09 09:26:38 i didnt have enough energy to look into the ldap issue. 2019-01-09 09:26:48 no i was not looking at ldap 2019-01-09 09:26:58 but i think we may want enable ldbm support 2019-01-09 09:27:08 and if possible remove berkdb support 2019-01-09 09:27:18 i dont think we an remove berkdb yet though 2019-01-09 09:27:47 i looked at fedora and gentoo 2019-01-09 09:27:48 <_ikke_> isn't berkdb necessary for sasldb? 2019-01-09 09:27:51 i dont think they enabled it 2019-01-09 09:28:07 i think you can choose to use lmdb 2019-01-09 09:28:46 did you also looked at the avoid_pic_overwrite patch? 2019-01-09 09:29:39 i didnt look into much details as i was trying to setup the smtpd and fix that aport. 2019-01-09 09:29:53 so what i did was look at others and copy what looked sane. 2019-01-09 09:30:30 sasldb was not enabled at all, that was my main concern 2019-01-09 09:30:57 ok 2019-01-09 09:31:18 ok the avoid_pic_overwrite looks correct 2019-01-09 09:31:19 thanks! 2019-01-09 09:31:27 i'll follow your advice and look no more :) 2019-01-09 09:31:35 haha 2019-01-09 09:31:37 thats a first 2019-01-09 09:31:40 ;-) 2019-01-09 09:31:57 <_ikke_> :-D 2019-01-09 09:31:58 but seriously, it could be i misssed sometimg cause this setup was a freaking nightmare 2019-01-09 09:32:13 glad _ikke_ helped 2019-01-09 09:32:23 cause i had square eyes 2019-01-09 09:32:56 regarding our prev discussion, it would be nice to have ldap enabled. 2019-01-09 09:33:18 its a minor thing i think. some linker issue i htink. 2019-01-09 09:33:40 not sure we also want to have db support, others have it. 2019-01-09 09:34:56 and i think it also makes sense to split saslauthd 2019-01-09 09:35:09 <_ikke_> from the tools? 2019-01-09 09:35:14 yes 2019-01-09 09:35:19 its a bit confusing at first 2019-01-09 09:35:20 <_ikke_> Yes, makes sense to me as well 2019-01-09 09:36:13 the only thing that worries me is that sasldb is still considered "experimental" 2019-01-09 09:36:32 i guess thats also the reason fedora has disabled it. 2019-01-09 09:36:50 <_ikke_> probably someone forgot to remove that designation? 2019-01-09 09:38:19 designation? 2019-01-09 09:39:08 that traefik error on arm also looks suspicious 2019-01-09 09:39:39 panic: runtime error: invalid memory address or nil pointer dereference [recovered] 2019-01-09 09:39:40 panic: runtime error: invalid memory address or nil pointer dereference 2019-01-09 09:39:40 [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x91f148] 2019-01-09 10:01:01 clang on armhf seems to be broken: https://build.alpinelinux.org/buildlogs/build-3-9-armhf/community/afl/afl-2.52b-r0.log 2019-01-09 10:03:03 Failing Tests (2): 2019-01-09 10:03:03 Clang-Unit :: AST/./ASTTests/NamedDeclPrinter.TestNamespace2 2019-01-09 10:03:03 Clang-Unit :: AST/./ASTTests/NamedDeclPrinter.TestUnscopedUnnamedEnum 2019-01-09 10:03:03 Expected Passes : 10958 2019-01-09 10:03:03 Expected Failures : 19 2019-01-09 10:03:03 Unsupported Tests : 78 2019-01-09 10:03:03 Unexpected Failures: 2 2019-01-09 10:03:43 Hello, I couldn't find license information for aports project itself. Wondering what it should be. Thanks. 2019-01-09 10:04:52 we should add that to the FAQ 2019-01-09 10:05:46 or put a license in root? 2019-01-09 10:06:04 @clandmeter: that sounds better 2019-01-09 10:06:13 aports/LICENSE some sort 2019-01-09 10:06:58 @clandmeter: but for the record, what is the current license for aports ? Or it doesn't have yet or this was not discussed before ? 2019-01-09 10:14:37 alpine_user: there have been questions about it earlier, but we havent really discussed it 2019-01-09 10:22:06 its a mixed bag of licences. i guess we can put all apkbuilds into a single license. but lots of patches are taken from several places. 2019-01-09 10:22:27 ncopa, do you have an idea what others do? 2019-01-09 10:37:30 i dont know 2019-01-09 10:37:44 well the patches goes with the package license 2019-01-09 10:37:57 the question is for the APKBUILD itself 2019-01-09 10:47:29 I wonder if we fetch the patch from fedora if it follows the same license? 2019-01-09 10:49:35 the patch will be compiled into the package itself so it should follow package license unless specified otherwise 2019-01-09 10:52:40 it can't be discussed, unfortunately. 2019-01-09 10:53:42 the apkbuilds already there are under whatever license their author wants; you can set a condition for future APKBUILDs to be accepted 2019-01-09 10:54:24 and if there's no license specified by the author so far, it has no license, the copyright belongs to the author 2019-01-09 10:54:39 that's the short summary of the conversations so far 2019-01-09 11:06:14 in theory that applies to patches and modifications too 2019-01-09 11:06:45 so if you submit a patch or PR to some upstream project, and does not explicitly tell which license that change is, then what? 2019-01-09 11:10:12 looks like builders for v3.9 are all done 2019-01-09 11:10:23 they are all idle 2019-01-09 11:10:38 anything important we need to fix before we do rc1? 2019-01-09 11:10:53 ncopa: recoll url is broken. there is new upstream version could be fixed easily, but will it then trigger rebuild on all builders? 2019-01-09 11:11:16 if I stay consistent with what I wrote above, unless there's a requirement by the project to license those under a specific license that the committer needs to accept, standard copyright applies ... it's a mess 2019-01-09 11:16:49 ah, ok, clandmeter just upgraded recoll 2019-01-09 11:17:06 hi yes i did 2019-01-09 11:18:28 will that trigger rebuild on all arch's, just curious 2019-01-09 11:18:49 yes, its a version change 2019-01-09 11:19:31 only edge or also v3.9? 2019-01-09 11:19:55 there is no v3.9 branch 2019-01-09 11:19:57 yet 2019-01-09 11:20:11 it will be branched on release 2019-01-09 11:20:32 so it follows master(edge) 2019-01-09 11:21:05 but its testing repo 2019-01-09 11:21:14 so thats not enabled on v3.9 builder 2019-01-09 11:22:18 hmm, what then build-3-9-armhf is on build.a.o. 2019-01-09 11:22:20 <_ikke_> clandmeter: I'm wondering, how do minor releases work? Does that only influence the images, because the repos only track the major version 2019-01-09 11:24:55 minor as in semver? 2019-01-09 11:25:07 <_ikke_> yes 2019-01-09 11:25:15 <_ikke_> that would be patch I guess 2019-01-09 11:25:25 <_ikke_> x.y.z 2019-01-09 11:25:34 patch is only a tag in branch 2019-01-09 11:25:54 so it only affects releases 2019-01-09 11:26:07 you dont have to update your repo file 2019-01-09 11:26:15 <_ikke_> Yes, right 2019-01-09 11:26:58 <_ikke_> So patch releases don't affect a whole lot except from not havint to install so many updates after installation 2019-01-09 11:27:00 <_ikke_> correct? 2019-01-09 11:27:40 yes, and you have another kernel. 2019-01-09 11:27:50 if you have tmpfs isntall it matters 2019-01-09 11:29:03 <_ikke_> right, though you could probably update the kernel on the boot media without releases as well, right? 2019-01-09 11:29:36 the bootmedia has a different kind of kernel. it has modloop which you need to generate. 2019-01-09 11:29:54 i mean the kernel is the same, but format its shipped is differerent 2019-01-09 11:30:29 <_ikke_> Ok thanks, didn't know that 2019-01-09 11:31:12 on cdrom its difficult to update anything :) 2019-01-09 11:31:24 so you will always boot the current kernel 2019-01-09 11:31:35 <_ikke_> yes, obviously 2019-01-09 11:31:52 the modloop is mounted which contains the modules and firmware 2019-01-09 11:32:04 and initramfs will mount and load modules. 2019-01-09 12:36:55 do we need 'update_config_guess || return 1' in prepare() of APKBUILD for testing/dante? 2019-01-09 12:37:56 removing it dante builds on armv7 and x86_64, where I tried, but before need checksum update 2019-01-09 12:46:42 anyway, patch is here for review: https://patchwork.alpinelinux.org/patch/4397/ 2019-01-09 14:08:57 mps: whoops! i had a checksum fix in my local queue which got pushed. sorry! 2019-01-09 14:09:01 for dante 2019-01-09 14:19:45 ncopa: np, what about update_config_guess in prepare()? did you fixed it, too 2019-01-09 14:23:03 nope 2019-01-09 14:28:10 for some reason update_config_guess tries to write to config.guess but it's mode is 0555 so prepare() fails 2019-01-09 14:28:39 in $pkgsrc dir, I mean 2019-01-09 14:36:55 mps, should be ok like this thx. 2019-01-09 14:37:28 mps, why did you bump pkgrel? 2019-01-09 14:39:46 clandmeter: thought it is must for every patch 2019-01-09 14:40:29 no only if the resulting pkg will be different. 2019-01-09 14:40:44 and from non to one is not a change :) 2019-01-09 14:41:03 so for build errors you just need to fix the apkbuild without bump 2019-01-09 14:41:09 else all other arch will build it too 2019-01-09 14:41:29 oh, didn't know. thanks for explanation 2019-01-09 14:41:43 build will check if the version from apkindex == apkbuild 2019-01-09 14:41:58 ACTION have to learn every day something 2019-01-09 14:43:14 mps, i didnt have time yet to do what i promised. ill try do that later today. 2019-01-09 14:44:22 clandmeter: I'm not in hurry, just waiting to see -rc1 :) 2019-01-09 14:45:07 I'm working on fix for testing/go-bindata on armv7 2019-01-09 14:45:40 that should fix traefik, too 2019-01-09 15:05:22 the update of lua-aports uncovered some circular deps 2019-01-09 15:05:35 some packages was not built due to circular make depends 2019-01-09 15:11:11 $ docker run --rm -it alpine:3.8 sh -c "sed -i -e 's/v3.8/v3.9/g' /etc/apk/repositories && apk update -q && apk dot --errors" | tpaste 2019-01-09 15:11:11 http://tpaste.us/wjxP 2019-01-09 15:11:30 anyone interested in fixing those packages? they are circular deps 2019-01-09 15:11:58 all of them? 2019-01-09 15:12:11 or unstatisfied/missing deps 2019-01-09 15:12:19 <_ikke_> rendered: http://g.jk.gs/Jc.png 2019-01-09 15:12:21 looks like most of them are circular deps 2019-01-09 15:12:33 how can i catch a local circdep? 2019-01-09 15:13:25 i think those comes from "bug" in abuild 2019-01-09 15:13:36 when running split function depends is not reset 2019-01-09 15:13:43 so it inherits the depends from main package 2019-01-09 15:14:05 so that means we just need to bump them? 2019-01-09 15:14:11 so if main package foo has depends="foo-common" and foo-common is a subpackage 2019-01-09 15:14:27 then the fix to set depends="" in foo-common split function 2019-01-09 15:14:39 its not fixed in abuild yet 2019-01-09 15:15:58 the foo-common gets the depends from global depends=foo-common 2019-01-09 15:16:09 i guess we should fix that in abuild 2019-01-09 15:18:36 http://tpaste.us/J6Rq 2019-01-09 15:21:53 just scary to do this change this late in the game 2019-01-09 15:22:05 but i think its the easiest way to fix those 2019-01-09 15:25:33 actually 2019-01-09 15:26:01 those who depend on themselves may have other broken or unexpected depends in other subpackages 2019-01-09 15:26:16 we should probably verify that all other subpackages' depends are correct too 2019-01-09 15:31:41 clandmeter: i have pushed fix for abuild, so now it should be enough to just rebuild those 2019-01-09 15:32:47 ok, i need to wait for abuild to arrive 2019-01-09 15:32:57 or build it myself 2019-01-09 15:35:30 ncopa, so a subpackage cannot depend on origin? 2019-01-09 15:35:44 or it automatically does? 2019-01-09 15:36:44 subpackages can depend on origin 2019-01-09 15:37:05 the problem is that subpackages automatically gets origin's depends as depends too 2019-01-09 15:37:17 so if origin has depend=subpkg 2019-01-09 15:37:30 then will all subpackages also get depend=subpkg 2019-01-09 15:37:39 and subpkg gets a circular depend 2019-01-09 15:37:44 depend on itself 2019-01-09 15:40:34 heh... samba is a pure nightmare to get right 2019-01-09 15:42:19 hmm 2019-01-09 15:42:25 ncopa, i have this for tvheadned: depends="$pkgname !$pkgname-dvb_scan" 2019-01-09 15:42:42 and depends="$pkgname !$pkgname-satellites_xml" in other subpkg 2019-01-09 15:43:18 what is causing the issue? what should i change? 2019-01-09 15:43:23 or is a rebuild enough? 2019-01-09 15:44:04 i dont think a rebuild will fix that 2019-01-09 15:44:29 rebuild will only fix depends of itself 2019-01-09 15:44:46 i think we can ignore those who are depends=! 2019-01-09 15:44:59 i think it flags when something is not existing 2019-01-09 15:45:18 depend="!foo" 2019-01-09 15:45:27 it is ok that foo does not exist 2019-01-09 15:45:38 but apk dot --error will flag it 2019-01-09 15:45:46 should probably be reported to fabled 2019-01-09 15:47:35 it flags if non existing. but both exist. 2019-01-09 15:51:51 i think we should also add openrc subpkg check to abuild. 2019-01-09 15:53:10 i dont think i can help much. almost time to go 2019-01-09 16:02:07 same here 2019-01-09 16:02:10 need to go soon 2019-01-09 16:02:14 re snapcast 2019-01-09 16:02:27 why use install_if in that case? 2019-01-09 16:02:33 depends will be much better 2019-01-09 16:02:48 install_if does not make any sense if there are only a single condition 2019-01-09 16:03:17 im utterly confused about what to add to depends now. 2019-01-09 16:04:06 so i can depend on subpackages just fine? 2019-01-09 16:04:13 yes 2019-01-09 16:04:23 so why is it erroring? 2019-01-09 16:05:14 because depends="snapcast-client snapcast-server" 2019-01-09 16:05:19 for all of them 2019-01-09 16:05:33 ah ok 2019-01-09 16:05:40 so i need to reset it downstream? 2019-01-09 16:05:40 origin + subpackages has all the deps 2019-01-09 16:05:56 http://tpaste.us/8VMb 2019-01-09 16:05:59 some doc on how it really works would be nice. 2019-01-09 16:05:59 i can fix it 2019-01-09 16:06:25 i think I'll fix it in abuild after v3.9 release 2019-01-09 16:07:20 i think in many cases you dont want origin depends in subpkgs 2019-01-09 16:08:46 exactly 2019-01-09 16:08:52 so we need fix that in abuild 2019-01-09 16:09:09 its trivial to fix, i am just afraid of unintentional consequences now 2019-01-09 16:13:30 i think libvirt can be fixed with a separate libvirt-libs subpackage 2019-01-09 18:46:55 Could someone initiate the building of lightdm for armv7? It is supported by `$arch` in the APKBUILD, but it isn't actually built 2019-01-09 18:48:25 actually, it has even been built, but it's nowhere to be found on the repos. https://build.alpinelinux.org/buildlogs/build-edge-armv7/testing/lightdm/lightdm-1.26.0-r1.log 2019-01-09 19:14:39 PureTryOut[m]: i think if next build fails it will abort before it rsyncs 2019-01-09 19:15:13 this one is blockg it: https://build.alpinelinux.org/buildlogs/build-edge-armv7/testing/perl-sql-abstract/perl-sql-abstract-1.84-r0.log 2019-01-09 19:16:06 Interesting, as perl-moo is already available on armv7 2019-01-09 19:16:16 But it seems bad that it doesn't rsync if some other package fails to build... 2019-01-09 19:17:16 yeah 2019-01-09 19:17:28 it is by design sort of 2019-01-09 19:17:47 it is to discourage push broken stuff 2019-01-09 19:18:03 and force us to fix those things asap 2019-01-09 19:18:13 otherwise those broken will stay forever broken 2019-01-09 19:19:10 Ah. Well, these things can still go unnoticed for a long time. Do you guys get a notification if something breaks on the build bots? 2019-01-09 19:23:40 should be visible here: https://build.alpinelinux.org/ 2019-01-09 19:23:55 and you can subscribe to mqtt messages 2019-01-09 19:24:15 i normally get a desktop notification 2019-01-09 19:28:16 oh 2019-01-09 19:28:20 you know what 2019-01-09 19:28:34 its the testing repository that is not completely built yet 2019-01-09 19:28:45 for armv7 2019-01-09 19:28:57 i guess there are lot of old broken stuff there 2019-01-09 19:29:16 i guess we should cimply move the things not touched for last 6months and move to unmaintained 2019-01-09 19:29:44 i dont have time to fix all those now 2019-01-09 19:29:45 Idk if stuff not touched for 6 months means it's unmaintained, but it's probably good to clean it out a bit yes 2019-01-09 19:29:59 I personally just want lightdm in the repos right now lol 2019-01-09 19:30:45 i guess testing and fixing it on x86_64 now, and then ask for move it to community is the fastest path right now 2019-01-09 19:31:23 i'll make it continue on error for now 2019-01-09 19:31:41 lightdm? it builds and works fine on at least x86, x86_64, armhf and aarch64. I don't mind moving it to community, but I'm not the maintainer of the package 2019-01-09 19:32:36 apparently I am the maintainer 2019-01-09 19:32:44 iirc i had some issues last time i tested it 2019-01-09 19:32:57 is default config ok? 2019-01-09 19:33:52 yeah works for us on postmarketOS 2019-01-09 19:38:10 i just tried apk add lightdm in a qemu vm 2019-01-09 19:38:17 nothing happens when i start the lightdm service 2019-01-09 19:39:28 failed to get logind seats 2019-01-09 19:39:32 do you have a greeter installed? 2019-01-09 19:39:33 as that's a requirement for it to run 2019-01-09 19:39:42 also, a DE or WM to boot into 2019-01-09 19:41:15 installing a greeter seems to help alot :) 2019-01-09 19:41:42 :D 2019-01-09 19:42:12 problem is that there are multiple greeters you can choose from, so you can't really set a default 2019-01-09 19:42:27 i was wondering if it would make sense to add install_if 2019-01-09 19:42:36 and install gtk greeter if gtk was installed 2019-01-09 19:42:39 lightdm build depends on accountsservice which is in testing 2019-01-09 19:43:05 but i suppose you may have gtk installed for some apps but still not want the gtk greeter 2019-01-09 19:43:10 I guess if both lightdm and gtk installed, it could safely be installed yes 2019-01-09 19:43:15 ah that's true as well 2019-01-09 19:43:38 right now Alpine has only lightdm-gtk-greeter it seems, so it's safe for now. probably not the best once there are more greeters packaged though 2019-01-09 19:43:45 maybe just add a wiki page? 2019-01-09 19:52:10 just built lightdm on armv7, but install is not fine 2019-01-09 19:53:53 what do you mean? 2019-01-09 19:55:37 removed accountsservice from depends, rebuilt with 'abuild -r', everything passed 2019-01-09 20:03:25 this was a box of worms 2019-01-09 20:03:32 i tried to update accountsservice 2019-01-09 20:03:38 meson build, which is okish 2019-01-09 20:03:46 but it fails to build due to our polkit is outdated 2019-01-09 20:03:52 so i looked at update polkit 2019-01-09 20:04:00 but recent polkit depends on mozjs 2019-01-09 20:04:09 mozjs52 apparently 2019-01-09 20:04:26 or at least, that is what void linux uses 2019-01-09 20:04:55 we do have mozjs60 in testing but it fails on arm and s390x 2019-01-09 20:05:09 could lightdm work without accountsservice? 2019-01-09 20:05:13 can someone help me with the gdal package? andypost merged my PR aports#5958 but the new version 2.4.0 is not available in edge for armhf, armv7, and s390x. 2019-01-09 20:05:38 it would just been so nice if it would be possible to disable js support in polkit 2019-01-09 20:06:16 we do have mozjs52 on pmOS iirc, not sure if that is useful to you 2019-01-09 20:06:16 hjaekel: did it build 2019-01-09 20:06:22 https://gitlab.com/postmarketOS/pmaports/blob/feature/phosh/main/mozjs/APKBUILD 2019-01-09 20:06:45 don't take `$arch=all` for granted though 2019-01-09 20:06:51 well 2019-01-09 20:06:58 will see if that could be done 2019-01-09 20:07:09 i was supposed to make the rc1 today 2019-01-09 20:07:11 ncopa, I see successful buildlogs for armhf and x390x, but no logs for armv7 2019-01-09 20:07:35 but it seems this lightdm and armv7 testing repo has delayed me :-/ 2019-01-09 20:07:56 oh I'm sorry :( 2019-01-09 20:07:59 hjaekel: testing repo is broken, lots of stuff does not built 2019-01-09 20:08:07 PureTryOut[m]: not your fault 2019-01-09 20:08:11 just remove accountsservice 2019-01-09 20:08:38 i'd like to fix it, but not now 2019-01-09 20:09:03 accountsservice needs to be updated, polkit needs to be updated and lightdm needs to be updated 2019-01-09 20:09:17 polkit update requires mozjs of some sort 2019-01-09 20:09:33 not sure if it requires mozjs52 or if mozjs60 will work 2019-01-09 20:09:35 huh, a lot of work 2019-01-09 20:09:59 if it works with mozjs60, then mozjs needs to be fixed on the remaining arches 2019-01-09 20:10:09 i guess armv7 and armhf woudl be enoug 2019-01-09 20:10:27 i dont think anyone using s390x cares about lightm 2019-01-09 20:10:52 yeah, its lots of work to maintain those things 2019-01-09 20:10:55 polkit doesn't have mozjs in depends 2019-01-09 20:11:24 heh, I'm using slim and xdm ;) 2019-01-09 20:11:44 Polkit update required mozjs52 for us 2019-01-09 20:11:51 Alpine moto: small, simple, secure 2019-01-09 20:12:45 I used to use slim but it would freeze every once in a while 2019-01-09 20:13:05 PureTryOut[m]: that must be dependecies of some package on which lightdm depends 2019-01-09 20:13:43 TBB: not in my case on different boxes, works like a charm 2019-01-09 20:14:15 yeah lightdm depends on accountsservice, which depends on polkit. but we needed to update polkit for something else, and mozjs was a new dep iirc 2019-01-09 20:14:34 polkit-105 does not need mozjs 2019-01-09 20:14:44 but anything newer than that requires mozjs 2019-01-09 20:14:50 which is why i havent updated it 2019-01-09 20:14:52 yes 2019-01-09 20:15:37 i tried to lobby polkit author to use lua instead 2019-01-09 20:16:02 https://bugs.freedesktop.org/show_bug.cgi?id=60122 2019-01-09 20:16:11 mps: I had a couple of x86 laptops, it's not a very exotic platform 2019-01-09 20:18:44 TBB: last time about year ago it worked on my old x86 too 2019-01-09 20:22:13 would be nice with help with: 1. update polkit to latest (incl add mozjs52 or fix mozjs60), 2. figure out what it would be required to move polkit to community. apparently lots of packages depends on it and all those needs to move to community too 2019-01-09 20:22:24 3. update accountsservice 2019-01-09 20:22:36 4. update lightdm 2019-01-09 20:23:08 5. move lightdm and accountsservice to community and investigate if anything else needs to move in addition 2019-01-09 20:23:50 if someone wants to work on that, then i have some WIP of accountsservice update 2019-01-09 20:23:55 I'll look at polkit 2019-01-09 20:24:53 btw, we are not in hurry for ncurses now? it is now ok on edge 2019-01-09 20:25:22 i think we are not in hurry with ncurses 2019-01-09 20:25:31 ok 2019-01-09 20:25:35 i think we just leave it as is til ncurses-6.2 comes out 2019-01-09 20:26:02 accountsservice WIP: http://tpaste.us/P0EQ 2019-01-09 20:27:28 hope that we will not have CVE for ncurses in meantime ;) 2019-01-09 20:27:47 Well, if mozjs60 won't do, feel free to take mozjs52 from postmarketOS :) 2019-01-09 20:30:21 hjaekel: i have configured the build-edge-armv7 servier to continue on errors so hopefully your gdal package will be available later today or early tomorrow morning 2019-01-09 20:34:36 does ninja have verbose option? accountsservice failed with patch you just posted 2019-01-09 20:35:36 actually, it is meson 2019-01-09 20:36:07 no, sorry ninja at the end 2019-01-09 20:37:43 ninja -v, found it 2019-01-09 20:48:54 i wonder if we should make a release test matrix 2019-01-09 20:48:58 in wiki 2019-01-09 20:49:26 for example: alpine-standard: boot from bios, boots from grub 2019-01-09 20:49:34 i mean boots from efi 2019-01-09 20:50:02 install to tmpfs (diskless) install works 2019-01-09 20:50:40 alpine-xen: boots, can create domU 2019-01-09 20:50:47 can create hvm guest 2019-01-09 20:50:50 etc 2019-01-09 20:51:15 boots and runs on qemu, virtualbox, vmware, hyper-v 2019-01-09 20:51:25 and real hardware 2019-01-09 20:51:45 boots and installs on rpi, rpi2, and as aarch64 2019-01-09 20:52:09 and test all the above on all relevant arches 2019-01-09 20:53:09 and then people can help run tests of the release candidates 2019-01-09 20:53:39 and can fill in which release that was tested (eg 3.9.0_rc1) 2019-01-09 20:54:09 and add link to bugtracker for issues found 2019-01-09 20:55:49 we could also add a column with file systems tested, eg install on ext4, install on xfs, zfs 2019-01-09 20:56:10 and a column with things like lvm and mdadm 2019-01-09 21:10:05 <_ikke_> ncopa: something like this? https://imgur.com/a/e56haN0 2019-01-09 21:11:29 yes 2019-01-09 21:12:01 not sure which is the best way to organize it, as it it is multidimentional 2019-01-09 21:12:09 <_ikke_> yes, indeed 2019-01-09 21:12:55 if a user test sys install with efi on xfs root on lvm on mdadm raid 2019-01-09 21:13:02 how does he document that? :) 2019-01-09 21:13:14 then does the same with ext4 2019-01-09 21:13:26 then without mdadm, only lvm 2019-01-09 21:13:29 thanks ncopa 2019-01-09 21:13:32 then with bios 2019-01-09 21:13:53 then with the netboot 2019-01-09 21:14:18 <_ikke_> that's very difficult to show on a 2d surface 2019-01-09 21:14:29 yup 2019-01-09 21:15:26 that is why i ask, because I am sure someone here can come up with a much better model than I can :) 2019-01-09 21:31:32 no space for LVM on LUKS with GRUB and single partition!? :D 2019-01-09 21:34:01 unmy: right, so the idea is that if user wants to test that, he can and add that to the matrix 2019-01-09 21:34:51 or she 2019-01-09 21:47:54 ncopa: just built accountsservice on armv7 with APKBUILD from aports tree as is 2019-01-09 21:48:12 don't see any problem with it 2019-01-09 21:58:56 build-edge-armv7/testing/xfce4-sensors-plugin fixed with 'pkgver=1.3.90' in APKBUILD 2019-01-09 22:29:12 ncopa: I managed to start lightdm on armv7, lightdm-gtk-greeter needs some tweaks in build() 2019-01-10 07:16:07 Hello there. How is lbu using lbu.list ? I couldn't find any location in the source code where the file is used. Actually, the file list used for apkovl creation is taken from alpine audit. And I couldn't find where lbu.list is used in apk either (apk seems to be only aware of apk). 2019-01-10 07:55:24 Processus42: where did you find lbu.list? 2019-01-10 08:06:12 In lbu sources, there is a default path for this file. It's also being mentionned in the wiki page. 2019-01-10 08:12:55 it is /etc/apk/protected_paths.d/lbu.list i suppose 2019-01-10 08:13:07 this is the exclude/include list 2019-01-10 08:13:39 so you can include things outside /etc in your apkovl 2019-01-10 08:13:54 or exclude things 2019-01-10 08:14:24 i think it is apk audit that uses anything in /etc/apk/protected_paths.d/* 2019-01-10 08:14:43 apk audit is used to generate the complete file list for lbu 2019-01-10 09:02:59 Yep, that what I discovered so far. The thing is that I couldn't find anything related to lbu.list (or even protected_paths) in apk sources. Maybe I'm not looking in the right place ? 2019-01-10 09:03:46 *that's *at the right place 2019-01-10 09:05:58 apk-tools sources: https://tpaste.us/Xny8 2019-01-10 09:22:11 Oh okay. I missed this, because I followed the source-code assuming apk had some specific arguments. Now I understand (It's in apk_db_dir_get). 2019-01-10 09:22:22 Thanks ncopa :) 2019-01-10 09:23:39 yw 2019-01-10 10:21:30 nmeum, you mention ocrmypdf would be broken? 2019-01-10 10:22:00 there are lots of broken packages in testing, discovered by armv7 rebuild 2019-01-10 10:24:47 we need some staging logic 2019-01-10 10:28:49 problem is that packages probably built at some time, but they no longer do 2019-01-10 10:29:01 or they never worked for armv7 2019-01-10 10:34:58 the question is, why do packages need to live longer than x period in testing. 2019-01-10 10:35:19 there is no logic in testing repo 2019-01-10 10:35:32 just dump something in it and forget about it. 2019-01-10 10:35:44 yeah 2019-01-10 10:35:50 we need have some maintenance there 2019-01-10 10:36:54 or maybe make it live outside of aports? with some logic attached. not sure how to manage that. 2019-01-10 10:38:01 we always bump into the same issues at the some similar point in time. 2019-01-10 10:38:32 to me it looks like dependency problem, build tried and depends not satisfied because not all makedepends package are built 2019-01-10 10:38:57 mps: some of them are 2019-01-10 10:39:15 i made it continue on error 2019-01-10 10:39:20 ofc, there are packages with bugs 2019-01-10 10:39:35 i think i can make it halt on error again 2019-01-10 10:39:42 so we can clean those up one by one 2019-01-10 10:40:42 i am sort of ready for 3.9.0_rc1 now 2019-01-10 10:40:58 maybe someone with good knowledge about graph theory could make script which create build queue in which build packages will be put 2019-01-10 10:41:48 lua-aports has some simple logic for that 2019-01-10 10:43:34 the failing packages in build order: https://tpaste.us/LzRa 2019-01-10 10:47:01 will look at some of them later, now preparing lightdm-gtk-greater, it puts config in /usr/etc instead of /etc 2019-01-10 10:49:16 do I need bump pkgrel for patch, it is a bug and should trigger version change, I think 2019-01-10 10:51:04 yes 2019-01-10 10:51:24 if you dont bump pkgrel will the builder not rebuild it 2019-01-10 10:51:31 so it will be unmodifed 2019-01-10 10:52:45 we have an interesting problem with the current kernel config 2019-01-10 10:53:12 ACTION rises from crypt 2019-01-10 10:53:15 im listening? 2019-01-10 10:53:38 there is a CONFIG_RANDOM_TRUST_CPU 2019-01-10 10:53:59 which is do we trust the CPU random generator for entropy? 2019-01-10 10:54:06 i have configured it as "no" by default 2019-01-10 10:54:21 there is a boot option you can change it 2019-01-10 10:54:36 but the problem is that in qemu boot hangs when starting sshd 2019-01-10 10:54:44 i assume it is due to lack of entropy 2019-01-10 10:55:18 if i press a few keys in the console, it continue to boot 2019-01-10 10:55:31 so i wonder if we should set CONFIG_RANDOM_TRUST_CPU=yes 2019-01-10 10:55:41 hm, like diskless boot? 2019-01-10 10:55:49 no, its after disk install 2019-01-10 10:55:50 or sysinstall? 2019-01-10 10:55:55 sysinstall 2019-01-10 10:56:12 i think im gonna tag 3.9.0_rc1 and people will notice it 2019-01-10 10:56:39 i also found out that interesting things happen if you try sysintall with UEFI on a 1G disk 2019-01-10 10:56:47 2G disk works 2019-01-10 10:57:10 hm, it could also be set via random.trust_cpu at boot-time 2019-01-10 10:57:34 yes 2019-01-10 10:58:09 question is, do we let kernel default be "dont trust" and then during install we set the boot option? 2019-01-10 10:58:20 or we document it and let user set boot option? 2019-01-10 10:58:41 or we auto add it if a virtual machine is detected? 2019-01-10 10:59:59 or we simply change the default config in kernel to "no" and let people who dont trust the CPU change the boot option? 2019-01-10 11:00:16 the general philosophy in alpine is to have secure default 2019-01-10 11:02:01 ncopa: my vote goes to disable 2019-01-10 11:02:12 as in dont trust? 2019-01-10 11:02:22 like it is now 2019-01-10 11:02:25 related: https://lwn.net/Articles/760121/ 2019-01-10 11:02:43 right, user/admin could decide then what he/she wants 2019-01-10 11:04:12 what does sshd need the entropy for? 2019-01-10 11:04:29 generate keys? 2019-01-10 11:04:48 and probably some short term keys as well 2019-01-10 11:04:52 yes, i think its the first boot only 2019-01-10 11:05:12 first boot for generate host keys 2019-01-10 11:05:35 ok 2019-01-10 11:05:54 i think im just gonna tag 3.9.0_rc1 and see what else shows up 2019-01-10 11:06:05 entropy file for qemu and other VMs could be saved to be used at next boot 2019-01-10 11:06:37 but we dont have entropy file from install 2019-01-10 11:06:42 ncopa: please look at this small patch for lightdm-gtk-greeter https://patchwork.alpinelinux.org/patch/4398/ 2019-01-10 11:06:45 mps: generating ssh keys is an first-boot issue 2019-01-10 11:07:09 mps: looks correct 2019-01-10 11:07:21 AinNero: regenerate entropy file every few hours, maybe 2019-01-10 11:07:37 mps: or after each boot 2019-01-10 11:07:49 and place it in the apkovl per default? 2019-01-10 11:08:07 ncopa: fixes /usr/etc, nothing more 2019-01-10 11:08:20 i suppose setup-disk need copy the current entropy file to the install 2019-01-10 11:08:33 or generate and include it 2019-01-10 11:10:04 AinNero: didn't though deeply about such serious issue, but for VM's entropy seed should/could be regenerated and saved for next boot, to not pause boot to long 2019-01-10 11:10:25 s/though/thought/ 2019-01-10 11:10:25 mps meant to say: AinNero: didn't thought deeply about such serious issue, but for VM's entropy seed should/could be regenerated and saved for next boot, to not pause boot to long 2019-01-10 11:10:54 the issue is the first boot after install, it needs to be part of setup-disk, like ncopa said 2019-01-10 11:11:22 how does haveged fit in this? 2019-01-10 11:12:02 of course, it could be generated/saved whenever is appropriate 2019-01-10 11:13:29 sometimes good entropy is needed before haveged starts 2019-01-10 11:19:16 am I correct that even when the kernel "trusts the cpu" in this, it still also gathers entropy from various timers and such? 2019-01-10 11:22:59 im checking the kernel code rn 2019-01-10 11:23:30 it always reads the hwrand 2019-01-10 11:23:48 the TRUST_CPU flag only determines if thats enough alone 2019-01-10 11:24:07 as in, if its a valid input pool 2019-01-10 11:27:34 still, this is an easy way for the NSA to cause machines have ssh keys from a quite small pool, so i dont think we could enable it per default 2019-01-10 11:34:51 anyway, haveged could be really useful for small machines like RPi's and similar 2019-01-10 11:42:52 AinNero: it is if the cpu is used as the only source of entropy... which is a bad idea for the exact reason you mention 2019-01-10 11:43:10 as initial entropy 2019-01-10 11:43:31 there might be more entropy when ssh gets it, but that wont me much in bad cases 2019-01-10 12:17:15 3.9.0 release candidate 1 is out 2019-01-10 12:45:17 ncopa: 'fix' for knot-resolver https://patchwork.alpinelinux.org/patch/4399/ actually 'upgrade and fix build' 2019-01-10 12:54:37 ncopa: sorry fot annoying you again, fix for testing/xfce4-sensors-plugin is here: https://patchwork.alpinelinux.org/patch/4400/ 2019-01-10 12:54:48 s/fot/for/ 2019-01-10 12:54:48 mps meant to say: ncopa: sorry for annoying you again, fix for testing/xfce4-sensors-plugin is here: https://patchwork.alpinelinux.org/patch/4400/ 2019-01-10 13:24:28 mps: thanks! 2019-01-10 13:25:35 np, will look at some other packages on your list, but first a cup of coffee ;) 2019-01-10 13:43:48 ncopa: fix for cups-pdf: https://patchwork.alpinelinux.org/patch/4401/ 2019-01-10 13:44:36 it need pkgrel bump since the url/homepage is included in the .apk 2019-01-10 13:45:05 $ apk info --webpage cups-pdf 2019-01-10 13:45:06 cups-pdf-3.0.1-r0 webpage: 2019-01-10 13:45:06 http://cups-pdf.de 2019-01-10 13:45:26 but i can fix that. 2019-01-10 13:46:30 mps: thanks! 2019-01-10 13:47:05 ah, sorry. didn't know, have a lot to learn. Anyway, I send patches but at the end committer should look at it before applying 2019-01-10 13:48:23 btw, don't forget lightdm-gtk-greeter https://patchwork.alpinelinux.org/patch/4398/ , it is ugly to have conf /usr/etc , IMHO 2019-01-10 14:05:55 for corkscrew I added http://deb.debian.org/debian/pool in source, but what to do with url, home page is for sale. Leave it as is or redirect to nonexistentsite.com 2019-01-10 14:10:42 or, it is better to use http://example.net/ 2019-01-10 14:14:55 if upstream is gone, maybe move it to unmaintained? 2019-01-10 14:17:42 not sure, it is still in void linux, debian, arch etc... it is still used widely. you decide how you feel it 2019-01-10 14:19:17 maybe to leave it for 3.9 and after some time see what should be best option, if there are best option for unmaintained/orphaned software 2019-01-10 14:20:53 anyway, posted patch here: https://patchwork.alpinelinux.org/patch/4402/ do what you think is 'good enough' for now 2019-01-10 14:33:14 i think example.net is not useful at all 2019-01-10 14:34:04 um 2019-01-10 14:34:04 could it be empty? 2019-01-10 14:34:11 i dont think its allowed 2019-01-10 14:34:26 the idea is to help user find upstream 2019-01-10 14:34:31 example.net is for testing 2019-01-10 14:34:34 we use debian as upstream now? 2019-01-10 14:34:49 where to look for bug reports, updates etc 2019-01-10 14:35:33 not sure, user look at problem on package and see url, and then ask help from Debian. not good 2019-01-10 14:36:03 and problem is on Alpine :/ 2019-01-10 14:37:13 there is nonexistentsite.com but don't know for what is used, although example.net is right in our case, I admit 2019-01-10 14:39:03 s/example.net is right/example.net is not right/ 2019-01-10 14:39:03 mps meant to say: there is nonexistentsite.com but don't know for what is used, although example.net is not right in our case, I admit 2019-01-10 15:01:43 then i'd rather keep the broken one 2019-01-10 15:02:04 i think we should fix our grub config: https://bugs.alpinelinux.org/issues/8601 2019-01-10 15:02:48 ok, after our discussion I think the same 2019-01-10 15:03:35 should I post update to patch or you will revert that field, url I mean 2019-01-10 15:08:23 i think i can just fix it 2019-01-10 15:08:25 probably quicker 2019-01-10 15:11:36 could this be new upstream? https://github.com/bryanpkc/corkscrew 2019-01-10 15:11:42 was the first thing google gave me 2019-01-10 15:13:08 eh, i searched even with github in search term but didn't find it, duckduckgo :| 2019-01-10 15:13:39 i googled "corkscrew tunnel" 2019-01-10 15:13:40 i'd investigate whether openbsd-nc is able to fully replace corkscrew 2019-01-10 15:14:05 mps: can you please preare a new patch using the github? 2019-01-10 15:14:10 looks like that is new upstream 2019-01-10 15:14:17 mps: just to check, I just tried, 1st result on ddg 2019-01-10 15:14:21 of course, will do 2019-01-10 15:14:28 (query: "site:github.com corkscrew" 2019-01-10 15:14:43 mps: then do: git format-patch -1 --stdout | tpaste 2019-01-10 15:14:46 and paste url here 2019-01-10 15:15:07 SpaceToast: i blindly tiped: corkscrew home page 2019-01-10 15:15:27 I don't think a homepage for a project will have the words "home" nor "page" on it :) 2019-01-10 15:15:27 :) 2019-01-10 15:15:39 (which is how search engines work) 2019-01-10 15:15:41 meh, right 2019-01-10 15:17:13 re testing the release candidates 2019-01-10 15:17:35 it would be nice to keep track of what needs to be tested and what has been tested 2019-01-10 15:18:14 i'd think that is an easy, but very valuable way to contribute 2019-01-10 15:18:51 _ikke_ suggested something like this: https://imgur.com/a/e56haN0 2019-01-10 15:19:14 <_ikke_> just a qnd mockup 2019-01-10 15:19:20 but it would be nice to have it in some sort of wiki 2019-01-10 15:20:02 <_ikke_> This doesn't cover combinations of technologies 2019-01-10 15:20:03 maybe ethercalc? 2019-01-10 15:20:07 sounds more like a tracker bug + milestone deal to me 2019-01-10 15:20:11 on the bug tracker 2019-01-10 15:20:49 i was thinking a wiki checklist 2019-01-10 15:20:52 or similar 2019-01-10 15:21:10 you boot your arch, then just mark it as tested in some wiki 2019-01-10 15:21:26 bugtracker can not be edited or resolved by anyone 2019-01-10 15:22:34 I'd imagine it depends on the bugtracker/setup, quite possible redmine can't do anything of the sort 2019-01-10 15:23:07 i was thinking it would be nice to generate something from script 2019-01-10 15:23:14 based on the latest-releases.yaml 2019-01-10 15:23:36 http://dl-master.alpinelinux.org/alpine/v3.9/releases/x86_64/latest-releases.yaml 2019-01-10 15:23:41 for each arch 2019-01-10 15:24:15 could even be a github powered markdown 2019-01-10 15:24:21 boot uefi: [ ] 2019-01-10 15:24:27 that is nice idea, and we can always look at yaml file 2019-01-10 15:24:52 and i think we should start small and simple 2019-01-10 15:25:06 but do it in a way that can grow all kinds of combinations 2019-01-10 15:25:26 my other concern is I'm not sure that's the right approach to testing; "boot X" primarily depends on the kernel, which is very unlikely to suddenly break 2019-01-10 15:25:51 sure, lots of stuff happen in between, but "openrc hangs forever" is a lot more useful than "x86 can't boot" 2019-01-10 15:26:23 the thing is that i want avoid ship things that is clearly broken 2019-01-10 15:26:34 I get that :) 2019-01-10 15:26:39 lets say 32bit x86 does not boot at all for some stupid reason 2019-01-10 15:26:49 but if we're doing something along these lines (highly simple), it might as well be CI 2019-01-10 15:27:04 so during release canidates, we can have a checklist what to test 2019-01-10 15:27:20 and gives us an overview that we know is tested and what is not 2019-01-10 15:27:21 yes 2019-01-10 15:27:33 e.g throw an apkovl in that should get detected by every boot mechanism that sends a "configuration X got through" during rc 2019-01-10 15:27:36 once we have a specification of what we want to test, it can be automated 2019-01-10 15:27:46 right 2019-01-10 15:27:59 we can test on different vm platforms automatically 2019-01-10 15:28:08 but we also need to test on different hardware 2019-01-10 15:28:34 so poeple who has that hardware can test it and report back that it works on hardware this and that 2019-01-10 15:28:54 and I think *that* part belongs on the wiki, but in a different format 2019-01-10 15:29:00 right 2019-01-10 15:29:09 I think the wiki can have a hardware-dedicated section that outlines each system's particularities 2019-01-10 15:29:25 stuff like https://wiki.archlinux.org/index.php/Lenovo_ThinkPad_X1_Carbon_(Gen_6) (that I had to look at just yesterday :) ) 2019-01-10 15:29:33 but imo that's separate from release testing 2019-01-10 15:30:10 but it would also be nice to have it reported that 3.9.0_rc1 boots and installs fine on thinkpad x1 gen6 2019-01-10 15:30:40 im thinkin "i tested release X. it boots and sysintall works on this hardware" 2019-01-10 15:30:42 sure, I just think it should go on the x1c6 page, rather than the 3.9.0_rc1 info page 2019-01-10 15:30:48 ok 2019-01-10 15:31:03 also, I have good news, 3.8.0 boots and installs fine on x1c6 ;) 2019-01-10 15:31:09 :D 2019-01-10 15:31:09 well, 3.8.2 but whatever 2019-01-10 15:31:23 but does 3.9.0_rc1? 2019-01-10 15:31:25 but it ended up being too painful for desktop use for me (so it's running arch now) 2019-01-10 15:31:49 I did that roughly 12h before 3.9.0_rc1 came out, so no idea 2019-01-10 15:31:52 but I would imagine so 2019-01-10 15:32:03 (since the first thing I did was apk upgrade to edge) 2019-01-10 15:32:11 then i guess it works 2019-01-10 15:32:51 the specific problem i have at hand is that i am about to send an email saying 3.9.0_rc1 is out and please help to test 2019-01-10 15:33:03 aha 2019-01-10 15:33:09 i would like to also say something about how to report back testing results 2019-01-10 15:33:12 and you don't want a flood of "rpi2 works" 2019-01-10 15:33:21 and users have no clue of what to test 2019-01-10 15:33:29 or what other people have tested 2019-01-10 15:33:43 exactly 2019-01-10 15:33:54 perhaps until we have infra for it a wiki page is fine 2019-01-10 15:34:09 something along the lines of "3.9.0 testing effort" 2019-01-10 15:34:18 i was thinking somethign simple like that yes 2019-01-10 15:34:23 they can add what they tested in themselves (unless already added) 2019-01-10 15:34:43 i think we should provide some sort of simple template 2019-01-10 15:34:54 so they can just fill in 2019-01-10 15:34:59 aha 2019-01-10 15:35:58 h1 architectures -> h2 "unified system" (table per); h1 software -> h2 type of software (e.g filesystem / uefi / etc) -> h3 specific soft in question -> comments 2019-01-10 15:36:07 is what seems reasonable to me 2019-01-10 15:36:20 I need to go for a bit though, good luck! 2019-01-10 15:43:25 does this work? https://alpine.global.ssl.fastly.net/alpine/v3.9/releases/ 2019-01-10 16:18:33 now we need look over https://bugs.alpinelinux.org/projects/alpine/issues?fixed_version_id=127&set_filter=1&status_id=o and move things we wont fix to 3.10 2019-01-10 17:44:11 ncopa: corkscrew patch: https://tpaste.us/dk1y 2019-01-10 17:51:24 and here is 'full' patch: https://tpaste.us/4ya4 2019-01-10 17:55:15 wow 2019-01-10 17:55:27 there are some uttee garbage bugs on there 2019-01-10 17:55:45 #8600 is invalid for a start 2019-01-10 17:56:38 close reason: rtfm 2019-01-10 17:56:40 :D 2019-01-10 17:57:57 although arguably both versions shoukd be in the repo as 1.6 us still supported 2019-01-10 17:58:56 ive recently come to the conclusion that v2 is a disaster 2019-01-10 18:10:19 clandmeter, are you ok to revert it https://github.com/alpinelinux/aports/pull/6024 2019-01-10 18:10:51 it buiolds fine locally and travis 2019-01-10 19:02:44 andypost, sure 2019-01-10 19:41:12 ncopa: alpine-xen-3.9.0_rc1-x86_64.iso tested on a small Intel XEON dom0 with 16 guests. Works fine so far :-) 2019-01-11 08:44:46 alioth.debian.org is down for some time, package archives is moved to alioth-archive.debian.org. some packages needs url change, and sane package need new source (I'm preparing one line patch) 2019-01-11 08:57:51 one line patch for sane is here: https://patchwork.alpinelinux.org/patch/4403/ 2019-01-11 08:58:30 is it worth a commit? 2019-01-11 08:59:09 <_ikke_> sure, why not? 2019-01-11 09:00:44 _ikke_: I know, but that was rhethorical question :) 2019-01-11 09:29:37 is there an issue with vim and reStructuredText? 2019-01-11 09:34:09 vim with filetype plugin on on rst will render incorrectly. 2019-01-11 09:44:19 do we want to ship busybox 1.30.0 or 1.29.3 with the v3.9 release? 2019-01-11 09:44:41 because if want to ship 1.30.0 I could start working on an upgrade soonish 2019-01-11 09:45:02 sounds dangerous 2019-01-11 09:45:20 i remember we had some issues before 2019-01-11 09:45:21 only bugfixes after rc 2019-01-11 09:45:30 thats what rc's are for 2019-01-11 09:45:51 oh, didn't notice that ncopa released an rc yesterday 2019-01-11 09:45:58 so yeah, in that case I would indeed postpone the update 2019-01-11 12:50:09 clandmeter: ncopa: have you ever tried to create an Alpine image for Openstack? Not sure if need something "special" for that - just started to look, but if you have some experience on that 2019-01-11 14:00:04 rdutra: i have no experience with openstack 2019-01-11 14:06:04 ncopa: Found some guides about generating a openstack image: https://docs.openstack.org/image-guide/fedora-image.html 2019-01-11 14:06:04 but they use virt-install command and it requires --os-variant flag (e.g --os-variant=fedora23), and there is no os-variant supported for Alpine 2019-01-11 14:06:04 I just installed alpine in a qcow2 disk using qemu and uploading to openstack to see what happens 2019-01-11 15:33:56 oh, it uses virt-install 2019-01-11 15:35:07 i think we should make alpine installable via virt-install 2019-01-11 15:39:28 there was another unattended install system 2019-01-11 15:39:30 from ubuntu iirc 2019-01-11 15:39:47 cloud init 2019-01-11 15:46:17 ncopa: cloud-init is part of Alpine 2019-01-11 15:47:06 ncopa: anyway, the qcow2 that I generated did not work in Openstack and no useful error message :( 2019-01-11 15:48:05 i was thinking of make an installer which can take input from cloud-init config 2019-01-11 15:48:07 or similar 2019-01-11 15:50:12 ncopa: so it would work with virt-install? 2019-01-11 15:50:42 I dont have much of knowledge in installer parts 2019-01-11 15:57:15 neither have i :) 2019-01-11 16:03:36 ncopa: btw, seems that gimp requires "libexecinfo-dev" to build on ppc64le 2019-01-11 16:03:40 this new version 2019-01-11 16:33:09 hum. ok 2019-01-11 17:02:10 ncopa, did you look at my analysis of the gdal/postgis problem that I analyzed in https://github.com/alpinelinux/aports/pull/5958 ? There are some PR that want to add sqlite-libs as a dependency to postgis, but I think this is not the root of the problem. 2019-01-11 17:19:58 hjaekel, correct 2019-01-11 17:20:23 Did postgis build now 2019-01-11 17:20:54 no, postgis did not build 2019-01-11 17:21:21 I think lxd has to be fixed first 2019-01-11 17:21:54 lxd should be working right now, afaik 2019-01-11 17:21:59 at least on edge 2019-01-11 17:22:54 lxd is working, but it breaks other packages 2019-01-11 17:23:46 Why would that be? 2019-01-11 17:24:34 lxd declares that it provides libsqlite3.so.0, so packages that require libsqlite3.so.0 pull lxd instead of sqlite-libs 2019-01-11 17:24:47 lxd does provide libsqlite3.so.0 2019-01-11 17:24:57 and it's basically pure sqlite3, but with the replication patches 2019-01-11 17:25:04 they shouldn't really break anything though 2019-01-11 17:26:02 maybe the libsqlite3.so.0 is binary incompatible to the one provided by sqlite-libs 2019-01-11 17:26:29 aha 2019-01-11 17:26:31 that's possible 2019-01-11 17:26:46 Lxd should not provide sqlite 2019-01-11 17:27:00 That's a bug 2019-01-11 17:27:06 clandmeter: lxd requires patched sqlite with replication patches, and fcolista didn't want to make a separate package 2019-01-11 17:27:28 I'm thinking we could just apply the patches to sqlite-normal, since I suspect it'll get merged eventually 2019-01-11 17:27:50 Im not sure that the right direction 2019-01-11 17:28:20 hmm, postgis built locally here 2019-01-11 17:28:34 clandmeter: what would you rather do? 2019-01-11 17:29:05 mps, thats the other problem: Travis and my local build pull sqlite-libs, but the alpine build system chooses lxd 2019-01-11 17:29:09 Yes it builds 2019-01-11 17:29:16 But not in builder 2019-01-11 17:29:35 why are thy pulling differnt libraries? 2019-01-11 17:29:40 ncopa should look at it 2019-01-11 17:29:45 true, just tried to see if could be built 2019-01-11 17:30:24 SpaceToast, not sure 2019-01-11 17:30:51 Are you sure they will get merged? 2019-01-11 17:31:06 no, I just find it likely 2019-01-11 17:31:44 That's the problem 2019-01-11 17:32:07 We need to keep supporting it even if it's rejected 2019-01-11 17:32:36 well the patches are developed by the lxd people (meaning canonical) 2019-01-11 17:32:40 so it's not like that part's going away 2019-01-11 17:33:34 I have not looked into it yet 2019-01-11 17:33:42 is it possible to remove the provides line from the lxd package? lxd can have its private version of libsqlite3, but it should not be a provider for that library 2019-01-11 17:33:47 So I'm a bad advisor 2019-01-11 17:33:59 hjaekel: the issue is that patched sqlite is still sqlite 2019-01-11 17:34:00 so they conflict 2019-01-11 17:34:10 if you want to have lxd installed, you cannot have sqlite installed 2019-01-11 17:34:25 But lxd should never provide sqlite 2019-01-11 17:34:26 however, my edge server has lxd installed (and thus no sqlite) and things like python etc that dep on sqlite seem to work fine 2019-01-11 17:34:28 you could rename it to libsqllite3-replication 2019-01-11 17:34:32 Not in our repo 2019-01-11 17:34:38 hjaekel: the files will still conflict 2019-01-11 17:34:56 either way, this is for fcolista to figure out, as the maintainer 2019-01-11 17:35:15 as I think I mentioned, I'd just apply the patches to sqlite normal 2019-01-11 17:36:56 I'll check it later. I'm drinking a 🍺 now. 2019-01-11 17:37:23 :) I'm considering some rum cream 2019-01-11 17:37:29 quite a bit later though 2019-01-11 17:38:30 as a completely unrelated side note, I so wish I could tell my terminal to not show those :D 2019-01-11 17:39:28 TBB: just remove all mono fonts that have glyphs and you should be good 2019-01-11 17:39:39 ooo! 2019-01-11 18:01:39 You don't have control over your own terminal? Poor you :p 2019-01-11 18:03:58 <[[sroracle]]> there is some APKBUILD property you can set so that it’ll skip that soname 2019-01-11 18:04:04 <[[sroracle]]> the name escapes me right now 2019-01-11 18:04:49 <[[sroracle]]> Could also use a soname prefix 2019-01-11 18:06:21 Yes that's what i was thinking 2019-01-11 18:06:36 Sonane change 2019-01-11 22:58:03 hjaekel, i think i have a fix 2019-01-11 23:09:33 [[sroracle]], tracedeps 2019-01-11 23:14:45 <[[sroracle]]> clandmeter: actually i was thinking of somask 2019-01-11 23:15:25 <[[sroracle]]> that'll prevent it from being put in .provides-so 2019-01-11 23:15:48 i think thats also what !tracedeps does 2019-01-11 23:16:07 <[[sroracle]]> !tracedeps will skip all automatic dependency checking 2019-01-11 23:16:22 <[[sroracle]]> which seems excessive 2019-01-11 23:16:25 thats not what i noticed 2019-01-11 23:16:42 i splitted the bundled libs 2019-01-11 23:16:58 which are sqlite and dsql or whatever its called 2019-01-11 23:18:00 <[[sroracle]]> oh if it's in a subpackage then yeah that's probably fine 2019-01-11 23:18:48 i didnt even know about somask 2019-01-11 23:19:02 i just scanned abuild for scanelf 2019-01-11 23:19:23 <[[sroracle]]> it's only used in one line of all of abuild, but it should be perfect for this usecase 2019-01-11 23:21:21 hjaekel thanx, nice find! 2019-01-11 23:22:13 [[sroracle]], im glad SpaceToast is working on docs. 2019-01-11 23:22:41 <[[sroracle]]> reminds me, i should probably join that channel 2019-01-11 23:51:11 somask does support lists 2019-01-12 00:03:16 *not 2019-01-12 00:42:25 <[[sroracle]]> it uses list_has though? 2019-01-12 00:52:07 yes, i dont know whats wrong. looks like it still adds provides for whatever reason. 2019-01-12 12:00:59 clandmeter: re ocrmypdf, yeah it was broken because it depend on a old version of a python library which was updated 2019-01-12 12:01:08 *depended 2019-01-12 12:16:28 clandmeter, hjaekel: i think in stead of options="!tracedeps" we should so sonameprefix="$pkgname:" which will add the $sonameprefix to the provides 2019-01-12 12:26:18 Has anyone got advice on how to get a package upgrade merged? 2019-01-12 12:27:00 I addressed the review comments on the PR but its been nearly six months ( https://github.com/alpinelinux/aports/pull/4871 ) 2019-01-12 12:29:02 kmaxwell: the devs are struggeling with keep up with the PRs 2019-01-12 12:29:22 PRs that require lot of feedback tend to be "forgotten" 2019-01-12 12:29:44 Is there anything I can do to help out or make it easier? 2019-01-12 12:29:49 so the best advice is to make a clean and nice PR. that increases the probability to get it merged alot 2019-01-12 12:31:06 I got simple version bumps merged quickly before, but this one involved removing a broken subpackage 2019-01-12 12:31:39 The last question on the PR was should it move from testing to community; when should a package move? 2019-01-12 12:31:49 so, the problem with the PR is that it has lots of history, for any dev to take a look at it, it requires to read the history (it sends the message to the dev that this will require time) 2019-01-12 12:32:12 second problem I see when i look at it is the commit messages 2019-01-12 12:32:45 they dont seem to follow the ususal way we format the commit messages 2019-01-12 12:32:57 "Incorporate review feedback" 2019-01-12 12:34:14 If you imagine that you see "Incorporate review feedback" somewhere in the middle of this page: https://git.alpinelinux.org/aports/log/ 2019-01-12 12:34:46 the commit message says absolutely nothing what the commit is about in a git log with 1000+ packages 2019-01-12 12:35:17 Sorry that is a commit to a separate repo where I was testing my changes, I can only see two commits: https://github.com/alpinelinux/aports/pull/4871/commits 2019-01-12 12:36:13 humm... 2019-01-12 12:36:16 looks like you are right 2019-01-12 12:36:27 so I got fooled by the gihub web ui 2019-01-12 12:36:45 I take the point about keeping the number of comments on the PR low, make it look easy 2019-01-12 12:37:28 Is it better to use the mailing list than the web ui? Does that make it easier for developers? 2019-01-12 12:37:40 your 2 commits looks nice and clean 2019-01-12 12:39:00 so the real issue is all the noise, which gives the devs the impression that: 1) submitter has no clue what he/she is doing 2) this will require lot of devlopers time 2019-01-12 12:39:37 in this specific case, if you would have closed the issue and created a new with those 2 only commits, you would have fooled the devs :) 2019-01-12 12:39:45 OK at least I understand the issue :-) 2019-01-12 12:39:56 but please dont do that. I'll see if i can merge it right now 2019-01-12 12:40:48 your commit messages are great! 2019-01-12 12:41:23 also, it does help to ping the devs here in IRC 2019-01-12 12:41:30 thank you! 2019-01-12 12:41:47 I really appreciate the effort you and the other devs put in 2019-01-12 12:42:02 another thing is that we are about to make 3.9.0 release, just did release candidate 1 2019-01-12 12:42:20 i have tried to ignore everythign that happens in testing repo last month 2019-01-12 12:42:40 because i want 3.9.0 out asap 2019-01-12 12:43:07 kmaxwell: thank you for your patience with us 2019-01-12 12:45:18 I understand, I have been trying to learn enough to contribute, I'll be a little more active here & on the mailing list 2019-01-12 12:46:13 One last question - are there guidelines about when a package should move from testing to community? 2019-01-12 12:50:07 what is the process / requirement to move a package (e.g. lxd) from testing to main or community so that it becomes available for the next stable release? 2019-01-12 12:50:37 sounds like something that needs to be added to the FAQ or developer docs 2019-01-12 12:51:04 so, historically, we created the testing repo because people asked for packages 2019-01-12 12:51:06 we built them 2019-01-12 12:51:14 but did not have time to test if they actually works or not 2019-01-12 12:51:47 we also wanted to make sure that package works when built on the offical build server, and not only when its built on the developers local machine 2019-01-12 12:51:54 so we added testing repository 2019-01-12 12:52:10 make it possible for the people requesting the package to test that it actually works 2019-01-12 12:52:51 we have traditionally never had any "quarantine" time or similar. the only thing required is: 2019-01-12 12:53:01 1) confirmation that package work 2019-01-12 12:53:39 that includes, that init.d script (if provided) works, that default config is ok 2019-01-12 12:54:14 2) that packaging is done correctly, that files are installed where they are supposed to 2019-01-12 12:54:27 for example that the configs are in /etc/ and not in /usr/etc 2019-01-12 12:54:32 and similar things 2019-01-12 12:55:15 makes sense thanks for explaining :) 2019-01-12 12:55:30 3) that dependencies are done correctly. abuild can (and should) autodetect shared libs 2019-01-12 12:56:19 for example sqlite-libs provides so:libsqlite3.so.0, any package linked to sqlite should have an automatically (by abuild) added depend=so:libsqlite3.so.0 2019-01-12 12:56:35 and user should not manually add a depend="sqlite-libs" in the APKBUILD 2019-01-12 12:57:03 4) that there is a maintainer 2019-01-12 12:57:59 we need someone who claim responsibility for the maintenance of the package, so if things break in the future, we have someone we can ask help us take care of it 2019-01-12 12:58:30 if those things are ok, then there is nothing prevening to move it to community repo 2019-01-12 12:59:17 ncopa: maybe check license is not bad idea even before accepting in testing 2019-01-12 12:59:33 mps: good point 2019-01-12 13:00:20 if I see a maintainer listed, e.g. https://pkgs.alpinelinux.org/package/edge/testing/armv7/lxd does that mean 4) is taken care of? 2019-01-12 13:00:42 pgauret: correct 2019-01-12 13:01:40 I shall do more testing on lxd then, unfortunately for the moment stuck at booting the alpine kernel on my arm boards (Bug #9826) 2019-01-12 13:01:52 re lxd, i just fixed a problem with a conflict with system libsqlite in lxd 2019-01-12 13:02:34 yes I saw that, must say I'm quite impressed at the pace things get fixed :) 2019-01-12 13:02:46 it was blocking the builders 2019-01-12 13:03:02 so the world stopped up for everyone :) 2019-01-12 13:04:43 once the above mentioned things are verified, then can you create a PR which moves the package *and* all the needed dependencies. 2019-01-12 13:04:54 packages in main and community cannot depend on things in testing 2019-01-12 13:05:08 yep saw that on the wiki 2019-01-12 13:06:07 it would be nice if what i wrote above could be added to the wiki 2019-01-12 13:06:20 ;) 2019-01-12 13:08:50 on that page ? 2019-01-12 13:08:51 https://wiki.alpinelinux.org/wiki/Aports_what_is_edge#Do_we_backport_new_packages.28from_edge.29_to_previous_stable_releases_.28The_Gift.2C_Favor.29 2019-01-12 13:10:22 lol 2019-01-12 13:10:37 yes 2019-01-12 13:11:41 ok just created an account on the wiki will add 2019-01-12 13:15:18 to clarifiy, if the 4 points above are satisfied the package moves from testing to main or to community? 2019-01-12 13:18:21 not automatically 2019-01-12 13:18:26 <_ikke_> pgauret: main vs community mostly depends on how long the package is supported 2019-01-12 13:18:44 we move on request 2019-01-12 13:18:58 ncopa: managed to compile community/firefox-esr on aarch64, now will try to make apk 2019-01-12 13:19:18 mps: do you have a way to build the rust package? 2019-01-12 13:19:35 on aarch64? 2019-01-12 13:19:38 no, used one from adelie 2019-01-12 13:20:10 for now, I want to have firefox on aarch64 in 3.9 2019-01-12 13:20:34 so, if i install the rust package from adelie on the builder, can i build our rust package? 2019-01-12 13:20:52 after that will look to build rust 2019-01-12 13:21:06 ok 2019-01-12 13:21:15 didn't investigated a lot about, but could be 2019-01-12 13:21:57 on my chroebook build take about 8 hours 2019-01-12 13:23:03 abuild package stopped because of 'no space left on device' 2019-01-12 13:23:35 looks like I don't have rights to edit the wiki, here are the changes I would propose to the wiki page 2019-01-12 13:23:38 https://gist.github.com/pgauret/e489d8f82873e5b7e1856ebfb2d5da9b 2019-01-12 13:23:47 now moving everything to bigger partition on sd card, slow process :( 2019-01-12 13:23:55 @ncopa thanks again for explaining 2019-01-12 13:26:40 I added it. Thank you! 2019-01-12 14:03:07 ncopa, what was blocking the builders? 2019-01-12 14:38:02 the lxd/sqlite thingy 2019-01-12 14:38:19 which explains why it was fixed so quickly 2019-01-12 14:53:52 I didn't see any error on commit Chan 2019-01-12 15:25:51 ncopa, can you show me the build error? 2019-01-12 17:47:34 finished and installed firefox-esr-60.4.0-r1 on aarch64, it works for now :) 2019-01-12 17:48:03 will see is it stable 2019-01-12 17:48:32 on v3.9 I mean 2019-01-12 18:20:11 mps, Nice 2019-01-12 18:20:33 Sorry i didn't get back to you 2019-01-12 18:21:54 clandmeter: ncopa prepared 'machine' 2019-01-12 18:23:18 Yes i know 2019-01-12 18:23:20 I hope that tomorrow I will be 'on it' 2019-01-12 18:23:35 You don't have access yet? 2019-01-12 18:23:37 ah, ok. no problem. 2019-01-12 18:23:48 no, i didn't posted keys 2019-01-12 18:23:54 Pm me 2019-01-12 18:24:13 Your key 2019-01-12 18:24:19 'wasting' time on upgrading to v3.9 ;) 2019-01-12 18:24:28 Or here in a paste 2019-01-12 18:24:44 please, pm me 2019-01-12 18:25:42 ? 2019-01-12 18:41:38 ncopa: https://dustri.org/b/making-snuffleupagus-run-on-alpine-linux.html thank you ♥ 2019-01-12 19:07:06 _ikke_, ncopa ^^ re:https://imgur.com/a/e56haN0 2019-01-12 19:07:11 http://tpaste.us/5wXN 2019-01-12 19:07:25 make use of mqtt 2019-01-12 19:08:43 keep the msg posted size limit to say 1kb 2019-01-12 19:08:51 or less 2019-01-12 19:09:52 if using mqtt-dirpub , they can be organized as it arrives and scripts can be written to show analytics 2019-01-12 19:17:54 <_ikke_> but how would you visualize all the tested options? 2019-01-12 19:18:01 <_ikke_> vs missing ones 2019-01-12 19:19:18 <_ikke_> there are potentially a huge amount of different combinations 2019-01-12 19:20:04 _ikke_: give a single example 2019-01-12 19:21:07 if it can be represented in spreadsheet or 'structured table on wiki page', quite likely in hierarchy 2019-01-12 19:21:29 <_ikke_> the spreadsheet is limited 2019-01-12 19:21:39 endpoints(msg) can be fullfledged data 2019-01-12 19:21:59 <_ikke_> modelling the data behind it is not that hard, the hard part is showing it 2019-01-12 19:22:04 thereby increasing its info inputs 2019-01-12 19:22:06 <_ikke_> it's n-dimensional 2019-01-12 19:22:29 so is topic+msg 2019-01-12 19:22:56 don't look at single topic but all topics combined 2019-01-12 19:23:14 give an example 2019-01-12 19:23:16 ? 2019-01-12 19:24:35 try a simple test, compile mosquitto with mqtt-dirpub 2019-01-12 19:25:05 then , mosquitto_sub -h msg.alpinelinux.org -t '#' --fmask /tmp/msgs/@date/@topic --nodesuffix 'msg' 2019-01-12 19:26:43 <_ikke_> http://tpaste.us/vbNQ 2019-01-12 19:28:37 if it difficult to start, the normalize the 'topics' and msg format 2019-01-12 19:28:45 then normalize* 2019-01-12 19:29:40 publish them somewhere 2019-01-12 19:35:18 here, have a look, http://d.insteps.net/msgs/ 2019-01-12 19:35:26 here, have a look, http://d.insteps.net/msgs/ 2019-01-12 19:35:52 <_ikke_> that's just a lot of messages, not a visualization :-) 2019-01-12 19:36:17 <_ikke_> Not sure what I'm looking at 2019-01-12 19:36:25 yes, one needs to build analytic tool around it 2019-01-12 19:36:41 which was the problem domain to begin with 2019-01-12 19:37:08 <_ikke_> :-) 2019-01-12 19:37:14 it hierarchy or current mqtt msgs from msg.alpinelinux.org 2019-01-12 19:37:55 <_ikke_> ok, I think I was confused about what you were trying to show due to the first link 2019-01-12 19:38:00 <_ikke_> so *what* are you trying to show? 2019-01-12 19:38:39 SpaceToast: ?? domain ? 2019-01-12 19:39:13 https://en.wikipedia.org/wiki/Problem_domain 2019-01-12 19:39:14 [WIKIPEDIA] Problem domain | "A problem domain is the area of expertise or application that needs to be examined to solve a problem. Focusing on a problem domain is simply looking at only the topics of an individual's interest, and excluding everything else. For example, when developing a system to measure good practice in medicine..." 2019-01-12 19:39:47 the issue is collaboration, and thus the problem domain is the visualization and sorting of the data 2019-01-12 19:39:56 you are offering solutions as to how to gather data, which is not within the problem domain. 2019-01-12 19:40:16 ah, thought was related to domain -> insteps.net 2019-01-12 19:44:16 how does 'atop' aggregate date to display ? 2019-01-12 19:45:19 or htop? SpaceToast ^^ 2019-01-12 19:45:44 by having someone design a UI capable of holding bundles of one-dimentional data 2019-01-12 19:45:49 the issue here is that the data is n-dimentional 2019-01-12 19:46:30 please, stop, you are extraordinarily underestimating and miscalculating (or, perhaps, misunderstanding) the problem at hand 2019-01-12 19:49:13 ok, so mqtt would not work ? 2019-01-12 19:49:41 mqtt is not within the problem domain 2019-01-12 19:49:48 it's not that it wouldn't work, it's that it is not relevant in any way 2019-01-12 19:49:59 would wait to see the actual data when published 2019-01-12 19:50:07 ah, ok 2019-01-12 19:58:49 gtg, if someone starts that testing phase and posts data, pls let us know 2019-01-12 23:17:17 \o I got some interesting ideas for some stickers, so I quickly mocked something up in an hour or so; but it involves official alpine branding (https://alpinelinux.org/alpinelinux-logo.svg in particular) - is it ok if I use it and make them? 2019-01-12 23:17:42 (it's basically the entire logo, no changes to proportions, with the text "I actually BOOT it" under it, on two separate lines) 2019-01-13 07:47:46 I can't see why not if it's not branded as official merchandise 2019-01-13 07:47:53 but that's not an authoritative answer 2019-01-13 15:53:55 well, the logo belongs to someone :) 2019-01-13 15:54:13 I want to make sure that whoever holds the rights to it doesn't mind (even if there's no possible legal trouble, out of respect) 2019-01-13 15:54:33 just like how I expect people to at least ask me if they want to drastically change / bundle things I make 2019-01-13 17:07:07 clandmeter: how is armhf and armv7 builds? in containers or chroot, or cross-build? 2019-01-13 17:07:39 i know that they are build on aarc64 hardware 2019-01-13 17:12:12 btw, building firefox-esr on armv7 v3.9 natively, hope it will finish till midnight 2019-01-13 17:12:12 <_ikke_> mps: lxc containers 2019-01-13 17:13:10 _ikke_: lxc containers with armhf/armv7 as root fs? 2019-01-13 17:13:49 <_ikke_> I assume yes 2019-01-13 17:15:41 hmmm, could it work under chroot on lxc container? 2019-01-13 17:33:07 <_ikke_> why do you need a chroot? 2019-01-13 17:39:46 _ikke_: I think it will be easier and faster for me to setup 2019-01-13 17:41:05 in the container, I mean. setting container in container is complicated and I never tried 2019-01-13 17:50:58 <_ikke_> But you need the actual hw 2019-01-13 17:51:04 <_ikke_> just a fs is not enough 2019-01-13 17:51:31 mps, your container does not support 32b 2019-01-13 17:51:36 yes, I know, i have it 2019-01-13 17:52:12 We have other host that can do 32bit 2019-01-13 17:53:52 clandmeter: aha, I'm building firefox-esr on armv7 now, real hardware. it works but is slow 2019-01-13 17:56:52 I'm currently using an AWS aarch64 instance to test package modifications in a chroot. I've thrown a link to the modified alpine-chroot.sh script on https://wiki.alpinelinux.org/wiki/Installing_Alpine_Linux_in_a_chroot#Alpine_Linux_aarch64_in_a_chroot_on_AWS_Linux 2019-01-13 17:58:19 mps, what is your container ip? 2019-01-13 17:58:21 emolitor: no problem to install chroot, I do that for decades 2019-01-13 17:59:08 147.75.79.110 2019-01-13 17:59:20 Local ip 2019-01-13 17:59:36 Ah 2019-01-13 17:59:38 Ok 2019-01-13 17:59:44 172.16.12.10 2019-01-13 18:00:06 That box is 32bit capable 2019-01-13 18:01:06 mps: Do you know if there is a 'native' way to boot the Packet Cavium instances to alpine aarch64? I have free access to an instance via work and that would be faster than the AWS instances. 2019-01-13 18:01:18 so, could setup chroot with armv7 on it 2019-01-13 18:01:43 emolitor, absolutely 2019-01-13 18:01:51 emolitor: 'Packet Cavium', what is this 2019-01-13 18:02:07 That's what i thought you are on 2019-01-13 18:02:19 It's not 32bit capable 2019-01-13 18:02:54 mps: Basically many core aarch64 instances https://www.packet.com/cloud/servers/c1-large-arm/ 2019-01-13 18:03:01 emolitor, you can try to boot the rescue os from packet 2019-01-13 18:03:10 ok, never mind then, will continue with local box to see where I can reach 2019-01-13 18:03:18 Its based on Alpine :) 2019-01-13 18:03:29 clandmeter: ahhhh 2019-01-13 18:04:01 And you should be able to boot it via ipxe 2019-01-13 18:04:09 is it related to packent.net 2019-01-13 18:04:29 Packet is our sponsor 2019-01-13 18:04:54 We ♥️ packet :) 2019-01-13 18:05:15 packet are pretty good if you can afford them :D 2019-01-13 18:05:18 I know, but they are on packet.net and emolitor mentioned packet.com 2019-01-13 18:05:41 mps: packet.net redirects me to packet.com 2019-01-13 18:06:44 yes, I see especially if look :) 2019-01-13 18:08:00 Our company is funded by the same vc that funded packet so have some access to free compute... 2019-01-13 18:38:16 <_ikke_> I have some related packages that can be bumped, should I create a single PR for them or separate? 2019-01-13 19:36:04 Single should be ok 2019-01-13 20:28:58 wow, i just re-installed my laptop using rc1 2019-01-13 20:29:13 udev hotplug and firefox audio working again \o/ 2019-01-14 09:41:31 heh that was on my list for this week 2019-01-14 09:46:50 <_ikke_> jwh: aha 2019-01-14 09:46:54 <_ikke_> I just ran into it 2019-01-14 09:47:37 :D 2019-01-14 09:53:08 <_ikke_> I figure this should also be fixed for 3.9 2019-01-14 09:58:15 yeah probably 2019-01-14 10:06:32 to not forget, sane build on armhf/armv7/aarch64 is disabled. I noted that removing libieee1284 from makedepends and disable on of backends solves problem, but didn't tested to end 2019-01-14 10:07:50 is this packages (sane and simple-scan) important for ARM or we can ignore the issue 2019-01-14 10:08:21 <_ikke_> Hmm, I wonder who wants to connect a scanner to an arm device 2019-01-14 10:09:03 btw, libieee1284 could be built because musl doesn't have some needed include/libs for ARM 2019-01-14 10:09:36 <_ikke_> couldn't? 2019-01-14 10:10:20 _ikke_: maybe you, today exists powerfull ARMs which don't have ieee1284 but have usb etc... 2019-01-14 10:10:49 _ikke_: sorry, couldn't. right 2019-01-14 10:11:06 usb scanners, thats going back 2019-01-14 10:11:07 :D 2019-01-14 10:11:57 jwh: some people have old ones and would like to use it 2019-01-14 10:12:34 where do we stop, lpt? 2019-01-14 10:13:03 on the other word, there are network scanners which are used, and ARM today are quite fine working machines 2019-01-14 10:13:59 IP scanners are so cheap now (usually in the form of multi function printers) and have been for like 5 or 6 years, theres really no reason to still have old usb ones 2019-01-14 10:14:01 well, there are a lot of laboratories with instruments which have ieee1284 2019-01-14 10:14:05 also the DPI sucks 2019-01-14 10:14:32 true 2019-01-14 10:14:46 isn't that what scientific linux is for though? 2019-01-14 10:16:19 yes. but how then Alpine could achieve world domination :) 2019-01-14 10:16:36 ha 2019-01-14 10:31:17 <_ikke_> clandmeter: will someone also take care of backporting that composer fix to 3.8/3.9? 2019-01-14 11:26:22 _ikke_, 3.9 == edge 2019-01-14 11:29:45 <_ikke_> clandmeter: Ah, I though because there was already an rc 2019-01-14 11:34:23 nope, when final is released stable branch is created and builders will be updated to follow it. 2019-01-14 11:36:32 <_ikke_> ok 2019-01-14 11:36:56 <_ikke_> So only bug-fixes after rc means you need to limit what you merge into edge 2019-01-14 11:38:35 _ikke_, you didnt bump pkgrel? 2019-01-14 11:38:47 <_ikke_> ugh, sorry, forgot that :( 2019-01-14 11:40:59 np i also missed it :) 2019-01-14 11:41:06 but corrected 2019-01-14 11:41:13 <_ikke_> clandmeter: thanks 2019-01-14 15:38:50 ncopa: Yo. Morten from the repro summit :) When you have 3-4 minutes free for a PM please give me a headsup 2019-01-14 17:50:18 I need a Dockerfile using alpine + java + python 2019-01-14 17:51:31 is it possible? 2019-01-14 17:57:12 alpine has packages for openjdk8 and python2 + python3 you can install them using `apk add python3 openjdk8` 2019-01-14 18:02:40 ok thanks 2019-01-14 18:28:53 i need a package for limits.h, which package should I use? 2019-01-14 18:41:57 vivi_: according to https://pkgs.alpinelinux.org/contents?file=limits.h&path=&name=&branch=edge&arch=x86_64 sounds like it should be musl-dev 2019-01-14 21:08:45 in lxc on AL trying: 'mount --bind /home/mps /armv7/home/mps' gives me: 'mount: /armv7/home/mps: permission denied' 2019-01-14 21:09:04 as root, ofc 2019-01-14 21:09:22 anyone have hint for me 2019-01-14 21:12:50 missing overlayfs? 2019-01-14 21:14:54 no, not problem with overlayfs. 2019-01-14 21:24:33 mps: see mount(2), EACCESS: A component of a path was not searchable. 2019-01-14 21:24:51 make sure +r is set on the dirs 2019-01-14 21:30:02 AinNero: it is. It works on my local containers without issue but that one where is the problem is somewhere else 2019-01-14 21:30:28 and you got CAP_SYS_ADMIN ? 2019-01-14 21:30:31 maybe unprivileged container 2019-01-14 21:31:17 probably not 2019-01-14 21:32:50 its not an unprivileged container 2019-01-14 21:32:56 but it does have restrictions 2019-01-14 21:34:20 ah, understand. wanted to use same home dir in chroot. now I will just copy it 2019-01-14 22:13:56 ncopa: I don't think your fcgiwrap fix made it to the repos 2019-01-15 02:13:30 is there a docker irc? 2019-01-15 02:17:39 patience is a virtue reserved for but a select few 2019-01-15 03:31:08 does anyone know why so many APKBUILD's are having "|| return 1" placeholders in many places? Isn't it defeating the whole purpose of builds/tests? 2019-01-15 03:31:15 https://i.imgur.com/sR0xnFX.png 2019-01-15 03:34:50 dimon222: "fail early" is a thing - if the build/test already failed, it bails out 2019-01-15 03:35:08 this is no longer needed though, since the default is `set -e` (which effectively does that to every single command) 2019-01-15 03:41:11 i see, completely forgot that its non-zero exit code in shell 2019-01-15 03:42:09 ah, that'd do it :) 2019-01-15 03:42:33 this is because exit codes are used to convey *which* error happened (think errno) 2019-01-15 07:44:31 SpaceToast: I don't know whether this applies to whatever sh Alpine uses at the moment, but at least in bash -e is slightly strange inside functions 2019-01-15 16:28:52 does anyone have any concern wrt enabling eBPF? #alpine-commits 2019-01-15 16:29:06 #9856 2019-01-15 16:30:47 afaik it is a source of plentiful kernel security issues 2019-01-15 16:31:06 not a good default 2019-01-15 16:31:27 i suspect that is why it is disabled currently 2019-01-15 16:36:58 would it be an idea to compile support for it but disable it by default, somehow? I dunno if kernel.unprivileged_bpf_disabled=1 is enough 2019-01-15 16:41:04 kaniini, please check https://github.com/alpinelinux/aports/pull/6030 2019-01-15 16:41:34 andypost: ack 2019-01-15 16:41:42 andypost: cannot commit on their behalf atm though 2019-01-15 16:42:45 kaniini, I find it strange that patch release require new dependencies 2019-01-15 16:44:29 it doesn't 2019-01-15 16:44:33 he added tests 2019-01-15 16:44:38 which require the dependencies 2019-01-15 16:44:41 they are in checkdepends 2019-01-15 16:45:23 ah... then it looks good to go 2019-01-15 17:26:28 ncopa: I agree with p4Wv1qn095FW about eBPF, it is 'can of worms', imo 2019-01-15 17:27:49 ncopa: i've created that bug report. i'm not going to insist on it. 2019-01-15 17:28:40 ncopa: i found only kernel.unprivileged_bpf_disabled option 2019-01-15 17:29:19 that way unprivileged users can't load eBPF programs 2019-01-15 17:30:40 also it is not enabled by default, thus by default anyone can load eBPF programs 2019-01-15 17:31:02 hatramatra: users who needs eBPF usually builds their own kernel/s and don't use kernels from distributions 2019-01-15 17:34:06 mps: i'm not sure i agree with that view 2019-01-15 17:34:17 eBPF is new (relatively, to say) subsytem in kernel and not yet passed deep scrutiny for use in secure environments/systems and there are not much programs which could benefit from it 2019-01-15 17:36:37 afaict the grsec people are having a lot of schadenfreude for the ebpf subsystem. 2019-01-15 17:36:49 actually, I like it as tool to extend kernels and by that whole system, but will not use it for anything exposed to internet 2019-01-15 17:40:10 i actually don't understand why it is needed for vrf functionality 2019-01-15 17:40:30 anybody knows what CONFIG_BPF=y does? that is already enabled in our kernel 2019-01-15 17:43:02 BPF is the Berkley Packet Filter, a pretty old piece of tech 2019-01-15 17:43:16 eBPF is a kernel-specific extended variant 2019-01-15 17:44:14 re: eBPF enabling, I think just disabling unprivileged bpf is fine - if root runs some weird eBPF code, that's root's fault 2019-01-15 17:44:35 (similarly, if root copy pastes dd if=/dev/zero of=/dev/sda, we can't (nor should) necessarily try to stop that) 2019-01-15 17:44:46 unprivileged users being able to break the system, however, is obviously not ok 2019-01-15 17:48:15 SpaceToast: well said. but anyway I would not use eBPF enabled kernels till it passes 'battlefield' for some time 2019-01-15 17:49:37 whoever is developing this is rather confident (incorrectly based on CVE-2017-16995) that it is safe to lead even unprivileged users to use it by default 2019-01-15 17:50:32 to me it also makes more sense to need explicitly opt-in and have it enabled by the administrator 2019-01-15 17:52:19 if we compile this in, should we hand in hand update also /etc/sysctl.d/00-alpine.conf so it's disabled by default? 2019-01-15 17:53:05 can it be compiled in as a module? 2019-01-15 17:53:13 sysctl is better than cmdline, imo 2019-01-15 17:53:15 then we could disable unprivileged uses by default, and require a module lode 2019-01-15 17:54:58 SpaceToast: i need to check if it can be compiled as a module 2019-01-15 17:56:10 ignore me, just want to test something 2019-01-15 17:56:14 algitbot: thanks for trying 2019-01-15 17:56:20 thanks 2019-01-15 17:56:27 is the code up somewhere? 2019-01-15 17:56:28 if it can be compiled as a module, I'd think it's perfectly ok to =m it and disable unpriv in 00-alpine.conf 2019-01-15 17:56:56 AinNero: I don't know for sure, but git.a.o mentions sircbot ( https://git.alpinelinux.org/hosted/sircbot/ ) 2019-01-15 17:57:00 perhaps that's the base for him 2019-01-15 18:02:59 someone asked me why Alpine doesn't have /opt . Anyone knows? 2019-01-15 18:03:39 We don't distribute packages that we do not build 2019-01-15 18:03:48 Therefore we don't need /opt 2019-01-15 18:04:41 (/opt is typically for things like tar xf from a website tarball, and similar) 2019-01-15 18:06:26 SpaceToast: CONFIG_BPF_SYSCALL cannot be compiled as a module, thus 00-alpine.conf is the only option 2019-01-15 18:06:40 hatramatra: are you sure that's for eBPF? 2019-01-15 18:06:50 rather than traditional posix/linux BPF 2019-01-15 18:07:06 only one of those is new and questionable, the other one is older than netfilter and pf 2019-01-15 18:07:27 CONFIG_BPF_SYSCALL: Enable the bpf() system call that allows to manipulate eBPF programs and maps via file descriptors. 2019-01-15 18:07:35 SpaceToast: that's were my thoughts, just wanted confirmation from someone, thanks 2019-01-15 18:07:52 mps: if they really want to have an /opt, they can mkdir it :) 2019-01-15 18:08:31 SpaceToast: ofc, ) 2019-01-15 18:08:56 hatramatra: ok, looks like it's indeed for eBPF and not cBPF (weird name, but whatever) 2019-01-15 18:09:06 unfortunate that it can't be a module, but I still think blocking unprivileged users should be enough 2019-01-15 18:13:46 SpaceToast: I don't have facts but 'somewhere in my head' something say 'unprivileged escalation' 2019-01-15 18:14:29 beh, privilege escalation 2019-01-15 18:14:43 if you have privilege escalation, you can do a lot worse than running some eBPF code 2019-01-15 18:16:54 ofc, but just my feeling is that a eBPF one is a potential big risk. 2019-01-15 18:17:20 well, module loading in general is too, as is having a root user, for example :) 2019-01-15 18:17:37 I think that if we trust root, we can trust root with eBPF, and if we don't trust root, we should make some major changes fast 2019-01-15 18:18:11 anyway, I don't argue of it's use or not, that is should be decided by user/admin. will stop here 2019-01-15 18:21:00 i've updated the bug report with findings 2019-01-15 18:21:25 SpaceToast,mps: thank you both for the discussion 2019-01-15 18:58:17 regarding this SEC issue: https://sintonen.fi/advisories/scp-client-multiple-vulnerabilities.txt 2019-01-15 18:59:55 I built locally openssh where I added libedit for sftp and use it instead of scp long time ago, at least eights months 2019-01-15 19:00:47 and disabled pam, btw. do we need pam support in openssh? 2019-01-15 19:07:51 I'd keep it even though it's probably not used in Alpine by default, and just disable it by default in the config 2019-01-15 19:08:45 TBB: it's currently not enabled, the question is whether or not it's ok to enable it in kernel but disable unprivileged access 2019-01-15 19:16:26 oh, mine was just a response for disabling pam, the ebpf issue I have no comments on 2019-01-15 19:17:06 Ah 2019-01-15 19:24:44 TBB: pam is diabled by default in /etc/ssh/sshd_config on Alpine 2019-01-15 19:25:14 s/diabled/disabled/ 2019-01-15 19:25:14 mps meant to say: TBB: pam is disabled by default in /etc/ssh/sshd_config on Alpine 2019-01-16 03:08:18 couple of more stupid questions. How to enforce specific version in depends and makedepends in alpine APKBUILD? 2019-01-16 03:08:45 i know that Alpine repo doesn't maintain package versions (aka only latest), but would be good to enforce existence of newest package otherwise it might cause side effects 2019-01-16 09:25:08 it seems mariadb-dev provides /usr/lib/pkgconfig/libmariadb.pc version 3.0.8 while mariadb-connector-c-dev provides version 3.0.7 and they conflict. Since mariadb-connector-c provides libmariadb.so already, should we do so with http://tpaste.us/KgEY ? 2019-01-16 09:25:37 this is on 3.9 repo 2019-01-16 11:00:37 <_ikke_> RHEL 8 does no longer include mongodb due to it's new license 2019-01-16 12:42:46 <_ikke_> reference: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8-beta/html/8.0_beta_release_notes/new-features#web_servers_databases_dynamic_languages_2 2019-01-16 14:46:38 interesting, what is now going to be the process to get mongodb ? they even consider stopping making tarballs. Compilation is the only way to go? 2019-01-16 14:49:28 apk add mongodb ? :) 2019-01-16 14:50:58 (RHEL no longer including it doesn't necessarily mean we won't, according to mongo SSPL should be OSI-compatible (and is in the process of OSI-approval) 2019-01-16 14:54:14 also, latest mongo builds are from december, whereas the license took effect in October 2019-01-16 15:54:19 is sane maintainer here? 2019-01-16 15:56:22 I prepared fix to build it on aarch64 and armv7/armhf but would like to ask for review before sending patch 2019-01-16 19:29:06 tmhoang: looks like you are right 2019-01-16 19:47:22 AinNero: we dont have the code for algitbot available for public anywhere (yet) 2019-01-16 19:47:49 i sort of started a rewrite of it 2019-01-16 19:52:53 hatramatra: what i´d want is to disable (unprivileged) ebpf support in kernel by default, and use sysctl to enable it 2019-01-16 19:53:50 i think its a question of flipping a ´0´ to a ´1´somewhere in the kernel source code 2019-01-16 19:54:14 i dont think its possible to disable ebpf competely 2019-01-16 21:34:47 ncopa, did you already take a look at clang? 2019-01-16 21:44:16 patch for https://bugs.alpinelinux.org/issues/9861 is not still visible on patchwork.a.o, and I received email response about hour ago from alpine-aports@lists.alpinelinux.org with the patch 2019-01-16 21:44:38 rspamd in action? 2019-01-16 21:45:24 no, my mail server log says it is accepted 2019-01-16 21:48:39 mps, hmm 2019-01-16 21:50:02 2019-01-16 21:23:36 [postfix/smtp] 52A4F1B924: to=, relay=mail.alpinelinux.org[74.117.189.116]:25, delay=5.1, 2019-01-16 21:50:27 dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 27EDBF85675) 2019-01-16 21:50:37 sorry for noise 2019-01-16 21:52:06 yes i know 2019-01-16 21:52:16 but lists should send it to patchwork 2019-01-16 21:52:35 i made some change, maybe i broke it. 2019-01-16 22:25:46 ncopa: would we maintain patch for kernel flipping this bit in aports? 2019-01-16 22:31:45 mps, i think i fix it. 2019-01-16 22:35:46 should I send patch again or it will be there in some time 2019-01-16 22:36:43 its on the ml just not in patchwork. 2019-01-16 22:38:31 could pwclient see it if it isn't on patchwork.a.o 2019-01-16 22:39:09 pwclient is same as web but for shell 2019-01-16 22:39:14 so no it cant see it 2019-01-16 22:39:30 if you tpaste me the patch ill check it. 2019-01-16 22:40:00 i do not have mail configured on my shell 2019-01-16 22:40:14 maybe it is easier to resend it? 2019-01-16 22:40:41 if that option is acceptable 2019-01-16 22:40:51 what is the difference? 2019-01-16 22:41:03 tpaste is much easier :) 2019-01-16 22:41:50 well, it's also easy for to send again, but never mind I'll tpaste it 2019-01-16 22:42:09 its confusing if you send it twice to the list 2019-01-16 22:42:32 ah, so i asked is that acceptable 2019-01-16 22:42:42 now it is clear 2019-01-16 22:42:54 i didnt say its not, tpaste is just nicer. 2019-01-16 22:43:46 by 'acceptable' I mean 'nice/fine' actually 2019-01-16 22:44:24 mps: you might consider "so I asked if that's ok" - this has a slight connotation that it's a variant you prefer 2019-01-16 22:44:41 you know that the finest points of English is not my good part 2019-01-16 22:44:47 yeah, that's why I'm trying to help :) 2019-01-16 22:45:02 np, and thank you 2019-01-16 22:46:03 clandmeter: will send tpaste in about ten minutes, I'm outside right now 2019-01-16 22:50:41 hmmm, so how much of a pita is it going to be to make alpine boot on uefi? 2019-01-16 22:51:00 jwh: depends on your specific UEFI implementation and skill level 2019-01-16 22:51:12 well actually I guess it doesn't really matter since alpine won't touch the bootloader 2019-01-16 22:51:40 export USE_EFI=true 2019-01-16 22:51:48 and setup-disk should handle UEFI setup for you 2019-01-16 22:51:53 I'm not intending to try and boot the iso or anything 2019-01-16 22:51:56 if you partition on your own (e.g if you want esp on /boot) it's a bit different 2019-01-16 22:52:04 you should not need that if it kernel detects efi 2019-01-16 22:52:14 total pain in the ass to boot anything other than mmc on this stick 2019-01-16 22:52:20 it's already running arch so in theory..... 2019-01-16 22:52:28 but tl;dr UEFI can work, whether or not it does depends on the specific implementation 2019-01-16 22:52:58 yes and the options you provide to setup-disk. some exotic setups will probably not work. 2019-01-16 22:53:25 if I can find a convenient initramfs to boot that has the required utils on to shrink the arch partition I can just install alpine on a secondary partition, or even just dd an image create by that script 2019-01-16 22:53:40 kernel doesn't care how its booted anyway, right? 2019-01-16 22:56:32 alright so if I wanna use setup-alpine because I'm lazy, I'll still have to convince grub to boot alpine 2019-01-16 22:56:59 jwh: in theory, setup-disk configures grub 2019-01-16 22:57:11 well I mean, existing grub 2019-01-16 22:57:15 ah, yeah 2019-01-16 22:57:17 it's uh, baytrail - so 32bit uefi 2019-01-16 22:57:24 so I doubt it would actually work OOTB anyway 2019-01-16 22:57:33 on arch you could probably get os-scanner and see if that helps you out 2019-01-16 22:57:37 the UEFI bit is handled by grub as-is 2019-01-16 22:57:41 I made this work long before any distributions were even building 32bit grub loaders 2019-01-16 22:58:03 hm, what does the netboot release do? 2019-01-16 22:58:05 but in that case you might not want to use setup-disk at all 2019-01-16 22:58:07 boot up, dhcp, ssh? 2019-01-16 22:58:19 (or, at least, not to set up your disk), I doubt you want a second/new esp 2019-01-16 22:58:26 clandmeter: https://tpaste.us/Kgxg 2019-01-16 22:58:41 netboot is just kernel and initramfs which support network booting. 2019-01-16 22:58:42 basically its already running, I can replace arch but I can't really boot any external media as a) can't find my powered usb hub, b) it's an absolute chore 2019-01-16 22:58:46 oh 2019-01-16 22:58:55 extended I think I need then 2019-01-16 22:58:57 and ofc modloop 2019-01-16 22:59:01 whichever runs from ram 2019-01-16 22:59:08 you can use something like ipxe 2019-01-16 22:59:16 boot.alpinelinux.org 2019-01-16 22:59:37 ohhh 2019-01-16 22:59:39 good shout 2019-01-16 22:59:45 ipxe is great, if you got it 2019-01-16 23:00:14 havent used it on anything other than undi supported boxes (as in, native)... it's not going to support whatever nonsense usb nic this is, is it? 2019-01-16 23:00:25 I use netboot.xyz myself because I have other needs, they do support alpine though 2019-01-16 23:00:38 yes kind of 2019-01-16 23:01:08 i had some issues but no energy to fix it. 2019-01-16 23:01:22 the aarch64 is kind of broken. 2019-01-16 23:01:35 hm, I expect I'm gonna have a bit of bother with a 32bit ipxe uefi 2019-01-16 23:01:37 binary 2019-01-16 23:02:45 the main issue really is finding something I can just boot into ram and shrink the existing partition, gonna be a pain in the ass if I nuke the arch install and it doesn't work first time 2019-01-16 23:03:18 you cant boot from usb? 2019-01-16 23:03:23 not easily 2019-01-16 23:03:34 requires a powered usb hub and magical key presses 2019-01-16 23:03:50 I can't find the former or remember the latter 2019-01-16 23:04:03 jwh: you can probably do the grub loopback trick to boot an arch iso (alpine isos cannot be loopback-booted) from the disk, which would load the whole image to ram and exec in 2019-01-16 23:04:10 I don't remember how to actually do it at this point though 2019-01-16 23:05:03 ah actually I guess I could do that 2019-01-16 23:05:10 since thats what the iso does anyway 2019-01-16 23:05:29 you can probably copy the netboot stuff to some dir in /boot and tell grub to boot it. 2019-01-16 23:05:51 I guess if theres enough of an OS to boot to a shell 2019-01-16 23:06:08 and has the required kernel support/modules 2019-01-16 23:07:30 with netboot kernel and initramfs you can fetch the modloop via modloop=http... 2019-01-16 23:07:57 ah interesting idea 2019-01-16 23:08:47 you can even fetch your ssh key and make it start sshd :) 2019-01-16 23:09:14 ha 2019-01-16 23:10:39 clandmeter: is that documented anywhere? I'll make a note to adapt that (or at write it to begin with if not) 2019-01-16 23:12:15 SpaceToast, check firstboot initd 2019-01-16 23:13:58 if ext had online shrinking this would be much easier heh 2019-01-16 23:15:07 clandmeter: ah cool, thanks :) 2019-01-16 23:35:13 clandmeter, please backport https://github.com/alpinelinux/aports/pull/6065 2019-01-16 23:38:13 ugh, pain in the ass 2019-01-16 23:42:01 bleh thought I could cheat and just do modloop= but it ain't having it 2019-01-16 23:45:53 probably doesn't have the kmods for the mmc heh 2019-01-17 00:44:54 hm, why does grub require syslinux (for extlinux)? 2019-01-17 00:44:58 seems kinda... redundant 2019-01-17 00:45:18 config generation is broken otherwise 2019-01-17 00:46:04 jwh: grub generation is done kind of strange, and uses /etc/update-extlinux.conf 2019-01-17 00:46:13 yeah I gathered that bit :P 2019-01-17 00:46:17 (see, for example, 10_linux line 24) 2019-01-17 00:46:17 just wondering why 2019-01-17 00:46:23 you'll have to ask the maintainer ¯\_(ツ)_/¯ 2019-01-17 00:46:27 it's on my list of things to fix 2019-01-17 00:46:35 ah 2019-01-17 00:46:35 I suspect it's because of the grub bug that makes it fail to find our initrd 2019-01-17 00:47:00 it's an easy 1-line fix, but upstream seems to hate me, and I haven't gotten around to figuring out what we do to our grub.d folder to actually patch it on our end 2019-01-17 00:47:04 oh, that 2019-01-17 00:47:20 ideally grub should be separate 2019-01-17 00:47:34 anyway, you shouldn't need grub, since your archgrub can just load alpine directly 2019-01-17 00:47:43 (and you definitely don't want a second esp) 2019-01-17 00:47:46 Ibroke it 2019-01-17 00:47:47 I broke it* 2019-01-17 00:48:09 I managed to get media booted without a powered hub, I'm better than gary sinese in apollo 13 2019-01-17 00:50:21 annoyingly, grub-efi doesn'gt include i386-efi 2019-01-17 01:03:52 its installed anyway, its just uh... not bothering to load usb keyboard kmods 2019-01-17 01:03:55 :D 2019-01-17 01:16:03 hm 2019-01-17 01:16:46 becoming more effort than its worth 2019-01-17 01:16:57 isn't bothering to load any usb drivers 2019-01-17 01:24:30 aha, sorted 2019-01-17 02:04:20 bah, tried to add it to grub APKBUILD but the hyphen breaks it, sigh 2019-01-17 03:05:25 heh, almost working apart from hdmi/graphical corruption on reboot, or hanging when trying to reset 2019-01-17 03:05:52 is python 3.7 anywhere in alpine yet? 2019-01-17 03:06:30 doesn't appear to be 2019-01-17 03:45:34 hm, what are the rules for pkgver? no periods, hyphens, ... ? 2019-01-17 03:47:54 hm 2019-01-17 04:15:10 https://wiki.alpinelinux.org/wiki/APKBUILD_Reference#pkgver 2019-01-17 04:15:39 yeah 2019-01-17 04:15:44 its a bit restrictive heh 2019-01-17 04:16:25 ye i think due to the ways it searches for package in APKINDEX 2019-01-17 04:17:23 heh 2019-01-17 04:17:26 also a lot of stuff was borrowed from archlinux i believe (?) from their PKGBUILD versioning 2019-01-17 04:24:20 heh, can't add real version or git hash, made up pkgver it is 2019-01-17 09:57:11 ncopa: just FYI: I was able to start Alpine on openstack, I followed this: https://github.com/rvalente/alpine-openstack-image 2019-01-17 13:05:31 nice 2019-01-17 13:05:48 what are the blocker(s) for doing a 3.9.0 rc2? 2019-01-17 13:06:26 rust and clang? 2019-01-17 13:06:37 do we need skia patch for firefox 2019-01-17 13:16:31 Debian have it, and Fedora iirc, Adelie also 2019-01-17 13:18:03 what's the blocker for rust? 2019-01-17 13:18:30 we currently only have it on x86 2019-01-17 13:18:32 regarding rust, right now building llvm6, I thihnk rust have problems with llvm5, at least for ARM 2019-01-17 13:23:03 hum 2019-01-17 13:23:12 so in order to get rust, we need upgrade llvm_ 2019-01-17 13:23:30 oh, ok. 2019-01-17 13:24:10 mps: what is the skia patch? 2019-01-17 13:24:14 what does it do 2019-01-17 13:24:18 I'm trying to upgrade llvm, will see is that enough 2019-01-17 13:25:05 do we upgrade to llvm7 while at it? 2019-01-17 13:25:12 or we only jump to llvm6 2019-01-17 13:25:27 skia is something which 'reorders' RBGA to BGRA in gfx engine 2019-01-17 13:26:14 ncopa: maybe going form llvm5 to llvm7 is big step 2019-01-17 13:27:44 here is docs about it https://skia.org/ 2019-01-17 13:27:54 can we ship alpine 3.9 with llvm5 and upgrade after 3.9 release? 2019-01-17 13:28:08 3.10 release should be out May 2019 2019-01-17 13:28:15 I've built ff with that patch 2019-01-17 13:29:00 i dont mind adding skia patch 2019-01-17 13:29:33 ok, btw I don't see big difference with it 2019-01-17 13:30:27 i think it would be nice to fix grub though 2019-01-17 13:30:34 so it does not depend on syslinux 2019-01-17 13:30:55 regarding llvm6, just finished 'abuild rootpkg' and now have to check if it help with rust building 2019-01-17 13:31:33 ok 2019-01-17 13:34:03 also, chromium is broken 2019-01-17 13:37:50 chromium on arm and ppc, you mean 2019-01-17 13:42:27 btw, I have question about crystal. in APKBUILD there is snapshot() function which build static version and upload it to the https://dev.alpinelinux.org/archive/crystal/ 2019-01-17 13:43:19 how this function could be triggered on build box? manually or add something in APKBUILD 2019-01-17 13:49:01 ugh, crashing has left me with all these build dependencies installed, fml 2019-01-17 13:50:30 jwh: there should be a virtual package beginning with a dot 2019-01-17 13:50:40 ah good point 2019-01-17 13:53:47 jwh, or abuild undeps 2019-01-17 13:53:58 oh, cool 2019-01-17 13:54:00 thanks guys 2019-01-17 13:54:11 obviously not crashing would be nice but I'm not even getting a panic :( 2019-01-17 14:02:13 clandmeter: have you noticed my question about crystal? and sorry for impatience 2019-01-17 14:02:40 its never triggered on buildbox 2019-01-17 14:02:48 a developer needs to do that 2019-01-17 14:03:44 so, developer who have ssh/scp access dev.alpinelinux.org I think 2019-01-17 14:03:57 yes, but any dev with push access has that. 2019-01-17 14:05:26 someone should do that, because I can't 2019-01-17 14:05:44 need to do what? 2019-01-17 14:06:25 to put static crystal on dev.alpinelinux.org 2019-01-17 14:07:02 sorry i dont follow. 2019-01-17 14:07:13 it is needed to bootstrap next version when they release 2019-01-17 14:07:30 it cannot depend on itself? 2019-01-17 14:07:58 well, it is how it works 2019-01-17 14:08:19 i dont know. maybe ask the maintainer 2019-01-17 14:08:30 you need a crystal to bootstrap new version when released 2019-01-17 14:08:39 most of these new languages depend on itself to build itself. 2019-01-17 14:09:18 maintainer is jirutka but he is not here or on ML, afaik 2019-01-17 14:09:50 he is alive, just not as active as before. 2019-01-17 14:10:14 are you trying to build crystal for 3.9? 2019-01-17 14:10:26 I see that he pushes patches 2019-01-17 14:10:48 or is it for a new arch? 2019-01-17 14:11:15 it is already built, just missing that static tarball on dev.a.o 2019-01-17 14:12:06 only on x86_64 and aarch64 2019-01-17 14:12:10 ok i have no idea about crystal 2019-01-17 14:12:16 please ask somebody who does :) 2019-01-17 14:13:20 I sent patches to upgrade it to new version and patch is accepted, crystal is in v3.9_r1 already 2019-01-17 14:15:00 just need someone who have access to dev.a.o to trigger snapshot in APKBUILD 2019-01-17 14:17:02 btw, crystal core devs uses Alpine as paltform where they test new features and releases first 2019-01-17 15:26:58 mps: crystal's `abuild snapshot` fails: 2019-01-17 15:27:02 gcc "${@}" -o '/home/ncopa/aports/community/crystal/src/crystal-0.27.0/.build/crystal' -no-pie -Wl,--as-needed -rdynamic -static /home/ncopa/aports/community/crystal/src/crystal-0.27.0/src/llvm/ext/llvm_ext.o `/usr/bin/llvm-config --libs --system-libs --ldflags --link-static 2> /dev/null` /usr/lib/libstdc++.a /usr/lib/libpcre.a /usr/lib/libm.a /us 2019-01-17 15:27:02 r/lib/libgc.a /usr/lib/libpthread.a /home/ncopa/aports/community/crystal/src/crystal-0.27.0/src/ext/libcrystal.a /usr/lib/libevent.a /usr/lib/librt.a -L/usr/lib -L/usr/local/lib _main.o 2019-01-17 15:27:02 collect2: error: ld returned 1 exit status 2019-01-17 15:27:02 libstdc++.a /usr/lib/libpcre.a /usr/lib/libm.a /usr/lib/libgc.a /usr/lib/libpthread.a /home/ncopa/aports/community/crystal/src/crystal-0.27.0/src/ext/libcrystal.a /usr/lib/libevent.a /usr/lib/librt.a -L/usr/lib -L/usr/local/lib` 2019-01-17 15:27:02 Error: execution of command failed with code: 1: `gcc "${@}" -o '/home/ncopa/aports/community/crystal/src/crystal-0.27.0/.build/crystal' -no-pie -Wl,--as-needed -rdynamic -static /home/ncopa/aports/community/crystal/src/crystal-0.27.0/src/llvm/ext/llvm_ext.o `/usr/bin/llvm-config --libs --system-libs --ldflags --link-static 2> /dev/null` /usr/lib/ 2019-01-17 15:27:03 make: *** [Makefile:123: .build/crystal] Error 1 2019-01-17 15:32:21 huh, it worked locally, I even preserved tarballs. Will look at issue when I come back to home, I'm out now 2019-01-17 15:38:01 meh, back to arch on this stick, will have to leave kodi aports stuff for now :( 2019-01-17 15:38:53 mps: can you please upload the tarballs to your arch container and I'll upload them to the dev archive 2019-01-17 15:39:10 ncopa, why do we need those? 2019-01-17 15:39:28 mps: why do we need those? 2019-01-17 15:39:47 clandmeter: i assume it is for bootstrapping? 2019-01-17 15:40:07 it is needed to bootstrap next version when it be released 2019-01-17 15:40:25 you cannot bootstrap with the one available in aports? 2019-01-17 15:40:55 althouth I thought that if we already have it in repo do we need static version to make new release 2019-01-17 15:41:11 ah, we have same thoughts 2019-01-17 15:41:15 right, initial bootstrap ofc we need it. 2019-01-17 15:41:41 like we do for golang 2019-01-17 15:41:43 I left that to work on after v3.9 will be released 2019-01-17 15:41:57 ok 2019-01-17 15:42:09 so what is left for the 3.9 now? 2019-01-17 15:42:16 its only llvm6 and rust? 2019-01-17 15:42:36 actually , I hope that that snapshot will not be needed at the end 2019-01-17 15:42:56 ncopa: I built llvm6 localy 2019-01-17 15:43:25 and now trying with it to build rust 2019-01-17 15:43:37 should that fix t he issue we have with clang on armhf? 2019-01-17 15:43:41 but building rust takes some time 2019-01-17 15:45:11 for some uncomprehensible reason for me, build crash when try with more than two parallel jobs 2019-01-17 15:46:26 so it takes few hours for one try 2019-01-17 15:47:38 <_ikke_> Anyone an idea what I should do about this error which only happens on builders? "IOError: [Errno 6] No such device or address: '/dev/tty'" 2019-01-17 16:03:23 _ikke_: i dont know. it looks weird 2019-01-17 16:03:35 the device node seems to exist on the builder 2019-01-17 16:04:08 i guess one option is to patch redo to not exit with error if it fails to open it 2019-01-17 18:51:06 i'm looking at grub config 2019-01-17 18:51:23 the grub-mkconfig is just insanely complicated 2019-01-17 18:51:33 and still does not do what we need from setup-disk 2019-01-17 18:51:45 so we may need to chroot and run it from there 2019-01-17 18:53:29 as I've probably mentioned before, I wrote a custom installer for a project I worked in until the end of last year... had a library for installing different boot loaders, among other things, and that was indeed the approach 2019-01-17 19:02:02 ncopa: chroot + run is the preferred approach 2019-01-17 19:02:27 I could / would be interested in adopting grub once I have more free time (so once the main writing effort for docs is done) 2019-01-17 19:06:27 on x86*, is there any other choice really, especially if you want to utilize any sort of boot time security... gummiboot was okay but limited (and is now tied to systemd anyway), syslinux has its own limitations, etc. 2019-01-17 19:13:57 i have fixed the dependency of update-extlinux.conf #8601 2019-01-17 19:22:38 ncopa: regarding rust, I'm not sure when it will be ready. So, you decide to release v3.9 or not and don't wait for rust on aarch64 and armv7 2019-01-17 19:23:24 mps: i am thinking it may make sense to just ship v3.9 now 2019-01-17 19:23:42 and then do the llvm upgrade, fix rust, upgrade python7, etc 2019-01-17 19:23:45 and then do 3.10 2019-01-17 19:24:22 also, upgrading llvm to version 6, it could be done but I fear that a lot of packages must be rebuilt and maybe will some bugs appear because of the change 2019-01-17 19:24:34 exactly 2019-01-17 19:24:38 I agree 2019-01-17 19:24:39 thats what i fear as well 2019-01-17 19:25:07 good, we understand complexity behind all that 2019-01-17 19:25:27 small note, 3.10 or 4.0 ;) 2019-01-17 19:26:02 based on prior input, sounds like it'd be more 3.10, since no breaking change was made 2019-01-17 19:26:17 yes, thats what i think too 2019-01-17 19:27:12 however you want, but 3.10 is four character and 4.0 just three ;) 2019-01-17 19:28:12 just one question before release, is there a problem with clang on armhf? 2019-01-17 19:28:25 not sure 2019-01-17 19:29:27 ok then 2019-01-17 19:32:57 iirc, clandmeter mention it today but don't know what is the issue if it exists at all 2019-01-17 19:42:46 i wonder if we should use grub as default boot loader 2019-01-17 19:43:05 its the only one that supports all arches 2019-01-17 19:43:16 we can still support extlinux for those who prefers that 2019-01-17 19:44:25 it seems that it should be relatively easy to fix setup-disk to use grub-mkconfig 2019-01-17 19:45:15 I don't think that does grub supports ARM boxes, but syslinux doesn't too 2019-01-17 19:45:32 what does arm use for efi then? 2019-01-17 19:45:39 i think arm is supported for grub 2019-01-17 19:46:02 coreboot and something on top of it 2019-01-17 19:46:26 on ARM64, arm32 uses mostly u-boot 2019-01-17 19:46:55 and some arm64 uses also u-boot 2019-01-17 19:48:00 but i presume you are talking about x86*, then it is not important. most will boot with either syslinux or grub 2019-01-17 19:48:19 i thought grub works on arm 2019-01-17 19:48:49 maybe on some newest, but on most it doesn't 2019-01-17 19:49:35 would be nice, and i will have it installed already, for sure 2019-01-17 19:50:45 I've built different u-boot for different boxes and it is not comfortable to boot 2019-01-17 19:51:21 something like direct interaction with firmware variables if you want to change boot parameters 2019-01-17 19:52:47 although, novadays it have config similar to syslinux, and syntax is nearly same, even 'boot config' file is called extlinux.conf 2019-01-17 19:55:00 but menu is just numbers to select boot options, no boot parameters editing 2019-01-17 20:04:31 ncopa: any more thoughts on #9856? 2019-01-17 20:15:39 hatramatra: i guess we dont have much option then 2019-01-17 20:16:33 but i think i want wait with it til after v3.9 if possible 2019-01-17 20:22:34 ncopa: ok 2019-01-17 20:32:20 target version can be changed to 3.10 then 2019-01-17 20:46:34 mps, i think you refer to smaller embedded boards. Most aarch64 servers use EFI nowadays. 2019-01-17 20:47:20 At least the ones i used 2019-01-17 20:50:08 right, I have seen these boards, even removed EFI from one of them, but these are newer arm64 2019-01-17 20:59:34 i pushed grub change that will make grub generate the grub.cfg 2019-01-17 21:00:18 grub users may need edit /etc/default/grub 2019-01-17 21:00:48 that's how it usually works :) 2019-01-17 21:01:04 thats how it works in alpine too now :) 2019-01-17 21:01:18 I'll take a look at it next time I'm doing maintenance on the specific box I have in mind at work 2019-01-17 21:01:22 would be nice with some help to test it 2019-01-17 21:01:23 should I put comments here? 2019-01-17 21:01:36 if you find bugs please report on bugs.a.o 2019-01-17 21:01:39 in case im not here 2019-01-17 21:01:42 ok 2019-01-17 21:01:51 how about positive ones?~ 2019-01-17 21:02:04 publish them here :) 2019-01-17 21:02:18 :) 2019-01-17 21:02:35 now that i expect positive feedback i will make sure to check this channel often ;) 2019-01-17 21:02:49 hey, positive feedback is important - keeps you going ^^ 2019-01-17 21:02:57 +1 2019-01-17 21:03:11 speaking of positive comments, ncopa - I had an interesting idea for a sticker, so I went ahead and made a design for it, but it does use the verbatim alpine logo (the svg form from alpinelinux.org), and I want permission to print and distribute them 2019-01-17 21:03:30 (I don't know if there's any legal reasoning or whatever, but even if there wasn't it'd be a basic respect thing) 2019-01-17 21:03:52 the author is a friend of mine 2019-01-17 21:03:55 the design is a fancy version of the logo, plus the text "I actually BOOT it" (in reference to the fact that a lot of our users run alpine in containers, which don't boot by definition) 2019-01-17 21:04:23 i think i asked him earlier about copyright of the logo 2019-01-17 21:04:25 ok, could I contact them (e.g by email?), or is it perhaps licensed CC or similar? 2019-01-17 21:04:27 aha! 2019-01-17 21:04:33 but i dont remember the answer 2019-01-17 21:04:35 let me search 2019-01-17 21:04:37 tyty 2019-01-17 21:09:22 http://lists.alpinelinux.org/alpine-devel/5719.html 2019-01-17 21:09:57 i also found the email, but it was a question of original svg and what font used etc 2019-01-17 21:11:17 mhm, do you think it'd be appropriate for me to contact him? 2019-01-17 21:11:53 stickers certainly count as print material, but it's impractical to fit "The Alpine logo is included by permission of the Alpine Linux Project." on a small piece of print area like that 2019-01-17 21:12:15 SpaceToast: i think you can just create it. other people have done so earlier 2019-01-17 21:12:26 technically, "communicating software compatibility with Alpine in a way that is not misleading"... 2019-01-17 21:12:29 Alpine can definitely boot :) 2019-01-17 21:12:46 but i can give you the email to Tobias, the creator, if you want be sure 2019-01-17 21:12:52 yes please :) 2019-01-17 21:13:43 it's certainly looking like it'd be fine based on the above email, but being sure is good, and making sure the copyright owner is fine with it (even if everything is otherwise fine) is something I strive for 2019-01-17 21:14:03 (e.g I certainly expect to be poked if someone wants to report my blog contents verbatim, even though they actually are creative commons) 2019-01-17 21:21:19 you got the email in PM. need to go now 2019-01-17 21:23:58 \o thanks again :) 2019-01-17 21:25:40 clandmeter: back to crystal, I actually built crystal without bootstrap tarball at the beginning but didn't want to make big changes in APKBUILD because I'm not maintaner. 2019-01-17 22:07:40 https://www.reddit.com/r/netsec/comments/agwm4h/hardenedalpine_hardened_alpine_docker_image/ ← wow, wtf. 2019-01-17 22:07:41 [REDDIT] hardened-alpine : hardened alpine Docker image (https://github.com/HazCod/hardened-alpine) to r/netsec | 4 points (59.0%) | 10 comments | Posted by nindustries | Created at 2019-01-17 - 10:54:47 2019-01-17 22:09:05 <_ikke_> lol 2019-01-17 22:09:09 <_ikke_> didn't know it did that 2019-01-17 22:09:22 <_ikke_> ah, yes, I knew 2019-01-17 22:09:27 <_ikke_> thought it automatically posted that 2019-01-17 22:11:02 do people not like... know how containers work? 2019-01-17 22:12:19 also lol "let's remove sysctl things but add a 30mb proprietary `scanner' blob" 2019-01-17 22:12:46 but 2019-01-17 22:12:48 but! 2019-01-17 22:12:55 less users in /etc/passwd is more secure 2019-01-17 22:13:14 jwh: so what you're saying is... run everything as root? :) 2019-01-17 22:13:21 1 user is less than 2, after all :D 2019-01-17 22:13:45 yes, you should definitely do that 2019-01-17 22:13:53 HARDENED distro - single user mode! 2019-01-17 22:14:13 :D 2019-01-17 22:14:45 I just ordered an odroid-hc1, already regretting it 2019-01-17 22:14:46 everyone should just run haiku and stop worrying, our proprietary closed source data-collecting scanner will help you out! 2019-01-17 22:15:08 think I should have gone for a c2 2019-01-17 22:15:31 while I'm sure we could do a better job with CVEs (as could literally every project out there), I really doubt this is the erm.. correct approach 2019-01-17 22:15:34 disk tray for the hc1 is convenient, but its cpu is bleh 2019-01-17 22:15:42 heh, yeah 2019-01-17 22:16:16 lol he/they removed the repo 2019-01-17 22:16:26 entire user, actually 2019-01-17 22:16:36 really? I was just looking at it... 2019-01-17 22:16:46 or did I do it wrong 2019-01-17 22:16:52 https://bitbucket.org/scalock/server/scannercli/scanner.contactCyberCenter 2019-01-17 22:16:54 https://github.com/HazCod/hardened-alpine - still up for me 2019-01-17 22:17:01 ah, the other thing 2019-01-17 22:17:04 yeah 2019-01-17 22:17:08 its gone, as has the user seemingly 2019-01-18 03:16:01 wow wow this hardened alpine tho 2019-01-18 03:16:23 removing chown altogether is next level 2019-01-18 03:21:20 it's so secure, your app has to run as root now :D 2019-01-18 09:13:00 ncopa, libvirt 5 has been released. Shall we upgrade it and ship with alpine 3.9 or is better to wait? 2019-01-18 09:13:14 clandmeter, ^ 2019-01-18 09:20:55 i would prefer to wait 2019-01-18 09:21:12 i think ncopa is ready to do release 2019-01-18 09:23:33 sounds good clandmeter 2019-01-18 09:45:11 while we have good fun on account of hardened alpine, what is the general opinion on file permissions of apkovl file in run-from-ram installations? :-) 2019-01-18 09:46:19 <_ikke_> Not sure if it breaks anything, I but I guess it should only be readable by root 2019-01-18 09:49:36 it isn't at the moment 2019-01-18 09:50:24 all root-only accessible sensitive files from /etc can be read from the apkovl file by anyone 2019-01-18 09:52:00 <_ikke_> yes, I realized since you (or someone else) last asked this question 2019-01-18 09:54:30 submit a patch to lbu 2019-01-18 09:55:24 <_ikke_> It would need to know what FS it is 2019-01-18 09:55:40 <_ikke_> for *fat* it would not be possible 2019-01-18 09:55:40 i think we already have checks? 2019-01-18 09:58:24 if mounted with dmask=0027 and fmask=0137, we should be OK 2019-01-18 10:00:11 clandmeter: is that lbu thing? isn't lbu mounting/remounting based on the entry in /etc/fstab? 2019-01-18 10:01:18 <_ikke_> hatramatra: lbu is creating the apkovl file 2019-01-18 10:01:45 sure, but can't set the file permissions if stored at vfat filesystem 2019-01-18 10:02:36 umask at gneration time should be sufficient 2019-01-18 10:02:41 by default, vfat (in /media/usb) is mounted with dmask=0022 and fmask=0022 2019-01-18 10:03:15 so it depends on how the filesystem is mounted ... i need to figure out where that is happening 2019-01-18 10:04:25 i set dmask/fmask in /etc/fstab, but after reboot i was back to dmask,fmask=0022 ... so whatever process is mounting /media/usb doesn't bother about /etc/fstab ... 2019-01-18 10:04:39 ... and rightly so. apkovl hasn't been unpacked yet 2019-01-18 10:04:55 i guess its nlplug-findfs, then 2019-01-18 10:05:04 part of mkinitfs pkg 2019-01-18 10:05:23 AinNero: thanks, i will look into it 2019-01-18 12:52:10 this is interesting 2019-01-18 12:52:10 https://patch-diff.githubusercontent.com/raw/alpinelinux/aports/pull/6073.patch 2019-01-18 12:52:28 https://github.com/alpinelinux/aports/pull/6073 2019-01-18 12:55:25 aaaaahhh, i've ive know they work with Alpine i'd apply for the IOSB 2019-01-18 12:55:54 this also has another usecase 2019-01-18 12:56:17 if you have a iso on the usb stick, its mounted directly, not as partition 2019-01-18 12:56:32 blocking other partitions, rendering the whole stick r/o 2019-01-18 12:56:43 with this patch, its possible to umount the boot media 2019-01-18 12:58:36 but im not satisified with the implementation 2019-01-18 15:06:16 fcolista: lets wait with major upgrade 2019-01-18 15:06:42 ncopa, yeah. Thanks, fully agree. 2019-01-18 15:07:52 hatramatra: good catch! i think it would be nice to fix that if possible 2019-01-18 15:08:33 the hardened-alpine docker image is sort of fun too 2019-01-18 15:09:06 not sure if we could clean up some of those things ourselves 2019-01-18 15:09:27 virtually nothing that's done in it is erm... actually needed 2019-01-18 15:09:46 shouldnt be needed 2019-01-18 15:09:49 if you remove all the extranious things, you're basically left with FROM alpine:3.8 :) 2019-01-18 15:10:04 and if you go through with all of it, you might as well just have a custom FROM scratch image 2019-01-18 15:10:09 also the tools they are removing are still available via /bin/busybox tool 2019-01-18 15:10:24 aye, and they remove things like chown, but then try to call them afterwards 2019-01-18 15:10:33 so you can do `/bin/busybox chown` 2019-01-18 15:11:17 i wonder if we should in our check() function check for world writable files or dirs though 2019-01-18 15:11:48 lots of dirs are world-writable by design, such as /tmp 2019-01-18 15:12:04 yeah, those needs to be excluded 2019-01-18 15:12:07 not sure if there are any legitimate cases within packages, but I wouldn't jump to conclusions 2019-01-18 15:12:25 i mean, what they do is to make sure we havent missed anything 2019-01-18 15:12:44 like unintentionally made /usr/bin/ world writable or similar 2019-01-18 15:13:09 i guess we could add tests for that in the official docker image 2019-01-18 15:13:29 because if we do that kind of mistakes, we want be notified and fix it, instead of silently fix it 2019-01-18 15:13:50 i also think the APP_USER idea is sort of nice 2019-01-18 15:14:12 to encourage users run as non-root 2019-01-18 15:14:26 currently its inconveinent to run non-root and very convenient to run as root 2019-01-18 15:15:19 are you sure? I don't have any difficulties performing adduser 2019-01-18 15:15:33 though in most cases `apk add app_name` is more than enough :) 2019-01-18 15:16:15 no, im not sure :) 2019-01-18 15:16:29 also, I'm not sure there's any real issue in running as root within a container 2019-01-18 15:16:45 because both root and UID 1000 translate to a single non-root user outside of docker, when done right 2019-01-18 15:17:23 in any case, the binary blob/scanner thing is sort of ... hm... 2019-01-18 15:17:35 highly questionable :) 2019-01-18 15:17:43 yup 2019-01-18 15:17:44 not only that, but it isn't always removed, like they claim 2019-01-18 15:18:09 (only removed if the scanner returns 0, which I have doubts on always being the case) 2019-01-18 15:19:06 I also looked into the author - they seem to be a security enthusiast from Belgium that's worked with government agencies and has a diploma in security; but looking at most of their work that makes me worried for Belgium :( 2019-01-18 15:19:48 (for example, they wrote a crypto wrapper that wraps around a crypto wrapper for golang, but omitted salts, and didn't even mention that they exist, so anyone using it might not think to salt their sensitive input (this is meant for passwords), and thus make themselves vulnerable) 2019-01-18 15:20:30 in short, I think we're better off improving what we have, rather than chasing after this... strange concept 2019-01-18 15:21:37 agree 2019-01-18 15:22:08 AinNero: you are not happy with the implementation of https://github.com/alpinelinux/aports/pull/6073? 2019-01-18 15:22:15 im not sure i like it either 2019-01-18 15:22:37 like, one should not grep like that through proc/cmdline, better use the KOPT_ mechanism 2019-01-18 15:22:56 and it copies data from the modloop without umounting it afterwards 2019-01-18 15:23:18 it is possible to solve the problem with overlayfs too 2019-01-18 15:23:29 instead of copying 200MB data to tmpfs 2019-01-18 15:23:33 the problem this person has, yes 2019-01-18 15:24:00 personally i'd like to umount the boot media, and currently i copy the modloop manually for that 2019-01-18 15:24:33 it is possible to unmount the boot media after everything is booted 2019-01-18 15:24:47 but then you no longer have hotplugging of new devices 2019-01-18 15:25:45 i copied the modloop to tmpfs and mounted it from there 2019-01-18 15:25:52 so i still have modules 2019-01-18 15:26:07 AinNero: feel free to comment on that PR 2019-01-18 15:26:25 copying modloop sounds like waste of ram 2019-01-18 15:26:45 later, still at daywork and need to take care of family afterwards 2019-01-18 15:26:51 the only benefit i see with that is faster copy (less data to copy, due to compression) 2019-01-18 15:27:46 yeah, family has prio. no stress with this 2019-01-18 15:29:29 ok, so what are the blockers for rc2 now? 2019-01-18 15:29:42 i think the only thing i want test is the grub thing 2019-01-18 15:31:05 and we need write release notes 2019-01-18 15:31:41 if grub testing is a blocker I'll try to do it this evening (at least in a VM, w/o UEFI) 2019-01-18 15:32:48 i did some testing yesterday, and i *think* it will work 2019-01-18 15:32:58 Hi, it seems clang-5.0.2 compiler is not usable on armhf. 2019-01-18 15:33:26 clang-5.0: error: unable to execute command: Segmentation fault 2019-01-18 15:33:41 the only thing was that it apparently switched to vga mode, so the qemu -curses gave me lemons 2019-01-18 15:33:58 terra: can you please file a bug on bugs.alpinelinux.org with as many details as possible? 2019-01-18 15:34:30 https://build.alpinelinux.org/buildlogs/build-edge-armhf/testing/mame/mame-0.205-r0.log 2019-01-18 15:34:43 https://build.alpinelinux.org/buildlogs/build-edge-armhf/testing/advancemame/advancemame-3.8-r1.log 2019-01-18 15:34:48 ncopa: ok 2019-01-18 15:34:50 i think i saw the segfault at some point, but i thought it was fixed? 2019-01-18 15:34:54 i dont remember the details 2019-01-18 15:40:15 ncopa: what you intend to release, stable release v3.9 or v3.9_rc2 2019-01-18 15:40:57 > 15:29 <@ncopa> ok, so what are the blockers for rc2 now? 2019-01-18 15:41:17 AinNero: ah, I see, thanks 2019-01-18 15:42:09 ACTION last few days my eyes are tired 2019-01-18 16:38:11 we have a problem with grub and kernel install 2019-01-18 16:38:24 problem is that triggers are run in wrong order 2019-01-18 16:38:32 linux-vanilla trigger needs to run first 2019-01-18 18:13:22 ncopa, setup-bootable -u seems broken 2019-01-18 18:13:59 I couldn't get it working 2019-01-18 19:51:22 clandmeter: what error do you get? 2019-01-18 19:51:59 cannot find syslinux.cfg or similar 2019-01-18 19:52:10 i used a v3.9 iso 2019-01-18 19:52:30 hum 2019-01-18 19:53:00 what arch? 2019-01-18 19:53:01 i looked in the iso, and its fine 2019-01-18 19:53:13 the -u means update 2019-01-18 19:53:19 x86_64 2019-01-18 19:53:27 does the syslinux.cfg exist on the target? 2019-01-18 19:53:34 yes 2019-01-18 19:53:42 it booted from it 2019-01-18 20:08:12 terra: regarding clang on armhf, could it be low memory. I have similar problems building big packages on armv7 with 4GB of ram, dmesg shows "out of memory" 2019-01-18 20:16:41 ok, here comes 3.9.0 rc2 2019-01-18 20:18:49 nice :) 2019-01-18 20:19:23 i am specifically interested in testing grub 2019-01-18 20:19:42 before start setup-alpine do: export BOOTLOADER=grub 2019-01-18 20:20:10 so, syslinux is still default? 2019-01-18 20:20:11 i just tested it in virtualbox and it worked there 2019-01-18 20:20:15 yes 2019-01-18 20:20:27 nice, i prefer syslinux :) 2019-01-18 20:21:06 i sorta prefer syslinux too, but it does not work with uefi 2019-01-18 20:21:14 nor on non x86* 2019-01-18 20:21:26 yes, understand 2019-01-18 20:21:57 syslinux works fine on my four x86* boxes 2019-01-18 20:22:12 i havent tested netboot images either 2019-01-18 20:22:26 although not newer models 2019-01-18 20:23:32 I don't have time to test images, but did some 'apk upgrade' and didn't noticed serious problems 2019-01-18 20:24:06 only had to manually remove libressl on one box 2019-01-19 00:58:54 SpaceToast: i got an email from Tobias saying he want give us the rights for the alpine logo, and that he hope that we still like it :) 2019-01-19 01:20:13 ncopa: oh! I was going to write the email to him tomorrow evening, so that's great :D 2019-01-19 01:20:28 in that case, I suppose it's you I have to ask permission :) 2019-01-19 01:23:34 (in case my opinion is worth anything by the way, I think it's a great logo :) ) 2019-01-19 01:24:04 i guess you can send him an email with a slingle line saying that ;) 2019-01-19 01:24:58 and i dont think you need ask for permission as long as it complies with the email mentioned earlier 2019-01-19 01:25:01 if you think he'd like that, I will; though I normally refrain from sending emails like that 2019-01-19 01:25:52 well, as far as I can tell, Alpine is definitely capable of booting :) I did note that I like asking anyways though 2019-01-19 01:26:02 i think its ok as long as he does not need to respond 2019-01-19 01:26:17 that makes sense 2019-01-19 01:28:00 we should probably put the guidelines on how to use the logo some place official too 2019-01-19 01:28:47 it can probably go with the FAQ we want to add to https://alpinelinux.org 2019-01-19 01:29:02 since, at least according to the email, it's a relatively common question 2019-01-19 01:30:37 good idea. i like 2019-01-19 01:31:02 ok, its time for me to sleep. have a nice weekend! 2019-01-19 01:32:05 \o you too 2019-01-19 02:16:35 spaces or tabs in APKBUILD? hmm 2019-01-19 02:20:46 <[[sroracle]]> Tabs 2019-01-19 03:34:22 does anyone know how to retry build noarch ? i created metapackage, but seems only 1 arch went to aport (armv7) 2019-01-19 11:47:35 i think im bumping into a fortify issue. any help appreciated https://tpaste.us/BoMk 2019-01-19 11:54:12 ncopa: in the rush to build rust I forgot to put crystal static tarball in my home dir on the aarch64 lxc container. they are in the /home/mps/crystal_static 2019-01-19 17:20:14 mps: a crystal ball? :o 2019-01-19 17:31:01 bleb: crystal-lang 2019-01-19 17:32:01 not a ball, more like a cone 2019-01-19 19:05:02 crystal tarball tho 2019-01-19 20:59:12 how far out is Alpine 3.9 still? 2019-01-19 21:02:57 rc2 is out right now, feel free to test and report back :) 2019-01-19 21:12:10 topic still shows 'release 3.9.0_r1 is out!' 2019-01-19 21:12:39 someone should probably fix that then :) 2019-01-19 21:13:22 <_ikke_> ^^ 2019-01-19 21:13:29 :D 2019-01-19 21:15:52 btw, I upgraded some machines, x86_64, aarch64 and armv7. till now everything is fine 2019-01-19 21:17:19 only missing thing is one of mainstream browsers, firefox or chromium on arm's 2019-01-19 21:18:20 maybe that should be written in release notes for users of these arches 2019-01-19 22:28:42 well there's always Dillo :P 2019-01-19 22:31:12 Firefox is not on arm because of Rust I guess (I can't remember why Rust isn't on arm though), but why is Chromium not available? 2019-01-19 22:46:15 PureTryOut[m]: chromium is really big application (over 600MB compressed tarball of the source) and have bugs for musl on arm cpus 2019-01-19 22:46:51 so just not worth fixing I guess? 2019-01-19 22:47:16 I tried, but after who know what number of bugs just gave up 2019-01-19 22:49:11 firefox-esr couldn't be made avaliable because of rust is not yet bootstraped to musl on aarch64, armv7 and armhf 2019-01-19 22:51:01 although I managed to build firefox-esr (60.x) for aarch64 and armv7 using some third party rust binaries but apk couldn't be added to official repos because couldn't be rebuilt by official builders 2019-01-19 22:55:28 maybe I should post guide how one can do that yourself if have enough cpu power and RAM, 8GB is needed 2019-01-19 22:56:38 new firefox-esr is faster and more responsive than the old, 52.x iirc 2019-01-19 22:56:56 but Rust is coming to arm right? 2019-01-19 22:57:47 I'm working on it, but not sure when will it be built 2019-01-19 22:58:23 s/it be/it will be/ 2019-01-19 22:58:23 mps meant to say: I'm working on it, but not sure when will it will be built 2019-01-19 22:59:29 that sentence didn't really improve lol 2019-01-19 22:59:37 but good work, looking forward to it 2019-01-19 22:59:40 noticed that Adelie Linux also released beta without rust on aarch64 and armv7, so no firefox there also 2019-01-19 23:00:00 PureTryOut[m]: I'm not native speaker 2019-01-19 23:02:21 bootsraping compiler is not easy task 2019-01-19 23:02:39 I can imagine! 2019-01-19 23:04:51 good thing is that it is possible :) 2019-01-19 23:09:46 Awesome haha 2019-01-19 23:09:52 Would be a damn shame if it wasn't 2019-01-19 23:10:02 does anyone even use alpine with desktop environments? i'm just trying to understand the need in browser in alpine 2019-01-19 23:11:09 <_ikke_> dimon222[m]: yes, people do use it for desktops 2019-01-19 23:11:23 PureTryOut[m]: I reached to point to build binaries (cargo, rustc, rustdoc ...) but libs are problem 2019-01-19 23:12:09 and, I'm new to rust, must admit 2019-01-19 23:13:43 I'm planning on installing Alpine on a laptop, and will use Plasma on it, so yes there is a need 😜 2019-01-19 23:14:44 PureTryOut[m]: are you one of pmOS developers 2019-01-19 23:14:54 yes 2019-01-19 23:16:03 you do a good work, I'm thinking to try it on one my asus phonepad 2019-01-19 23:16:28 thanks! and yes you should 2019-01-19 23:16:42 it needs quite a few quality of life improvements and new packages to be useful for me, to be honest 2019-01-19 23:16:47 I tried putting it on my laptop recently, but so many things were awkward, and I don't have the time to try to fix all of them right now 2019-01-19 23:16:49 anyway, that's a topic for #alpine-linux, I'd say 2019-01-19 23:16:54 plasma being missing is definitely a big one 2019-01-19 23:17:04 once the docs are done I might give it a second spin :) 2019-01-19 23:50:44 I agree with Plasma missing. that's why for now I'm just taking the packaging we use for KDE on postmarketOS and putting them in a private repository, till team maintainership in Alpine is a thing and we can upstream KDE 2019-01-20 00:25:49 are there any examples of APKBUILD for Go packages? trying to make new aport but cant find anything that doesn't involve direct usage of prebuilt Go docker image 2019-01-20 01:18:11 dimon222 there's lots of go packages but most of go apps require bulder image (compiler...) 2019-01-20 01:19:20 https://pkgs.alpinelinux.org/packages?name=go-*&branch=edge 2019-01-20 01:26:56 i actually tried to replicate similar environment in APKBUILD as golang image has, but still got confused by fact that even after installing apk "go" from alpine, it downloads tarball? 2019-01-20 01:26:57 https://github.com/docker-library/golang/blob/304174c7c604cbb7dd445ab58f479efe98f3bbf4/1.11/alpine3.8/Dockerfile#L40 2019-01-20 01:29:01 curious what components actual "go" package is missing that they have to still download tarball. govendor? 2019-01-20 04:12:05 hm, I added i386-efi to grub, but perhaps it should be part of the -efi package? 2019-01-20 05:29:36 eh, gopath is evil 2019-01-20 11:58:25 The current rust package depends on llvm-libunwind but it looks like the binaries it produces all depend upon the unwind routines from libgcc. AFAICT that dependency should be dropped, does anyone online know why that dependency is there? (I'm a bit novice to rust so uncertain if there is something I'm missing somewhere) 2019-01-20 12:04:07 emolitor: dependencies to llvm-libunwind is removed by patch 2019-01-20 12:06:24 mps: a pending patch? the current version on edge still pulls in llvm-libunwind as a dependency 2019-01-20 12:06:39 look in: community/rust/musl-fix-linux_musl_base.patch 2019-01-20 12:07:22 llvm-libunwind-dev is needed during build phase 2019-01-20 12:08:26 looking at the APKBUILD shouldn't it be a makedepends and not depends? 2019-01-20 12:10:02 probably, didn't looked. actually, llvm-libunwind-dev could be removed now probably but I didn't tried 2019-01-20 12:11:00 K, I'm testing now without it at all. Looking at the libunwind source it only uses llvm-libunwind when building crt-static. In theory it shouldn't be needed at all 2019-01-20 12:11:23 (looking at the rust libunwind source in lib.rs) 2019-01-20 12:12:37 Is it too late to drop the dependency for 3.9? It would simplify upgrading rust, llvm, etc greatly. 2019-01-20 12:13:03 I noticed that rust APKBUILD need some cleaning and fixes but didn't wanted to send patches till the new stable is released 2019-01-20 12:14:17 yes, too late. I already prepared upgrade to llvm, lld and clang to 6, but waiting till release of the stable 2019-01-20 12:14:26 K 2019-01-20 12:14:37 'K'? 2019-01-20 12:14:59 Ok, that makes sense. 2019-01-20 12:16:23 main problem with rust in Alpine is that it is x86_64 only 2019-01-20 12:17:03 we need it for some other arch's, aarch64, armv7 and ppc64 2019-01-20 12:18:05 and my impression is that upstream ignores musl on these arch's 2019-01-20 12:20:10 Yes, I took a stab at aarch64 and it is unpleasent to try to get to build. 2019-01-20 12:22:06 OT, but from the clean lang looks like rust becoming too big and cumbersome 2019-01-20 12:24:04 Seems like all new languages start small but struggle to stay small. 2019-01-20 12:24:35 If I get anywhere with rust on aarch64 I'll surface some patches. 2019-01-20 12:24:54 The trouble is bootstrapping it without using a prebuilt binary. 2019-01-20 12:30:45 I built cargo, rustc, rustdoc (binaries) but failed at libraries 2019-01-20 12:33:14 and i do that in my free time, so not going fast as i would like 2019-01-20 12:36:35 rust seems happy without the dependency. I'll rebase my mesa and clang changes on top of the llvm6/7 changes once they have landed but this should unblock me for now. 2019-01-20 12:37:44 OT, understand about the time commitment. I really only have weekend mornings unless something breaks at work. 2019-01-20 12:43:59 I'll post patches for llvm and clang after stable released. not sure is it pk to go straight to 7 or first to 6 2019-01-20 12:44:20 s/pk/ok/ 2019-01-20 12:44:21 mps meant to say: I'll post patches for llvm and clang after stable released. not sure is it ok to go straight to 7 or first to 6 2019-01-20 16:36:38 https://dl-cdn.alpinelinux.org serves *.fastly.{com,net} certs; is this intentional? 2019-01-20 16:37:51 yes 2019-01-20 16:46:55 <_ikke_> Thalheim: fastly is the cdn, so it would make a lot of sense :-) 2019-01-20 16:47:19 <_ikke_> If you want it to be trusted, you need to use the prober domain 2019-01-20 16:47:23 <_ikke_> proper 2019-01-20 16:48:38 <_ikke_> Thalheim: https://alpine.global.ssl.fastly.net/ 2019-01-20 16:54:18 _ikke_: naturally. I just didn't realize that the branding value of 'dl-*.alpinelinux.org' was worth the confusion for anyone wanting HTTPS 2019-01-20 16:57:43 or dont use https 2019-01-20 16:57:52 we do not advertise https for fastly 2019-01-20 17:07:10 why not use HTTPS? I would expect it to be the default for a security-oriented Linux distro, but even the HTTPS download page does not offer any HTTPS links. 2019-01-20 17:07:57 technically speaking, the contents of the packages is verified regardless of the transport (it's all signed) 2019-01-20 17:08:35 the reasoning is generally the same that debian uses - no reason to give people a false sense of security 2019-01-20 17:08:38 SpaceToast, there was an url recently regarding this topic 2019-01-20 17:08:47 which explained it nicely 2019-01-20 17:08:48 while I disagree, it doesn't matter quite as much as one might think 2019-01-20 17:08:58 might also be part of reason - ca-certificates is not part of pre-installed alpine package 2019-01-20 17:09:01 clandmeter: the one about apt, yeah, that I disagreed with and just mentioned ;) 2019-01-20 17:09:04 that doesn't ensure that the ISO/tarballs are correct, if the user doesn't verify against the signature 2019-01-20 17:09:21 Thalheim, you can verify them (and you should) 2019-01-20 17:09:33 we provide the pgp key on our website 2019-01-20 17:09:35 TLS doesn't guarantee that the file is correct 2019-01-20 17:09:50 TLS only guarantees that the server is what it claims to be, and that nothing compromised the files during transport 2019-01-20 17:10:13 clandmeter: I agree (and do) just there's nothing stopping an organization from serving their own versions of both the iso/tarball and sig 2019-01-20 17:10:28 we do 2019-01-20 17:10:38 just not via fastly 2019-01-20 17:10:50 or you can use the url _ikke_ posted 2019-01-20 17:11:05 you can pick any mirror from mirrors.a.o 2019-01-20 17:12:01 btw, this is not a development topic 2019-01-20 17:12:36 SpaceToast, do you remeber the url to that apt page? 2019-01-20 17:12:47 https://whydoesaptnotusehttps.com/ 2019-01-20 17:13:36 some parts of that are kind of outdated (e.g due to LE being thing), but in the end nothing's stopping you from using a TLS mirror :) 2019-01-20 17:26:50 at the expense of (1) mirror availability, (2) significantly increased ping times, (3) reduced bandwidth -- but these things are more "nice to have" -- and this is, as you said, off-topic. Is there a more appropriate venue for this type of discussion? 2019-01-20 17:28:18 no thoughts on my grub dilemma? :D 2019-01-20 17:35:39 Thalheim, yes #alpine-linux or #alpine-infra 2019-01-20 17:39:47 <_ikke_> does the apk index have a ttl to mitigate replay attacks? 2019-01-20 17:41:44 <_ikke_> "jwh │ hm, I added i386-efi to grub, but perhaps it should be part of the -efi package?" 2019-01-20 17:44:17 yeah 2019-01-20 17:44:44 I can't seem to actually use i386-efi as a subpackage, so it had to be i386_efi which is just ugly 2019-01-20 17:44:57 problem is defining i386-efi() I think 2019-01-20 17:45:29 but also the -efi subpackage should probably provide both 32 and 64bit 2019-01-20 17:47:07 I know 32bit uefi isnt that common, but its still useful 2019-01-20 17:48:04 clandmeter: thanks; didn't know about -infra 2019-01-20 17:53:06 SpaceToast, thx for the link 2019-01-20 17:53:39 nw :) 2019-01-20 18:24:23 interesting, tho didn't find the 1 use case i can think of. If i have custom package with enterprise software that was bought for $$$ but not available on official repos, http will add risk of someone stealing it, no? 2019-01-20 18:26:14 you can make your own mirrors go over https, proprietary software that could be "stolen" isn't going in the mainline repos anyway 2019-01-20 20:09:03 <_ikke_> What can cause /dev/tty to not be available for a process? 2019-01-20 20:09:42 <_ikke_> IOError: [Errno 6] No such device or address: '/dev/tty' 2019-01-20 20:12:52 _ikke_: is /dev/tty actually there? 2019-01-20 20:13:14 <_ikke_> SpaceToast: I suspect not 2019-01-20 20:13:20 have you tried creating it? :) 2019-01-20 20:13:34 usually, not being there is caused by it being deleted, or never having been created 2019-01-20 20:13:40 <_ikke_> No, It's a 3rd party program that tries to open it 2019-01-20 20:14:26 <_ikke_> Iirc it's associated with an interactive session 2019-01-20 20:14:42 <_ikke_> "Of course since crontab can run whilst you are not logged in, it doesn't have an associated teletype, so the linux device /dev/tty would not be available to gpg. 2019-01-20 20:14:44 <_ikke_> " 2019-01-20 20:15:48 /dev/tty is a node that refers to the controlling terminal of a process 2019-01-20 20:15:59 <_ikke_> yes 2019-01-20 20:16:04 if there is no terminal associated, then it wouldn't respond, but I'm not sure errno is what you'd expect in that scenario 2019-01-20 20:16:10 <_ikke_> And the alpine builders are not run with a terminal 2019-01-20 20:16:24 ah 2019-01-20 20:16:24 <_ikke_> out = open('/dev/tty', 'w') 2019-01-20 20:16:30 <_ikke_> That's what causes that error 2019-01-20 20:16:32 <_ikke_> (python) 2019-01-20 20:16:52 that's quite strange, stdout is still a thing, perhaps it's some curses bindings or something being built? 2019-01-21 03:08:24 with abuild -r, is there a way to avoid removing the built code from src? 2019-01-21 03:08:36 I need it to run gdb with a core dump from testing a package. 2019-01-21 03:09:03 mcr1: abuild -r is for actually building the package and copying it into the repo, you can specify individual steps instead of the -r 2019-01-21 03:09:24 so `abuild fetch unpack prepare build package` or something along those lines 2019-01-21 03:09:37 (you can actually read abuild(1)'s source to see what steps are in there, it's mostly just shell :) ) 2019-01-21 03:12:10 thanks. 2019-01-21 03:12:25 which step cleans up src/* ? so that I don't do it :-) 2019-01-21 03:12:54 I believe it's clean / cleansrc or something along those lines 2019-01-21 03:13:07 the current cleaning code is a bit of a mess (code duplication, etc) 2019-01-21 03:13:14 but you're not at risk of doing it by accident 2019-01-21 03:15:01 <[[sroracle]]> mcr1: you can also remove srcdir and/or pkgdir from CLEANUP / ERROR_CLEANUP in /etc/abuild.conf 2019-01-21 03:16:07 <[[sroracle]]> if you remove srcdir from ERROR_CLEANUP for example then it would prevent srcdir from being removed in the event of a failure; removing from CLEANUP prevents it from being removed even if it completes successfully 2019-01-21 05:29:19 <_ikke_> mcr1: you can use abuild -rk 2019-01-21 05:29:36 <_ikke_> mcr1: sorry, abuild -rK 2019-01-21 11:14:58 anyone knows how can I redirect the STDOUT of netcat on a file when is ran in a screen session? 2019-01-21 11:15:11 I'm running a remote dump. 2019-01-21 11:15:29 host a : tcpdump host | nc $IP $IPRT 2019-01-21 11:15:48 host b : nc -l $PORT 2019-01-21 11:16:02 *host b : nc -l $PORT >> /tmp/file 2019-01-21 11:16:39 if host b ran nc -l ... in a screen session, STDOUT is not redirected to /tmp/file 2019-01-21 11:16:44 it's busybox netcat 2019-01-21 11:25:18 fcolista: screen shouldn't have any influence on that 2019-01-21 11:25:34 mps it's in a detached mode 2019-01-21 11:26:00 that also shouldn't matter 2019-01-21 11:26:05 I've tried to attach the screen session 2019-01-21 11:26:18 and the output is printed on the screen rather than redirected to the file 2019-01-21 11:26:41 even if nc -l $PORT >> /tmp/file 2019-01-21 11:27:08 if i don't use screen, then /tmp/file is correctly filled 2019-01-21 11:27:17 so, appears that screen has a role. 2019-01-21 11:27:57 ah, maybe nc -l -p $PORT >> /tmp/file, i.e. add -p 2019-01-21 11:28:25 yes, -p specifies the port 2019-01-21 11:28:33 command is exactly: 2019-01-21 11:28:41 nc -l -p 3000 >> /tmp/file 2019-01-21 11:28:49 (on host b). 2019-01-21 11:28:52 On host a: 2019-01-21 11:29:17 tcpdump port 80 -w - | nc $IP_HOST_B 3000 2019-01-21 11:29:22 does it works without screen 2019-01-21 11:29:32 yes, it works.. 2019-01-21 11:29:59 wondering if the stdout in screen is somehow reset 2019-01-21 11:31:10 hmmm, strange, shouldn't be 2019-01-21 11:32:45 it shouldn't...but actually it does :) 2019-01-21 11:38:20 instead of tcpdump try 'echo something" to see is the problem nc or tcpdump 2019-01-21 11:42:53 fcolista: tried under screen, it works 2019-01-21 11:43:21 Which version of alpine 2019-01-21 11:43:22 ? 2019-01-21 11:44:06 on remote 3.8 (armhf) on local 3.9_rc2 (x86_64) 2019-01-21 11:44:28 tcpdump in screen on remote 2019-01-21 11:45:02 and nc on local is busybox applet 2019-01-21 11:45:25 and on remote, busybox too 2019-01-21 11:45:34 ok..this is alpine 3.1 (host a) and alpine 3.2 (host b) 2019-01-21 11:45:47 different subnets of course 2019-01-21 11:46:14 firewall, maybe? 2019-01-21 11:46:32 no, otherwise it woudldn't work even without screen 2019-01-21 11:46:52 bah, right :| 2019-01-21 11:47:16 how do you run screen ? 2019-01-21 11:47:22 screen -d -m $COMMAND ? 2019-01-21 11:47:50 no, in normal mode 2019-01-21 11:48:13 so you are attached to screen 2019-01-21 11:49:12 yes 2019-01-21 11:49:47 ok, now I detach by ctrl-a d, and still works 2019-01-21 11:50:36 if i run: 2019-01-21 11:50:36 screen nc -l -p 3000 >> test 2019-01-21 11:50:44 no, in detached mode does not work 2019-01-21 11:50:59 you are right 2019-01-21 11:51:01 so I'm attached to screen, i see output to the screen rather than in "test" file 2019-01-21 11:53:21 hm, this is not a devel topic... 2019-01-21 11:54:30 AinNero: right, we should move to #alpine-linux 2019-01-21 11:54:32 true AinNero 2019-01-21 13:43:08 i think we have some major issue with hibernation 2019-01-21 13:43:27 during early boot, nlplug-findfs is scanning around and mounting stuff 2019-01-21 13:43:39 after that, the resume= option is evaluated 2019-01-21 13:43:47 https://www.kernel.org/doc/Documentation/power/swsusp.txt 2019-01-21 13:44:05 > If you touch anything on disk between suspend and resume... 2019-01-21 13:44:07 > ...kiss your data goodbye. 2019-01-21 13:44:26 work by chance, but i see potential for data loss and angry users 2019-01-21 13:45:13 we could move the resume= code before nlplug-findfs, but that can't work with stuff like lvm anymore 2019-01-21 14:13:25 Hello there, do we have a wiki page about apk audit output ? 2019-01-21 14:38:29 stateless, do you have an idea regarding https://github.com/pybind/pybind11/issues/1650 2019-01-21 15:22:40 AinNero: nlplug-findfs does not need to mount anything if root= is specified 2019-01-21 15:23:08 ah, thats the reason why there is no resume support for diskless, then 2019-01-21 15:23:50 i guess its *a* reason to why there is not support for diskless :) 2019-01-21 15:24:35 you do need a swap partition for resume, which means you need a disk 2019-01-21 15:25:21 hm, some diskless usecases do have a disk 2019-01-21 15:25:31 like data mode 2019-01-21 15:26:16 but historically, we didnt support resume at all 2019-01-21 15:26:25 due to grsecurity kernel 2019-01-21 15:28:23 i havent verified that nlplug-findfs does not mount anything when root is specified. if it does, that could be fixed 2019-01-21 16:29:58 Is there any cron that can support year parameter? Like http://www.nncron.ru/help/EN/working/cron-format.htm -> Its good for triggering jobs only one time. (Yes, I know 'atd') 2019-01-21 17:51:29 i dunno if J0WI is here, but i think we should move pdns and pdns-recursor to main if want support those for more than 6 months: https://github.com/alpinelinux/aports/pull/5599 2019-01-21 18:43:30 at what order 'abuild prepare' in default_prepare call applies patches? Using order as they listed in source or random order? 2019-01-21 18:46:28 order listed in source 2019-01-21 18:48:44 thought so, but wasn't sure. thanks for clarification (and someone should add this to APKBUILD guide) 2019-01-21 19:46:17 anyone packaged ISC kea (new name for dhcp)? 2019-01-21 19:46:35 in testing/kea, I see now. 2019-01-21 19:46:52 are testing packages built into some other repo, or do I just have to build them myself? 2019-01-21 19:47:01 is there a FAQ on running my own package repo? 2019-01-21 19:47:49 libuv-v1.24.1 is available, can it be upgraded or nodejs needs 1.23.2 ? 2019-01-21 19:49:03 seems nice tool, https://github.com/thias/glim 2019-01-21 19:49:40 maybe some scripts borrowed for grub loading iso from usb 2019-01-21 19:55:27 fcolista, can you backport it? https://github.com/alpinelinux/aports/pull/6089#issuecomment-456148107 2019-01-21 19:59:24 also community/discount v2.2.4 if possible 2019-01-21 20:01:16 found another nice todo app, but is go lang, github.com/gammons/todolist 2019-01-21 20:09:37 clandmeter: not sure why that happens... will need to have a deeper look at it 2019-01-21 20:14:35 stateless, thx 2019-01-21 20:44:47 <_ikke_> clandmeter: I have a patch for redo, not sure if it correct or actually working though 2019-01-21 21:09:55 what is preferred doc format at, http://docs.alpinelinux.org (md,rst,asciidoc) ? 2019-01-21 21:10:20 vkrishn: asciidoc 2019-01-21 21:10:27 thanks 2019-01-21 23:22:33 ok, here comes 3.9.0 rc3 2019-01-21 23:33:02 i think the only thing needed for 3.9.0 release now is release notes? 2019-01-21 23:36:47 ncopa: good work, I'm running 3.9_rc2 on few boxes, till now everything is ok 2019-01-21 23:38:06 ncopa: I'm updating that one box I mentioned to 3.9.0 repos right now 2019-01-21 23:38:12 and looking at the grub changes 2019-01-21 23:38:56 it's successfully booting though, so I'll call that good enough for now :) 2019-01-21 23:43:06 great! 2019-01-21 23:51:42 hmm 2019-01-21 23:53:01 :q 2019-01-21 23:55:24 for some reason /etc/default/grub isn't getting through though 2019-01-21 23:56:10 oh nvm, it was just a typo :) 2019-01-21 23:56:35 ncopa: it might make sense to ship a default /etc/default/grub, with the same defaults that update-extlinux.conf used to have 2019-01-21 23:58:12 mostly just for modules 2019-01-22 00:33:40 ncopa: maybe topic in this channel needs update ;) 2019-01-22 03:07:23 eh, this pytest is going be in my nightmares 2019-01-22 07:00:49 andypost, to which version should I backport certbot 0.30.0? 2019-01-22 10:28:55 @fcolista 0.30.0 next is not released yet 2019-01-22 11:16:36 ncopa, new musl is out, but i guess it is a bit late in the RC process to update that? 2019-01-22 11:17:05 too late 2019-01-22 11:17:14 rc's are for bugfixes, usually 2019-01-22 11:17:31 if we would include the new musl, we need to do the testing all over again, i guess 2019-01-22 11:19:22 looking at change log there not too much stuff going on. but yes. might be better to wait release/branching. then upgrade edge. and if it's stable possibly backport. 2019-01-22 11:19:47 it fixes few nasty bugs though 2019-01-22 11:28:48 fabled: I prepared llvm, lld, clang upgrades just after rc1 released and talked with ncopa about sending patches, but after talking about it we agreed to wait for stable release and then upgrading to newer releases 2019-01-22 11:29:59 if we found nasty/serious bug we should to backport them anyway, or to try at least 2019-01-22 11:49:42 btw, we have main/llvm5, should we have separate main/llvm6 or just rename main/llvm5 to main/llvm6 2019-01-22 11:51:15 or just rename main/llvm5 to main/llvm, maybe? 2019-01-22 16:17:11 any rust expert here? Trying to bootstrap rust and have some questions about settings default build parameters 2019-01-22 16:18:49 mps, you can ping Shiz 2019-01-22 16:19:44 hullo 2019-01-22 16:22:28 Shiz: I bootstrapped rust to aarch64 with aarch64-alpine-linux-musl (and other arch'es) and made cargo, rust and rust-stdlib apk's 2019-01-22 16:23:55 \o 2019-01-22 16:24:03 I built it using foxkit rust, but didn't set library path properly in './configure', it works when I set LD_LIBRARY_PATH=/usr/lib/rustlib/aarch64-foxkit-linux-musl/lib 2019-01-22 16:25:08 this is first phase to get alpine in rust targets, next I plan to make it 'native' to alpine instead of foxkit 2019-01-22 16:26:15 question is, how to set library path in cargo and rustc to /usr/lib/rustlib/aarch64-foxkit-linux-musl/lib 2019-01-22 16:26:47 in rpath, maybe? 2019-01-22 16:39:08 hmm, looks like found it but will take few hours to confirm because build process is slow 2019-01-22 17:01:18 uh we used rpath in the other patches 2019-01-22 17:01:20 im pretty sure 2019-01-22 17:01:26 did you use alpine's patches? 2019-01-22 17:10:53 no, used adelie to bootstrap but just added alpine rpath patch and now rebuilding it 2019-01-22 17:14:18 I've got it to work but must set LD_LIBRARY_PATH and want to make it without that step 2019-01-22 17:35:15 hmm 2019-01-22 17:41:14 ~# clang 2019-01-22 17:41:16 Error relocating /usr/bin/clang: _ZSt11__once_call: symbol not found 2019-01-22 17:41:18 Error relocating /usr/bin/clang: _ZSt15__once_callable: symbol not found 2019-01-22 17:41:21 on v3.8 2019-01-22 17:44:41 mps: I'm pretty sure we got this fixed 2019-01-22 17:44:45 have you looked at the other patches? :p 2019-01-22 17:45:44 Shiz: clang? it is not needed for rust afaik 2019-01-22 17:47:55 no, t's something i noticed just now, unrelated to rust 2019-01-22 17:47:56 :p 2019-01-22 17:49:07 clang isn't needed for rust, but it's pretty directly related, llvm and all :) 2019-01-22 17:49:09 ah, ok 2019-01-22 17:50:25 llvm is needed aalthough rust have llvm bundled in src 2019-01-22 17:51:10 but, alpine removes this bundled llvm and uses installed one 2019-01-22 17:53:23 btw, CHOST, CBUILD and CTARGET in abuild, are they documented somewhere 2019-01-22 18:07:16 mps, https://wiki.gentoo.org/wiki/Embedded_Handbook/General/Introduction 2019-01-22 18:10:22 clandmeter: not much, but have simple example. abuild -h show CHOST AND CTARGET. thanks for link 2019-01-22 18:13:29 it clarifies these variables to me so now understand better. thanks again 2019-01-22 19:00:12 Hello, I'm trying to add a new aport. Created a pull request 10 days ago, no feedback so far. Is there any other step I should take? Can anyone help me move things along? Thx. 2019-01-22 19:01:17 <_ikke_> codingjourney: We're currently in a release process, so new aports have lower priority currently 2019-01-22 19:04:11 OK, I'll just wait then. 2019-01-23 06:14:15 Can we force grub-mkconfig to use partition UUID when creating grub.conf? My system became non-bootable after last changes. 2019-01-23 06:14:55 Because script generates grub.conf using /dev/sd* names which is very unreliable. 2019-01-23 06:18:00 I mean it could be "root=UUID=....." instead "root=/dev/sdc3" 2019-01-23 06:18:31 optionally labels please :D 2019-01-23 06:20:32 maybe updating grub.conf can be completely disabled by preference. 2019-01-23 06:25:32 codingjourney: 10 days is marginally small for new aport. I have a PR that waiting for 4 months. 2019-01-23 10:17:57 So I'm building packages and serve the repo on my personal network, and I got this while running wget in # setup-apkrepos: 2019-01-23 10:17:58 wget https://mirrors.alpinelinux.org/mirrors.txt : ssl_client: mirrors.alpinelinux.org: ocsp verify failed: ocsp response not current 2019-01-23 10:18:23 I never got this before doing custom repo 2019-01-23 10:21:20 tmhoang: I got similar wget ssl errors when localtime is not correctly set 2019-01-23 10:21:59 terra: I see. I just use UTC in previous step. Let me check again. 2019-01-23 10:22:33 try fırst: ntpd -n -q -p pool.ntp.org 2019-01-23 10:23:43 terra: I'm running in QEMU, host is set to CET, tried CET but still the problem. ntp is configured after that step (configuring mirrors) I guess. 2019-01-23 10:24:39 ntpd seems to do the job 2019-01-23 10:24:51 what "date" command says is true then? 2019-01-23 10:25:25 host shows CET, guest show UTC 2019-01-23 15:37:37 terra: I looked at the code in grub-mkconfig that does UUID and it depends on udev 2019-01-23 15:37:46 but i agree it would be better with uuid 2019-01-23 15:39:45 ncopa: grub-mkconfig "thinks" that it needs an initrd (correct) and udev for UUID, this is because it assumes that initrd will use /dev/disk/by-uuid to identify the correct disk(s) 2019-01-23 15:40:14 whether or not that reflects reality I'm not sure, but I have doubts (mostly towards the latter part) 2019-01-23 15:40:48 i think we may want create /dev/disk/by-uuid symlinks from mdev scripts 2019-01-23 15:40:55 i think it will fix it 2019-01-23 15:41:46 well, does our initrd/mount depend on /dev/disk/by-uuid to mount based on UUID? 2019-01-23 15:41:51 perhaps that check is simply wrong 2019-01-23 15:42:03 no, it does not 2019-01-23 15:42:49 is there any circumstance in which our initrd would fail to use UUID? (besides the obvious disk cloning scenario) 2019-01-23 15:43:05 no 2019-01-23 15:43:20 then 10_linux should probably default to using UUID at all times, without any checks :) 2019-01-23 15:43:36 unless GRUB_DISABLE_LINUX_UUID is true, of course 2019-01-23 15:43:44 (or UUID is missing from device) 2019-01-23 15:44:20 well, raid1 with two disks with same uuid may confuse our initramfs init 2019-01-23 15:44:45 i think that we set root manually in our setup-disk 2019-01-23 15:44:55 well, that's what GRUB_DISABLE_LINUX_UUID is for then :D 2019-01-23 15:45:07 yeah 2019-01-23 15:45:23 still, I think we can simply remove the test for /dev/disk/by-uuid, and add a check to make sure that the specified UUID exists (which is what it might have been there for to begin with) 2019-01-23 15:45:35 not sure how we'd do that, and work is keeping me busy right now though 2019-01-23 15:45:46 http://tpaste.us/65Kz 2019-01-23 15:45:54 i think that should be enough 2019-01-23 15:46:08 I agree 2019-01-23 15:46:16 it'd be nice to make sure that initrd can successfully mount the partition though 2019-01-23 15:47:23 i am pretty sure it can 2019-01-23 15:48:39 found another error in the trigger though 2019-01-23 16:31:16 ok, i tested the grub uuid thing in a vm 2019-01-23 16:31:38 http://tpaste.us/65Kz works 2019-01-23 16:32:15 nice :) 2019-01-23 16:57:09 ncopa: it didn't work for me: root=/dev/sdc3 2019-01-23 16:57:43 my current setup is a usb dongle with f2fs root 2019-01-23 17:01:23 I'm going out for now. 2019-01-23 18:27:28 clandmeter: what is the status of signed modloop? 2019-01-23 18:36:19 ok, here comes rc4 2019-01-23 18:37:35 <_ikke_> ACTION holds on 2019-01-23 19:47:36 bah 2019-01-23 19:47:58 grub-mkconfig generates this root for zfs: root=ZFS=tank/alpine/root 2019-01-23 19:48:20 isn't that standard? 2019-01-23 19:48:51 our initrafs expects: root=tank/alpine/root rootfstype=zfs 2019-01-23 19:49:08 ah 2019-01-23 19:49:19 i think we should fix our initramfs 2019-01-23 19:49:31 ACTION opens the crypt 2019-01-23 19:49:38 someone summoned me 2019-01-23 19:49:45 :) 2019-01-23 19:51:40 heck, i dont even know how to manualy mount a ZFS 2019-01-23 19:52:23 I'm far more familiar with btrfs, which works much more like a native fs 2019-01-23 19:52:34 my understanding is that zfs is more daemon-y/managed 2019-01-23 19:56:11 i assume it worked in the non-grub syntax, ncopa? 2019-01-23 19:56:50 yes, it works with: root=tank/alpine/root modules=sd-mod,zfs rootfstype=zfs quiet 2019-01-23 19:56:57 thats what i use on my laptop 2019-01-23 19:57:06 with gummiboot 2019-01-23 19:57:21 is this a bug to be fixed for 3.10 ? 2019-01-23 19:57:21 i should replace gummiboot with grub 2019-01-23 19:57:36 i think it would be good to have it fixed for 3.9 2019-01-23 19:57:40 but maybe 3.9.1 2019-01-23 19:57:47 i see 2019-01-23 19:59:47 ncopa: btw, rootfstype= implies modules= for that specific module 2019-01-23 20:00:25 see 873bda089bd05adbe74ad17cae063ee4bcbe25de 2019-01-23 20:01:06 hm. nevermind 2019-01-23 20:01:20 i might not be entirely sober, good night 2019-01-23 20:01:30 :) 2019-01-23 20:01:41 ACTION raises an eyebrow 2019-01-23 20:01:42 as long as you remember that's a thing when you wake up :D 2019-01-23 20:01:53 mount -t $rootfstype $root /sysroot 2019-01-23 20:01:59 is all that needs to work 2019-01-23 20:02:15 can anyone spot whats wrong with the haveged init file? 2019-01-23 20:02:16 :D 2019-01-23 20:02:25 jwh: can you paste it? 2019-01-23 20:02:29 I'm at work right now :) 2019-01-23 20:02:34 it has 'need net' 2019-01-23 20:02:53 o.O 2019-01-23 20:02:55 i think you can mount zfs that way with "legacy" mount support in zfs 2019-01-23 20:03:29 jwh: I bet it also isn't supervise-daemon based :) 2019-01-23 20:03:42 command_background 2019-01-23 20:03:45 :D 2019-01-23 20:04:09 thats ok though 2019-01-23 20:04:28 sigh... so zfs needs special case handling 2019-01-23 20:04:49 well, ideally everything that can be forced to foreground likely should (and should be based on supervise-daemon), since it's just more consistent (also see: daemontools) 2019-01-23 20:04:54 but that can wait :) 2019-01-23 20:05:47 AinNero: you were not completely off. init does: modprobe -a $(echo "$KOPT_modules $KOPT_rootfstype" | tr ',' ' ' ) loop squashfs 2> /dev/null 2019-01-23 20:06:41 yeah just picked the wrong commit while searching though history 2019-01-23 20:06:57 SpaceToast: yes, the more important thing is removing the bogus dependency 2019-01-23 20:07:00 this is probably just a matter of a case switch with setting rootfstype 2019-01-23 20:07:00 :) 2019-01-23 20:07:30 AinNero: well, the format that should be supported is root=ZFS=tank/alpine/root 2019-01-23 20:08:11 it's surprising to me that that's how it looks, though; on btrfs root is a standard partition/blockdevice, and you specify what exactly you're interested in in rootflags (e.g rootflags=subvol=/@) 2019-01-23 20:09:03 im surprised that nlplug-findfs does not choke on root= not resolving to any blockdevice 2019-01-23 20:09:19 this may work: http://tpaste.us/9gXZ 2019-01-23 20:09:26 sort of hackish though 2019-01-23 20:10:09 it's pretty hackish, but it might be useful for other things too (e.g in case we have trouble with root=UUID=foobar), or something new along these lines comes out 2019-01-23 20:11:05 ncopa: thats what i would have done 2019-01-23 20:11:46 the execution order of this withing the initramfs as well 2019-01-23 20:12:19 SpaceToast: root=UUID=.... already works 2019-01-23 20:12:19 i this we should document this special behavior in the manpage 2019-01-23 20:12:30 hum... 2019-01-23 20:12:48 ncopa: yes, I'm just giving an example - root=TAG=content seems like it's getting used more and more (e.g ZFS) 2019-01-23 20:13:03 which seems natural given LABEL and PARTUUID being a thing already 2019-01-23 20:13:23 im curious if grub-mkconfig uses other prefixes as well 2019-01-23 20:13:26 hum... 2019-01-23 20:13:27 so it's not unreasonable to be prepared to handle additional special cases 2019-01-23 20:13:35 i think it uses UUID= 2019-01-23 20:13:47 nothing else? 2019-01-23 20:13:53 dunno 2019-01-23 20:14:13 nlplug-findfs supports both UUID= and LABEL= 2019-01-23 20:14:28 i guess thats the proper place to fix the ZFS= thing too 2019-01-23 20:16:22 nah, ZFS= is semantically differenyt 2019-01-23 20:16:27 it does not resolve to a block device 2019-01-23 20:18:32 hm. 2019-01-23 20:18:40 i think i understand your point there 2019-01-23 20:19:16 i think that it currently works with zfs but that nlplug-findfs times out 2019-01-23 20:19:20 its sort of slow 2019-01-23 20:21:44 ncopa, i upgraded one of my servers to v3.9 yesterday and had some issues. a few startup messages about missing sysctl ipv6 related things. 2019-01-23 20:22:28 also lxc complained about cgroups 2019-01-23 20:22:35 hm, i guess im not of too much use here, i have close to zero xp with ZFS 2019-01-23 20:23:23 clandmeter: do you think you could report those issues on bugs.a.o? 2019-01-23 20:23:34 clandmeter: the ipv6 things happen when the ipv6 module is not loaded anymore 2019-01-23 20:23:37 AinNero: i think something like this: http://tpaste.us/nMN9 2019-01-23 20:23:52 AinNero, it is loaded 2019-01-23 20:23:56 same here. i dont have much experience with zfs 2019-01-23 20:24:04 but it could be loaded later for some reason. 2019-01-23 20:24:11 ncopa: didnt you just say you use it? 2019-01-23 20:24:20 :) 2019-01-23 20:24:53 i also use it but dont have much experience with it :) 2019-01-23 20:26:15 but the logical volumes/trees show up as device node? 2019-01-23 20:26:31 hum 2019-01-23 20:26:34 dont know 2019-01-23 20:26:46 i guess not 2019-01-23 20:27:01 like, with lvm2 its an devicemapper blockdev 2019-01-23 20:27:09 regarding sysctl messages, if it depends on ipv6 module we should or load it by default or remove the rules by default. 2019-01-23 20:27:32 blkid reports: /dev/sda4: LABEL="tank" UUID="9680052662386236292" UUID_SUB="18196581817640080421" TYPE="zfs_member" PARTUUID="4255c2ae-815e-475a-93dd-7a9cf412176a" 2019-01-23 20:27:58 thats the physical device 2019-01-23 20:28:12 there should be something alpine/root 2019-01-23 20:28:21 that is the device node that pops up 2019-01-23 20:28:34 clandmeter: i think we load ipv6 by default nowdays 2019-01-23 20:29:06 ncopa, how? 2019-01-23 20:29:08 assuming loading ipv6 is the new default, it does not get adopted if there were modifications to /etc/modules 2019-01-23 20:29:56 commit 0655da328034c0de4ba88ea54613347b906da77e 2019-01-23 20:29:56 Author: Natanael Copa 2019-01-23 20:29:56 Date: Thu Jun 7 10:52:32 2018 +0000 2019-01-23 20:29:56 main/alpine-baselayout: enable ipv6 and sysrq by default 2019-01-23 20:30:16 via /etc/modules? 2019-01-23 20:30:20 yes 2019-01-23 20:30:21 yes 2019-01-23 20:30:26 hmm 2019-01-23 20:30:30 may need to run update-conf 2019-01-23 20:30:36 ^ 2019-01-23 20:30:48 there was no new config 2019-01-23 20:31:25 and i do not have it in /etc/modules 2019-01-23 20:31:35 SpaceToast: `update-conf` is something we'd really need in a 'how to upgrade' section in the handbook 2019-01-23 20:31:54 update-conf runs a diff with .apk-new 2019-01-23 20:32:07 i know 2019-01-23 20:32:18 clandmeter: apk upgrade will not overwrite things in /etc/ (except /etc/init.d), it will create an .apk-new 2019-01-23 20:32:38 yes i know that for more than 10 years now thanks :) 2019-01-23 20:32:43 :) 2019-01-23 20:32:46 lol 2019-01-23 20:32:57 <_ikke_> :D 2019-01-23 20:33:03 the thing is there is no apk-new file 2019-01-23 20:33:04 what im trying to say is, i think you need to manually add ipv6 to your /etc/modules 2019-01-23 20:33:06 and modules doesnt have it 2019-01-23 20:33:07 aha 2019-01-23 20:33:40 oh and i bumped into the usb-storage issue (again) 2019-01-23 20:33:59 usb got mouted as sda1 2019-01-23 20:34:21 instead of? 2019-01-23 20:34:37 <_ikke_> usb? 2019-01-23 20:35:01 yes usb 2019-01-23 20:35:14 i think the proper fix for that is to use UUID 2019-01-23 20:35:24 in fstab? 2019-01-23 20:35:53 im always confused how that works 2019-01-23 20:36:10 what causes /media/xxx to be mounted? 2019-01-23 20:36:27 interesting 2019-01-23 20:36:56 apk info -W /etc/modules 2019-01-23 20:37:04 /etc/modules is owned by alpine-baselayout-3.1.0-r2 2019-01-23 20:37:16 apk fix alpine-baselayout 2019-01-23 20:37:25 (1/1) Reinstalling alpine-baselayout (3.1.0-r2) 2019-01-23 20:37:48 and suddenly modules.apk-new is there 2019-01-23 20:38:01 huh.. thats interesting 2019-01-23 20:38:10 if nlplug-findfs finds either apkovl or .boot_repository, then it will mount /media/ 2019-01-23 20:38:37 if is found in /etc/fstab, then it will adjust mount point accordingly 2019-01-23 20:38:38 yes thats was my knowledge 2019-01-23 20:38:42 mount --move iirc 2019-01-23 20:38:46 ah ok 2019-01-23 20:38:49 that i didnt know. 2019-01-23 20:39:09 the idea is that /etc/fstab will always win 2019-01-23 20:39:34 i was already confused to now find any apk-new entries in etc 2019-01-23 20:39:46 s/now/not 2019-01-23 20:39:46 clandmeter meant to say: i was already confused to not find any apk-new entries in etc 2019-01-23 20:40:09 i wonder what happens 2019-01-23 20:40:26 can we release 3.9.1 as is? or should we fix ZFS=....? 2019-01-23 20:40:34 i sort of want to just push 3.9 2019-01-23 20:40:42 <_ikke_> 3.9.1? 2019-01-23 20:40:48 3.9.1? 2019-01-23 20:40:52 <_ikke_> ha 2019-01-23 20:40:52 did i miss something? 2019-01-23 20:41:49 s/3.9.1/3.9.0/ 2019-01-23 20:41:49 ncopa meant to say: can we release 3.9.0 as is? or should we fix ZFS=....? 2019-01-23 20:42:17 i guess what i had in mind was, can we fix this for 3.9.1? 2019-01-23 20:42:28 clandmeter: i also wonder about signed modloop 2019-01-23 20:42:37 which was supposed to be fixed for 3.8.x 2019-01-23 20:42:44 hmm 2019-01-23 20:42:51 but i dont know what needs to be done or how its supposed to work 2019-01-23 20:42:54 or how i can test it 2019-01-23 20:42:54 it was targetted for netboot 2019-01-23 20:43:04 i think the tools are available 2019-01-23 20:43:19 2019-01-23 20:32:38 yes i know that for more than 10 years now thanks :) :D 2019-01-23 20:43:36 i think we maybe also already signtthe modloop 2019-01-23 20:43:45 do you mind for a second ? https://github.com/alpinelinux/aports/pull/6143 . Currently broken on s390x without this patch. 2019-01-23 20:43:49 hi tmh1999! nice to have you back! 2019-01-23 20:43:56 I remembered we have signed modloop 2019-01-23 20:44:22 ncopa: Hi I'm back for 2 weeks ! I messaged you but it seems you were on travel. I'm now tmhoang@freenode at day time ... 2019-01-23 20:45:00 im not sure we integrated it into the mkimage profile? 2019-01-23 20:47:21 tmh1999: im still on travel (currently on a cafe in a shopping mall with good wifi and AC) 2019-01-23 20:47:49 ncopa: Aw poor you mi amigo ... 2019-01-23 20:48:13 :) 2019-01-23 20:48:45 ac wifi is nice ;-) 2019-01-23 20:48:57 lol 2019-01-23 20:49:08 AC = power adapter ? 2019-01-23 20:49:14 air condition 2019-01-23 20:49:22 Hello 2019-01-23 20:49:32 ok at least it's closer than ac wifi :D 2019-01-23 20:49:46 axe: hi 2019-01-23 20:49:46 somewhere further from UTC/CET ? 2019-01-23 20:50:05 ncopa, i dont think we added it to mkimage (yet) 2019-01-23 20:50:19 GMT-3 2019-01-23 20:50:23 only mkinitfs and alpine-conf 2019-01-23 20:50:47 clandmeter: can you check exactly whats missing, and maybe write an email or an issue on bugs.a.o? 2019-01-23 20:51:05 How do I take nodejs source code and make an alpine package out of it? 2019-01-23 20:51:06 and i'll try fix it tomorrow 2019-01-23 20:51:07 damn, i need to write down what i should write down 2019-01-23 20:51:13 <_ikke_> lol 2019-01-23 20:51:17 lol 2019-01-23 20:51:48 axe: https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package 2019-01-23 20:51:54 On debian based systems I can just use checkinstall, but I want to use alpine now. 2019-01-23 20:52:29 I got this irc channel from that link 2019-01-23 20:52:32 <_ikke_> axe: you can use abuild if you have an APKBUILDdefinition 2019-01-23 20:52:50 <_ikke_> axe: you can probably look at existing packages 2019-01-23 20:53:07 Oh, so I first have to include an APKBUILD file in the source folder, and then I can use abuild? 2019-01-23 20:53:35 yes, the APKBUILD is the recipy for building the .apk 2019-01-23 20:53:46 ok, i need to go 2019-01-23 20:53:50 \o 2019-01-23 20:53:54 They're a different version than what I've been using for my webapps, and I don't want to go through the hassle of fixing my webapps to work with the older version. 2019-01-23 20:54:08 thanks ncopa 2019-01-23 21:01:02 ncopa, you want me to send a patch for mkimage? 2019-01-23 21:03:21 clandmeter: would you mind pasting here if you have already had it ? I'd love to read yours 2019-01-23 21:04:01 tmh1999, i dont have it. need to look into it. 2019-01-23 21:04:14 clandmeter: okay because I'm doing so 2019-01-23 21:04:15 tmh1999, if you have something already please share :) 2019-01-23 21:04:19 sure thing 2019-01-23 21:04:40 on first sight it doesnt look that hard to add. 2019-01-23 21:04:50 i wonder if we should have it for all profiles 2019-01-23 21:06:47 musl 1.1.21 was out 2 days ago,wow 2019-01-23 21:12:28 ncopa, i wonder if adding the uuid to fstab would fix my issue of missing cache repo. wouldnt the mount --move be done after apk restores system? 2019-01-23 21:28:55 Wow I decided to look at existing nodejs apk packages for an example of a APKBUILD file and it's a lot more involved of a process than I thought. Nothing like using checkinstall on debian based systems 2019-01-23 21:49:57 clandmeter: yes, it is after apkovl is found, because apkovl contains the fstab, but there is a loop that will parse fstab and move the mounts before swap_root 2019-01-23 22:02:37 It seems to be working 2019-01-23 22:03:03 thanks for clearing that up for me, ncopa, I really appreciate it. 2019-01-23 22:04:15 ncopa: I guess you just downgrade kernel from 4.19.16 to 4.19.7 2019-01-23 22:05:15 guess it should 17 2019-01-23 22:05:41 @clandmeter: mind a push for the kernel ? 2019-01-23 22:09:00 Ah looks like it 2019-01-23 22:10:10 Im not behind pc 2019-01-23 22:10:23 okay, good night :) 2019-01-23 22:14:05 I messaged ncopa. It's included in the latest rc :| 2019-01-23 22:14:23 He will fix it later 2019-01-23 22:15:09 yeah no worry/hurry though 2019-01-23 22:16:26 I'm going to look into the sign modloop thing tmr at work. My vm is down due to a bug in 4.19.10 kernel ... 2019-01-23 22:25:03 Does making a package usually take as long/longer than compiling? 2019-01-23 22:25:27 axe: depends on the complexity of the package :D 2019-01-24 00:32:50 Bah... I will fix the kernel update 2019-01-24 02:26:51 rc5 pushed 2019-01-24 02:50:23 new update - my gateway (running edge, on "flat" btrfs) just got its updates as well - everything is still all good in terms of booting 2019-01-24 02:50:29 (it's amd64 with uefi) 2019-01-24 08:26:09 <_ikke_> goes fast 2019-01-24 08:26:16 <_ikke_> missed r4 2019-01-24 08:26:57 yes it had an issue 2019-01-24 08:27:09 kernel version drop instead of bump :) 2019-01-24 08:28:49 <_ikke_> d'oh 2019-01-24 13:43:07 what target to add to alpine-linux-musl rust? All, in hope that one day we will manage to bootstrap on all arch's 2019-01-24 13:46:19 I think we should rename arm_alpine_linux_musleabihf to armhf_alpine_linux_musleabihf. Right? 2019-01-24 14:20:23 Re #9901 I guess we can remove/replace the text "general purpose" on the about page and close the issue as resolved? 2019-01-24 14:27:49 Re #9903 I think it also happens with ext4. Problem is that our initramfs needs rootfstype to be set but grub-mkconfig does not set it 2019-01-24 14:29:09 I guess the simplest solution is to run blkid in initramfs if rootfstype is missing 2019-01-24 15:22:36 re: 9901 I don't think the issue is with how we describe things... this person has been on the user ML, and they seem somewhat confused - for instance, the first thing they asked about was how to convert sysv scripts to openrc, but explicitly did *not* want to write an openrc init script 2019-01-24 15:22:58 meanwhile, dropping the general purpose label has lots of implications I'm not sure are desirable :) 2019-01-24 15:23:41 when I was poking about, it seemed to me that the issue with NM was that it couldn't integrate with wpa_supplicant properly; I'm planning to port iwd over once I have some time, so that could be all that's needed 2019-01-24 15:24:33 <[[sroracle]]> SpaceToast: https://code.foxkit.us/sroracle/packages/blob/sr/user/iwd/APKBUILD 2019-01-24 15:24:50 <[[sroracle]]> I think the musl patch can be dropped if you bump to latest version, those changes should be merged 2019-01-24 15:25:19 latest version is much more.. latest :) 2019-01-24 15:25:35 we're on 0.14 rather than 0.2 2019-01-24 15:26:09 but yeah, it should be quite simple, just a matter of doing it; I'm explicitly not touching my user-aports at the moment though, in order to make sure I don't accidentally take time away from the first docs component 2019-01-24 16:01:46 it annoys me that user wants us to drop everything in our hands and immediately fix #9901 2019-01-24 16:04:21 oh I'm aware, they act the same way in the ML :) 2019-01-24 16:04:35 but fundamentally changing what the distribution is about because of a bad actor seems silly to me 2019-01-24 16:05:24 new users would be much easier if they hadn't expectations of how our distro should work 2019-01-24 16:06:13 lets offer him a full refund 2019-01-24 16:06:17 :D 2019-01-24 16:06:57 people already have a (very strong) inclination to believe that alpine is for "servers and embedded" only - a few people have straight up been surprised to hear we have xfce in the repos at all - they didn't bother checking because they're so sure 2019-01-24 16:07:17 responding to 9901 by removing the claim that we are general purpose will, imo, solidify that belief 2019-01-24 16:07:48 whereas, from what I'm seeing, things are getting better (e.g plasma5 work is still ongoing) - sure there are lots of things to fix, but all of those things are *fixable*, given enough time 2019-01-24 16:09:42 i'd not give in just to spite their attitude 2019-01-24 16:10:06 yeah, you are both right 2019-01-24 16:10:11 aye, complying to something like that (even in a "ok, we're no longer general purpose") not only feels wrong, it tends to give bad results :) 2019-01-24 16:10:29 also, general purpose != support for poetteringware 2019-01-24 16:10:49 hah 2019-01-24 16:11:33 I don't necessarily mind systemd being an option if users want it (though in this case it's outright impossible, poettering actively breaks support with everything except glibc), I start having questions when it's the *only* option 2019-01-24 16:11:51 e.g with our current setup, if someone wanted to use runit as their init system, it'd be a relatively simple process 2019-01-24 16:15:50 systemd and minimalistic doesn't go together 2019-01-24 16:16:15 there was only one minimalistic distro using systemd, and they switched to runit 2019-01-24 16:18:38 ACTION put the irssi trigger to remove word systemd 2019-01-24 16:21:21 no one have comment about my question regarding rename rust arm-alpine-linux-musleabihf target to armhf-alpine-linux-musleabihf 2019-01-24 16:22:04 huh 2019-01-24 16:22:12 it has hf twice 2019-01-24 16:23:14 right, but arch is named 'armhf' and we now have 'armv7' 2019-01-24 16:23:46 the v7 indeed belongs at the beginning 2019-01-24 16:25:57 I added armv7 and aarch64 already, but not sure what to do with 'arm' it is too generic 2019-01-24 16:25:58 mps: i have no clue 2019-01-24 16:26:29 let me check what abuild says on armhf 2019-01-24 16:28:34 'abuild -A' says armhf, so I think that I will add armhf-alpine-linux-musleabihf target 2019-01-24 16:28:52 the abuild arch is separate from the compiler tuple 2019-01-24 16:29:25 https://github.com/alpinelinux/abuild/blob/master/functions.sh.in 2019-01-24 16:29:40 yes, compiler are armv6-alpine-linux-musleabihf-xxx 2019-01-24 16:32:53 ok. for now I will skip that and just try to add armv7 patch in aports repo 2019-01-24 16:37:54 mps: on amd64, my rust "target" is x86_64-unknown-linux-musl; s/unknown/alpine/ is quite obvious, and I'm not sufficiently familiar with arm - is abi<(hf)?> normal? 2019-01-24 16:39:10 s/glibc/libc/ 2019-01-24 16:39:10 SpaceToast meant to say: mps: on amd64, my rust "target" is x86_64-unknown-linux-musl; s/unknown/alpine/ is quite obvious, and I'm not sufficiently familiar with arm - is abi<(hf)?> normal? 2019-01-24 16:39:24 its eabi on arm, usually 2019-01-24 16:40:49 SpaceToast: it should be x86_64-alpine-linux-musl 2019-01-24 16:41:18 the vendor field is optional 2019-01-24 16:42:12 yes but most have 'vendor' addapted 2019-01-24 16:42:23 I mentioned that yes :) it's not actually running alpine (that's my laptop), but the questions was regarding the libc bit specifically 2019-01-24 16:42:31 as we have in gcc and other tools 2019-01-24 16:43:38 SpaceToast: for musl we have 'musl' and arm's eabi plus hf where needed 2019-01-24 16:45:23 SpaceToast: I'm not right now behind dev machine, but in about ten minutes I'll post targets which I added 2019-01-24 16:51:23 any ideas how to fix #9903? 2019-01-24 16:52:22 we could have a postupgrade script that parses /proc/cmdline and creates /etc/default/grub if its missing 2019-01-24 16:52:28 but it sounds hackish 2019-01-24 16:52:32 since when do we have that bug? 2019-01-24 16:52:47 I'll take a look once I'm back home (in ~8+ hours) 2019-01-24 16:52:54 since i changed grub to use grub-mkconfig 2019-01-24 16:52:56 if you could, please PM me the bug link :) 2019-01-24 16:55:28 new installs work: https://git.alpinelinux.org/alpine-conf/commit/?id=13c1ebccd0b53fe82a1c8454d9dbbea9bea26699 2019-01-24 16:55:34 but upgrade does not 2019-01-24 16:55:47 the above also shows the setup-disk created grub.cfg 2019-01-24 16:57:34 another option is to ship an /etc/default/grub with grub package GRUB_CMDLINE_LINUX_DEFAULT="quiet" 2019-01-24 16:57:48 bu that will break things for people who depend on a special modules=... 2019-01-24 16:58:54 i think we need a post-upgrade script 2019-01-24 16:59:04 that parses /proc/cmdline 2019-01-24 16:59:10 strips out root=... 2019-01-24 16:59:41 and does nothing if GRUB_CMDLINE_LINUX_DEFAULT is set 2019-01-24 17:00:00 the complaint is about the value of root=, from what I can tell 2019-01-24 17:00:21 /etc/default/grub not being populated on upgrade is something I had mentioned... how do we populate $modules in setup-disk? 2019-01-24 17:02:33 perhaps we can have the post-upgrade script generate a "sane" /etc/default/grub, but place it into .apk-new if one already exists? 2019-01-24 17:02:46 ("sane" by detecting root= fs type and whatever else is needed) 2019-01-24 17:10:20 i think complaint is wrong. i think problem is the missing rootfstype= 2019-01-24 17:11:33 yes, i think we need a postupgrade that does nothing if GRUB_CMDLINE_LINUX_DEFAULT is set, and if its not set, we set it to something "sane" by parse /proc/cmdline 2019-01-24 17:12:39 ncopa: can't remember exactly but about half year (or maybe more) I tried f2fs in qemu and rootfstype have to be set to boot, iirc 2019-01-24 17:13:13 it was with syslinux 2019-01-24 17:13:28 my complaint is regarding parsing /proc/cmdline 2019-01-24 17:13:37 I think ideally we should build it from scratch by detecting rootfs etc 2019-01-24 17:13:57 however, the complaint that root=non-UUID is also valid, since we should be using UUID in almost all cases now 2019-01-24 17:14:06 without it boot didn't worked even when I put f2fs module in initramfs 2019-01-24 17:15:15 UUID is best choice for default, in my experience 2019-01-24 17:15:26 grub-mkconfig does try to detect uuid and use it if found 2019-01-24 17:16:00 the user in question either explicitly disables UUID (unlikely), uses lvm (possible, but maybe they'd mention it?) or grub failed to find a UUID 2019-01-24 17:16:00 most FSs today have UUID 2019-01-24 17:16:14 I have no idea *how* grub detects UUIDs though, and I can't look it up right now 2019-01-24 17:18:02 http://git.savannah.gnu.org/cgit/grub.git/tree/util/grub-mkconfig.in#n136 2019-01-24 17:18:37 basically: grub-probe --target=fs_uuid / 2019-01-24 17:19:19 i think we have to parse /proc/cmdline 2019-01-24 17:19:35 at a minimum to detect modules= and rootfstype= 2019-01-24 17:19:38 it just feels really wrong, to me 2019-01-24 17:19:42 agree 2019-01-24 17:19:46 e.g sd-mod isn't required for the vast majority of systems 2019-01-24 17:19:54 (well, desktop/laptop systems :) ) 2019-01-24 17:20:04 but parsing /proc/cmdline e.g during installation will cause it to be added 2019-01-24 17:20:35 the long term solution would be to add the ability to automatically load modules into the initrd, but that's (relatively) quite heavy, afaik 2019-01-24 17:21:15 this is not for installation 2019-01-24 17:21:20 this is for upgrade 2019-01-24 17:21:26 so the installation will *not* probe cmdline? 2019-01-24 17:21:34 correct 2019-01-24 17:21:39 only the post-upgrade 2019-01-24 17:21:41 ok, I'm fine with it then 2019-01-24 17:21:51 since cmdline will already be tuned by the user (or us) during install 2019-01-24 17:22:01 yes 2019-01-24 17:22:02 but then we have to be judicious in what we put in it during install 2019-01-24 17:25:05 ncopa: Debian have /etc/default/grub where that can be overridden, do you put something similar for Alpine 2019-01-24 17:26:29 yes 2019-01-24 17:26:41 we also use /etc/default/grub 2019-01-24 17:26:48 since that is what grub users expect 2019-01-24 17:27:05 does redhat/fedora also use /etc/default/grub? 2019-01-24 17:27:11 and gentoo? 2019-01-24 17:27:31 don't know for other distro's, only for debian/ubuntu 2019-01-24 17:27:42 grub-mkconfig uses /etc/default/grub, so its the upstream config 2019-01-24 17:27:52 im actually pretty annoyed by grub 2019-01-24 17:28:07 in theory /etc/grub.d/* is config 2019-01-24 17:28:27 thats because nobody can agree on a sensible config structure heh 2019-01-24 17:28:41 so if your linux system does not boot, please go ahead and edit /etc/grub.d/10_linux 2019-01-24 17:28:43 well, I'm long time annoyed with it, because that switched to syslinux 2019-01-24 17:28:48 default, conf.d, etc 2019-01-24 17:30:58 in my experience with Debian it works fine but requires sometimes 'fine' tweaks 2019-01-24 17:32:42 yeah, the location of /etc/grub.d is weird 2019-01-24 17:32:54 based on how it's meant to be used it should be in /usr/share/grub/grub.d or something 2019-01-24 17:33:00 grub is weird 2019-01-24 17:33:38 $ tpaste < grub.post-upgrade 2019-01-24 17:33:39 http://tpaste.us/M5Yv 2019-01-24 17:34:07 missing esac 2019-01-24 17:34:36 yup, looks alright otherwise, I think? 2019-01-24 17:34:43 you might want to also exclude rootflags=* 2019-01-24 17:34:54 (used in btrfs for subvols etc) 2019-01-24 17:34:59 grub should autodetect them 2019-01-24 17:36:46 you are right 2019-01-24 17:38:07 also re: setup-disk, considering how bootloader config is getting more complex, might it make sense to split that part out into setup-bootloader (or similar)? 2019-01-24 17:38:28 (e.g people setting up their partitioning by hand may be interested in having the two steps be separate) 2019-01-24 17:38:49 yeah 2019-01-24 17:39:07 that can probably happen after 3.9 though, just mentioning :) 2019-01-24 17:39:22 agree, make sense 2019-01-24 17:39:47 i have been thinking of rewrite setup-* scritps in lua 2019-01-24 17:40:02 and with lua-linenoise for tab autocompletion 2019-01-24 17:40:21 and so you can press or similar and get a menu 2019-01-24 17:40:32 so you can jump backwards if you need 2019-01-24 17:40:58 currently you can only ctrl-c and start over if you need change something you previously did 2019-01-24 17:41:12 that sounds interesting to me :D 2019-01-24 17:41:25 you were also considering cloud-init support iirc 2019-01-24 17:41:31 yes 2019-01-24 17:41:41 or partial support 2019-01-24 17:42:03 so that you can provide a cloud-init config file to setup-alpine 2019-01-24 17:42:11 ah, that sounds ok 2019-01-24 17:42:55 if/when you start working on it (I'm guessing after 3.9 :) ), please do tell me, I'll be interested in looking in, giving feedback, etc (though I suspect I'll still be plenty busy with docs by the time that happens... which means I'll need to know the details regardless) 2019-01-24 17:43:25 yeah 2019-01-24 17:43:49 I think I won't add any details to the docs until it's finished, though 2019-01-24 17:43:57 (at which point I'll rewrite that entire section) 2019-01-24 17:44:17 i suspect that after v3.9 we will only have time to upgrade llvm, clang, python, musl, boost and then its time for 3.10 2019-01-24 17:44:58 ok, those are all (except boost) upgrades I'm interested in, and I'm certainly ok with waiting longer before rewriting a couple thousand words :) 2019-01-24 17:45:06 I'm still interested in participating once (eventually) it happens though 2019-01-24 17:45:59 and rust support 2019-01-24 17:48:20 ncopa: I prepared clang, llvm6, lld6 but didn't sent patches waiting 3.9 release first 2019-01-24 17:48:39 nice! 2019-01-24 17:48:56 mps: awesome 2019-01-24 17:50:43 few days ago asked here what to do with naming new llvm, we have main/llvm5, should we add main/llvm6 or make community/llvm6 2019-01-24 17:51:17 hmm, looking at it, llvm is on 7 by now 2019-01-24 17:51:21 also we have community/llvm3.9 2019-01-24 17:51:24 is there any specific reason we can't skip 6? 2019-01-24 17:51:52 llvm7 needs more patching and testing 2019-01-24 17:52:00 ok 2019-01-24 17:52:32 if we're going llvm$N, could make sense to add testing/llvm7 2019-01-24 17:52:39 I thought in first step to go with llvm6, most other tools works fine with that version 2019-01-24 17:54:34 testing/llvm7 sounds fine, I even have it in private repo, but not finished yet 2019-01-24 17:54:46 nice :) 2019-01-24 17:56:25 my question for brainstorming is, where to put llvm6, generic main/llvm, main/llvm6, community/llvm6 or something else 2019-01-24 17:57:24 and, that rust will 'kill' 2019-01-24 17:57:42 since our current llvms have numbering, we could keep doing that; so probably main/llvm6 2019-01-24 17:57:48 ok i think grub is okish now 2019-01-24 17:57:56 eh, again enter key, hat rust will 'kill' me :) 2019-01-24 17:58:28 we should probably also fix initramfs-init to work without rootfstype set 2019-01-24 17:59:13 it should be relatively easy. if KOPT_rootfstype is empty, then call blkid and find TYPE= 2019-01-24 18:18:34 I guess we only need to fix ZFS= and we are good for 3.9.0? 2019-01-24 20:35:51 fsck.f2fs should be in initramfs to sole #9910, probably 2019-01-24 22:02:34 hm, thats 2 boxes that don't boot anymore 2019-01-24 22:02:54 genuine problem? (the one I have video for complains about crc32 module missing when loading fs driver) 2019-01-24 22:03:22 x86_64, bumped to linux-vanilla in testing 2019-01-24 23:44:11 jwh: what filesystem? 2019-01-24 23:44:35 i think th crc32 module(s) needs to explicitly be included in the initramfs 2019-01-24 23:44:46 so its a bug 2019-01-24 23:45:18 ncopa: f2fs 2019-01-24 23:45:50 it says crc32 (I'm pretty sure it was 32, I'll look in a bit), but I don't see a module named that on disk, only libcrc32 2019-01-24 23:46:32 there are quite a few differences between a couple of versions ago 2019-01-24 23:47:17 but uh, it broke on my other box too which is ext4 2019-01-24 23:47:21 kernel/fs/crypto/fscrypto 2019-01-24 23:48:14 sorry, kernel/fs/crypto/fscrypto should be added to /etc/mkinitfs/features.d/f2fs.modules 2019-01-24 23:48:54 I forgot to add issue in bugs.a.o 2019-01-24 23:48:57 well, it might be a coincidence, but its not just f2fs I don't think 2019-01-24 23:49:08 I'll upgrade a VM shortly 2019-01-24 23:49:30 should probably have doen that before upgrading headless boxes :D 2019-01-24 23:50:08 I did that about half year ago when added f2fs to syslinux and initramfs 2019-01-24 23:50:48 heh, it took me a while to realise I hadn't added f2fs to modules= 2019-01-24 23:52:56 hmm, my /etc/mkinitfs/mkinitfs.conf contains: features="ata base ide scsi usb virtio ext4 f2fs" 2019-01-24 23:53:36 hm, yeah 2019-01-25 00:38:27 hm ok 2019-01-25 00:38:35 ext4 one is unrelated, no idea why that didn't boot 2019-01-25 00:43:47 yeah crc32, need to find the magic combination of modules to load for my usb keyboard though, probably should work ootb heh 2019-01-25 00:46:50 hm so this one is odd 2019-01-25 00:56:27 not having it with fscrypto in initramfs either 2019-01-25 00:57:08 can't figure out the magic list of modules for my keyboard either so can't see whats going on 2019-01-25 00:58:27 jwh: f2fs depends on fscrypto 2019-01-25 00:59:12 'modinfo f2fs' shows that 2019-01-25 01:00:54 yeah 2019-01-25 01:01:24 but its not that thats breaking it 2019-01-25 01:01:38 (and it wasn't in the initramfs before the update either, and it worked) 2019-01-25 01:01:53 its the last vanilla update that killed it 2019-01-25 01:02:20 but... without a keyboard I can't verify its actually loading fscrypto :D 2019-01-25 01:02:31 absurd problem to have but what you gonna do 2019-01-25 01:05:22 yeah, so ext4 has the missing modules 2019-01-25 01:06:50 ext4 depends on mbcache,jbd2,crc16 2019-01-25 01:07:20 crc32c_generic (and any arch specific ones) 2019-01-25 01:08:11 the underlying problem is there is no dependency tree between fscrypto and modules it relies on 2019-01-25 01:08:28 guess it just works as typically those routines are built in rather than as modules 2019-01-25 01:08:39 or they're loaded by other modules 2019-01-25 01:09:48 either way, making f2fs the same as ext4 is sufficient 2019-01-25 01:09:50 ext4 depends on: kernel/arch/*/crypto/crc32* 2019-01-25 01:10:06 yes, I *just* said that 2019-01-25 01:10:06 lol 2019-01-25 01:10:16 thats whats missing from f2fs.modules 2019-01-25 01:10:19 cat /etc/mkinitfs/features.d/ext4.modules 2019-01-25 01:10:24 ... 2019-01-25 01:10:27 kernel/arch/*/crypto/crc32* 2019-01-25 01:10:32 please read 2019-01-25 01:10:36 kernel/crypto/crc32* 2019-01-25 01:10:44 kernel/fs/ext4 2019-01-25 01:11:15 yes... 2019-01-25 01:11:38 that's all for ext4 2019-01-25 01:13:27 and, Alpine default /etc/mkinitfs/features.d/f2fs.modules have only one line: kernel/fs/f2fs 2019-01-25 01:13:48 sigh 2019-01-25 01:13:50 I'll repeat it agai 2019-01-25 01:13:51 n 2019-01-25 01:14:09 f2fs requires crc32c and friends, just like ext4 2019-01-25 01:14:11 this will not work, so I added locally another line: kernel/fs/crypto/fscrypto 2019-01-25 01:14:18 it isn't that 2019-01-25 01:14:35 but since you likely still have ext4 in your features, it will work 2019-01-25 01:14:43 I do not 2019-01-25 01:14:48 hence the problem 2019-01-25 01:15:27 fscrypto doesn't depend on any module 2019-01-25 01:15:52 yeaah, not repeating myself gain 2019-01-25 01:15:55 again* 2019-01-25 01:16:21 [01:08:11] < jwh> the underlying problem is there is no dependency tree between fscrypto and modules it relies on 2019-01-25 01:16:54 ok, ok, just trying to conclude what could be propblem in your case, not to persuade you to something 2019-01-25 01:17:17 well, actually its a dependency of f2fs.ko but I can't see why 2019-01-25 01:18:20 would help if I had a copy of the source 2019-01-25 01:18:34 super.c, thats the chap 2019-01-25 01:21:26 I had problem like you a year ago (iirc) with f2fs (but not with keyboard) and solved it by adding kernel/fs/crypto/fscrypto to /etc/mkinitfs/features.d/f2fs.modules 2019-01-25 01:21:42 yes, but did you see what I said? 2019-01-25 01:21:47 [01:14:35] < jwh> but since you likely still have ext4 in your features, it will work 2019-01-25 01:22:03 or some other feature that also happened to pull in the dependencies 2019-01-25 01:22:38 btrfs, ext4, raid, xfs - those pull in the same 2019-01-25 01:22:47 yes, yes, I see. I don't remember exactly, but also I didn't added ext4 then 2019-01-25 01:23:01 well its there by default, so it would make sense 2019-01-25 01:23:28 easy enough fix though, all good 2019-01-25 01:23:29 and also remember that tried to find which crc32 and crc16 to add 2019-01-25 01:24:04 it was about year ago and in qemu so I forgot details 2019-01-25 01:24:09 yeah, sounds similar 2019-01-25 01:24:29 if someone could commit a fix that would be awesome :D 2019-01-25 01:24:45 but, I'm sure that for f2fs you need kernel/fs/crypto/fscrypto 2019-01-25 01:24:54 yeah I have that anyway 2019-01-25 01:25:15 and not sure for crc32, but maybe that also must be loaded 2019-01-25 01:25:25 but thats similar, the same drivers that pull in *crc* also pull in fscrypto 2019-01-25 01:25:47 it has explicit code in the module to bail 2019-01-25 01:26:00 https://kernel.googlesource.com/pub/scm/linux/kernel/git/jaegeuk/f2fs-stable/+/linux-3.18.y/fs/f2fs/super.c#3104 2019-01-25 01:26:09 ancient version but that bit is the same 2019-01-25 01:27:05 huh, here is [02:26] so not good time to look at kernel source, at least for me 2019-01-25 01:27:10 heh, same here 2019-01-25 01:29:41 yes, source shows that it need crc32 2019-01-25 01:31:38 makes sense that the various filesystems depend on it 2019-01-25 01:32:00 would probably make sense to move crc to base or something... unless people actually boot without any filesystem support 2019-01-25 01:32:02 that same block is in the 4.19 2019-01-25 01:32:25 likely used by other modules anyway 2019-01-25 01:32:37 by ext4 for sure 2019-01-25 01:33:13 theres a number that do 2019-01-25 01:34:27 yes, in fs/ext4/super.c line 3631 have the same block, like it is a copy-pasted 2019-01-25 01:34:44 heh, cute 2019-01-25 01:35:33 but ext4 have that: MODULE_SOFTDEP("pre: crc32c"); 2019-01-25 01:35:56 ahhh 2019-01-25 01:35:58 while f2fs doesn't have it 2019-01-25 01:36:24 so, we discovered bug in f2fs driver 2019-01-25 01:37:32 well, the argument may well be that since many modules rely on crc32 why isn't it loaded anyway, not up to the driver 2019-01-25 01:37:55 I can kinda understand that, don't really want to be declaring every possible dependency in every module 2019-01-25 01:40:28 in the meantime though, should probably get that added to the packaged f2fs.modules 2019-01-25 01:40:39 just incase someone else stumbles upon it 2019-01-25 01:43:22 well, I had a chat about that with some people here (ncopa and azarus, iirc) and forgot to add issue in bugs.a.o, about year ago, to repeat myself 2019-01-25 01:43:47 doh 2019-01-25 01:45:30 probably bug in f2fs driver, missing something like that in ext4 'fs/ext4/super.c:MODULE_SOFTDEP("pre: crc32c");' 2019-01-25 01:46:37 yaeh 2019-01-25 01:49:23 well, one less thing I need to fix at least, onto other nonsense :D 2019-01-25 01:52:55 well, we enjoy to fix things, doesn't we :) 2019-01-25 01:53:28 heh 2019-01-25 01:53:35 I'll revisit usb keyboard another day 2019-01-25 01:53:53 kinda hard to debug why the keyboard doesn't work... without a keyboard 2019-01-25 01:54:54 serial console? (: 2019-01-25 01:55:06 nope, intel stick :D 2019-01-25 05:06:31 finally solution for pytest-xdist, eh, such a challenge 2019-01-25 05:18:00 hmmm strange response from travis 2019-01-25 05:18:14 "No packages found to be buil" 2019-01-25 05:46:58 ncopa, clandmeter: I know you're busy with the upcoming alpine release - but if you guys or somebody else has time to look at this qt5-qtwebengine fix for x86, it would be nice. it's a simple patch: https://github.com/alpinelinux/aports/pull/6156 2019-01-25 08:20:54 is there a ninja musl patch for st.st_mtim.tv_nsec? 2019-01-25 09:12:14 ollieparanoid[m], ok, i think we do not have to bump pkgrel. 2019-01-25 12:10:16 clandmeter: hi! i understand from ncopa that you're the person to talk to about infrastructure and possibly using gitlab ? 2019-01-25 12:10:41 (and also about aarch64 and UEFI perhaps?) 2019-01-25 12:11:51 mort___, hi, yes infra we can talk in #alpine-infra 2019-01-25 12:12:17 I played a bit with aarch64 and EFI 2019-01-25 12:12:28 but im not an export at all :) 2019-01-25 12:12:37 s/export/expert 2019-01-25 12:12:37 clandmeter meant to say: but im not an expert at all :) 2019-01-25 12:34:18 clandmeter: sorry afk! will move gitlab conversation to alpine-infra :) 2019-01-25 13:04:36 patchutils need rebuild, missing shebang (#!/usr/bin/perl) in scripts, could be because missing perl in makedepends 2019-01-25 13:08:17 clandmeter: re EFI/aarch64 - do you have any notes or anything you can point me to about that? 2019-01-25 13:09:26 context: i have an aarch64 server (fairly old hardware now, was something of an early beta release) that, after several firmware upgrades to move it to EFI boot, ended up working — but the only supported image from the vendor was an old version of centos 2019-01-25 13:09:35 i'd really like to put a proper distro on it … :) 2019-01-25 13:11:24 its an xgene board? 2019-01-25 13:12:17 i have a memory like a sieve. yes i think that's it 2019-01-25 13:12:18 hang on 2019-01-25 13:17:47 mort___, what are the issues you bump into now? 2019-01-25 13:17:53 MP30-AR1 motherboard, apm883408-xNA24SPT 2019-01-25 13:18:16 :) 2019-01-25 13:18:36 thats xgene yes 2019-01-25 13:19:13 not really difficult issues yet, more where do i start :) 2019-01-25 13:19:26 came across https://wiki.alpinelinux.org/wiki/Create_UEFI_boot_USB 2019-01-25 13:19:37 you should be able to just boot efi usb 2019-01-25 13:20:28 hmm, patchutils-0.3.4-r0 on aarch64 is correctly build with '#!/usr/bin/perl' and on x86_64 without. 2019-01-25 13:23:35 clandmeter: cool :) how do i create the image? 2019-01-25 13:24:35 im not sure if dd the iso to usb will work 2019-01-25 13:24:37 but you can try 2019-01-25 13:25:10 the iso is uboot though? 2019-01-25 13:25:25 (i tried that and it didn't seem to work) 2019-01-25 13:25:28 no 2019-01-25 13:25:47 regular aarch64 iso is not uboot i think 2019-01-25 13:26:13 also the aarch64 images i see on the download page are .tar.gz rather than .iso 2019-01-25 13:27:05 i think i made my own efi usb 2019-01-25 13:28:08 ooh - any chance you have any notes on doing so lying around? :) 2019-01-25 13:30:57 (please?) 2019-01-25 13:31:37 i dont think i have notes :( 2019-01-25 13:36:41 oh well :) i'll have a go. how hard can it be… :) 2019-01-25 14:13:21 I sent fix for #9913 to: https://patchwork.alpinelinux.org/patch/4430/ . I think that bug should be fixed before v3.9 release 2019-01-25 15:24:08 mps: pushed. thanks 2019-01-25 15:29:50 ncopa: noticed it, thanks 2019-01-25 15:30:19 i wonder if we should try fix grub + zfs root before release too 2019-01-25 15:30:41 i`m backporting the f2fs patch for grub 2019-01-25 15:33:21 last night I talked with jwh here. We found bug in f2fs kernel module, it missing depends crc32 when tried modinfo f2fs 2019-01-25 15:34:21 but in fs/f2fs/super.c 4.19 (and earlier) it is clear that it depends on it 2019-01-25 15:34:42 yeah 2019-01-25 15:35:23 maybe to add patch for vanilla or report upstream, if someone is ready to go through lkml labyrinths 2019-01-25 15:37:08 but, anyway, for release 'kernel/arch/*/crypto/crc32*' and 'kernel/crypto/crc32*' should be added to /etc/mkinitfs/features.d/f2fs.modules 2019-01-25 15:37:33 well for now, just adding the paths to f2fs.modules will do, can submit a patch upstream and just wait, but its still there for other modules even though they have correct dependencies so just for completeness... 2019-01-25 15:37:35 oh, and 'kernel/fs/crypto/fscrypto' 2019-01-25 15:39:30 ncopa, any idea why travis skips new package? https://github.com/alpinelinux/aports/pull/5516 2019-01-25 15:58:16 mps, jwh: yes, lets fix the mkinitfs' f2fs.modules 2019-01-25 16:00:02 andypost: weird. no clue. maybe ask jirutka? 2019-01-25 16:02:15 ncopa: didn't understood, to send patch or you will add them to /etc/mkinitfs/features.d/f2fs.modules 2019-01-25 16:04:04 i am checking if someone already sent patch 2019-01-25 16:04:10 if not i'll fix it 2019-01-25 16:04:22 unless you have a patch ready ofc 2019-01-25 16:04:26 didn't see anything on bugs.a.o 2019-01-25 16:04:41 http://tpaste.us/xpD7 2019-01-25 16:04:50 I wouldn't imagine people normally remove ext4 from features when adding f2fs 2019-01-25 16:04:59 hope that's enough 2019-01-25 16:05:12 yeah, thats enough on mine 2019-01-25 16:05:45 didn't need fscrypto as either it gets the dependency right or something else pulls it in, but should probably add it anyway 2019-01-25 16:06:33 in my experience fscrypto must be there 2019-01-25 16:06:49 don't have time to check it again 2019-01-25 16:06:53 ok 2019-01-25 16:09:51 pushed 2019-01-25 16:13:35 cool, thanks 2019-01-25 17:05:47 thinking of the root=ZFS=tank/alpine/root issue and nlplug-findfs 2019-01-25 17:06:19 as i understand the ZFS=x/y/z is that x is the zpool name 2019-01-25 17:06:46 my cmdline on my laptop is root=tank/alpine/root 2019-01-25 17:07:15 blkid reports: /dev/sda4: LABEL="tank" UUID="9680052662386236292" UUID_SUB="18196581817640080421" TYPE="zfs_member" PARTUUID="4255c2ae-815e-475a-93dd-7a9cf412176a" 2019-01-25 17:08:25 which basically means, when nlplug-findfs has found a TYPE="zfs_memeber" with label "tank", it has already found the root device it is looking for? 2019-01-25 17:09:08 and could in theory exit after import the zpool 2019-01-25 18:34:47 i think this will fix grub and zfs root: http://tpaste.us/yPBe 2019-01-25 18:34:54 just needs testing 2019-01-25 19:00:57 nice work 2019-01-25 19:01:39 im not sure how i'd generate a boot media using a git revision from mkinitfs 2019-01-25 22:06:46 i wonder why ppl add python packages to aports without taking care of the runtime deps... 2019-01-25 22:08:46 <_ikke_> probably lack of testing 2019-01-25 22:12:38 Possible but what use does it have. Probably just to satisfy some other aports deps. 2019-01-25 22:12:58 And even that breaks 2019-01-25 22:13:12 people don't like using langauge-specific package managers 2019-01-25 22:13:17 in some cases, that's fully justified 2019-01-25 22:13:27 (for example, python updates will break all pip/pipsi-installed packages) 2019-01-25 22:13:44 <_ikke_> SpaceToast: the problem is that they didn't add all run-time dependencies 2019-01-25 22:14:00 _ikke_: oh I realize, and I agree that it's lack of testing; I'm responding specifically to "but what use does it have" 2019-01-25 22:15:56 I'm upgrading certbot and switching it to py3 2019-01-25 22:16:13 <_ikke_> clandmeter: nice 2019-01-25 22:16:23 <_ikke_> I'm looking if I can get redo to work with py3 as well 2019-01-25 22:16:31 <_ikke_> but it seems to prefer py2 itself 2019-01-25 22:16:52 But wife is looking in my direction 2019-01-25 22:17:05 So i think i need to stop :) 2019-01-25 22:17:18 Will push tomorrow 2019-01-25 22:17:19 <_ikke_> better to respond :P 2019-01-25 22:17:48 After i fix all those deps 2019-01-25 22:17:58 Gnite 2019-01-25 22:18:26 <_ikke_> nite 2019-01-26 00:52:09 would be really nice if my serial consoles worked propery :( 2019-01-26 02:38:54 lol i just checked if any of my outstanding old PRs got any new releases, and then i hit perfect timing 2019-01-26 02:38:58 https://i.imgur.com/XBMTNMN.png 2019-01-26 02:45:11 oh, so like that time I bumped spampd like a day after getting it into testing/ 2019-01-26 03:27:29 haha, this is so messed up, trying to get tests to work on one of python packages, but it requires missing dependency. I get to that test dependency, and it requires another test dependency 2019-01-26 03:28:00 at least good its not as bad as most of java and npm world 2019-01-26 03:28:33 (well, maven, sbt and npm) 2019-01-26 03:29:44 wew maven 2019-01-26 17:22:26 ping fcolista - lxd codegen for lxc is horribly broken on musl; the fix just got merged (https://github.com/lxc/lxd/pull/5435), bug in question is https://github.com/lxc/lxc/issues/2798 - can we cherry pick the patch into r3, or do you want to wait until 3.9.1 / 3.10.0? (given the severity of the bug) 2019-01-26 17:22:51 (also there might be an lxc check merged soon (?), but I'm not sure on the specifics of that one) 2019-01-26 20:19:25 oof, need to bump traefik 2019-01-26 20:23:34 should probably get some non-amd64 env sorted so I can test/fix things too 2019-01-26 22:00:51 i have fixed the grub + zfs root issue 2019-01-26 22:00:57 (i think) 2019-01-26 22:01:47 i think we may want fix initramfs-init to run blkid to detect filesystem type if rootfstype is missing 2019-01-26 22:03:34 ACTION scratches head 2019-01-26 22:03:50 nlplug-findfs is interfacing blkid anyways.. 2019-01-26 22:27:48 <_ikke_> clandmeter: pkgs.a.o allows you to search for any arch, but once you selected one, you cannot got back 2019-01-26 22:29:56 _ikke_, yes, if you have time please add an issue and ill see if i can look into it. 2019-01-26 22:32:25 <_ikke_> ^ 2019-01-26 22:51:02 clandmeter, does it makes sense to backport https://github.com/alpinelinux/aports/pull/6147 it looks like really security affected 2019-01-26 22:56:28 andypost, hmm 2019-01-26 22:57:18 They don't update minors I guess 2019-01-26 23:35:13 how to local reindex ~/packages/{main,community}/arch APKINDEX.tar.gz 2019-01-26 23:35:38 s/local reindex/reindex local/ 2019-01-26 23:35:38 mps meant to say: how to reindex local ~/packages/{main,community}/arch APKINDEX.tar.gz 2019-01-26 23:38:39 mps, if this paths in etc/apk/repos then as usual 2019-01-26 23:39:39 yes 2019-01-26 23:40:35 how? how 'as usual', can't remember I did that already 2019-01-26 23:42:38 mps, I mean apk update 2019-01-26 23:44:00 aha, no, my question is how to reindex /home/USER//packages/{main,community}/archXX/APKINDEX.tar.gz file after delete some file from these dirs 2019-01-27 00:03:51 apk index 2019-01-27 00:04:03 `apk index -o APKINDEX.tar.gz *.apk` 2019-01-27 00:04:40 `abuild-sign -k APKINDEX.tar.gz` 2019-01-27 00:07:00 p4Wv1qn095FW: thanks 2019-01-27 04:43:58 hm 2019-01-27 04:44:24 so why are traefik tests failing so much on non-x86_64 2019-01-27 04:53:48 andypost: 2019-01-27 04:54:11 ye i added depends recently so they all went into testing. Tho, are they ready for community? or is there set of reqs for it? 2019-01-27 04:59:11 also u, armhf or armv7? 2019-01-27 04:59:13 uh* 2019-01-27 06:15:11 dimon222: I think they ready to be moved 2019-01-27 09:18:52 we really need a method of cleaning up users when removing packages btw 2019-01-27 09:20:16 couldn't apk do that, if they're defined in the package meta instead of pre-install? 2019-01-27 09:33:15 I made a booboo, can someone merge 6170 real quick? 2019-01-27 12:33:05 ncopa, tmhoang, i added modloop signing support for netboot. 2019-01-27 12:33:56 ncopa, not sure we want to add it to other images? 2019-01-27 16:16:28 clandmeter: It seems you put modloop_sign=yes to profile_base(), not profile_netboot() ? 2019-01-27 17:41:56 is WSL offically supported? 2019-01-27 17:43:07 tmhoang, uhm yed you are right 2019-01-27 17:43:52 Lets see what ncopa thinks of it. 2019-01-27 17:44:09 well you already did by accident haha 2019-01-27 17:44:17 We can move it to netboot only 2019-01-27 17:44:26 let's just silently add the remaining profile_netboot() ... 2019-01-27 17:44:27 Yes it was an old commit 2019-01-27 17:44:58 yeah understood 2019-01-27 17:45:00 Isn't it inherited? 2019-01-27 17:45:17 only netboot not inherited 2019-01-27 17:45:28 all other profiles call profile_base 2019-01-27 17:45:58 It has been a really crappy day today 2019-01-27 17:46:09 I should have looked closer 2019-01-27 17:46:19 it's rest day, take it easy 2019-01-27 17:47:04 It's not under my control this day today 2019-01-27 17:47:25 family or work ? 2019-01-27 17:47:52 Family... 2019-01-27 17:48:11 enjoy it :)) 2019-01-27 17:48:27 Hospital in and out 2019-01-27 17:48:36 aw I'm sorry 2019-01-27 17:48:46 I thought family meetings, sort of 2019-01-27 17:49:27 Np 2019-01-27 17:49:36 I think i know what happens 2019-01-27 17:49:49 Netboot profile is newer 2019-01-27 17:50:30 do you want to do it now or later ? 2019-01-27 17:50:48 Later 2019-01-27 17:50:56 No pc now 2019-01-27 17:51:02 Just mobile 2019-01-27 17:51:20 that's what I think. No worry, take you time. 2019-01-27 17:51:50 when building packages: PIE or not on Alpine by default or case by case 2019-01-27 17:52:20 Pie should be on by default 2019-01-27 17:52:49 ah we're here 2019-01-27 17:53:28 If it is possible, ok. But for some which is hard or impossible what to do? try hard or discard package from Alpine 2019-01-27 23:16:35 how to make package to depends on it's previous version in makedepends 2019-01-27 23:16:58 i dont think its possible 2019-01-27 23:18:35 huh, how then to solve that problem, by some scripting in prepare() function? 2019-01-27 23:51:56 mps: do you mean package2 (version 2.x) depends on package1 (version 1.x) ? 2019-01-27 23:53:38 yes, something like that 2019-01-27 23:55:11 actually package name is the same, but depends on it's previous version 2019-01-27 23:57:35 maybe build static version of the package (anyway it need to be static) and then next release depends on that previously built static version 2019-01-27 23:58:00 I'm talking about crystal language, btw 2019-01-28 00:05:23 mps: I think you specifically need to create 2 packages : crystal1, and crystal2. 2019-01-28 00:05:55 I believe jirutka has been doing some work to make crystal working on Alpine 2019-01-28 00:06:14 please ask him or check out his github page for his personal repository 2019-01-28 00:06:21 yes, he is, but he is not active much now 2019-01-28 00:07:16 he made static version and packaged it in tar.gz to be downloaded for next release build 2019-01-28 00:09:07 it's a pity he is not active here, he did a good work 2019-01-28 00:09:51 I'm just trying to continue where he stopped 2019-01-28 00:16:01 tmhoang: I upgraded llvm, clang and lld to version 6 (in private repos) and now trying to test it with crystal and rust on aarch64 and armv7 2019-01-28 00:27:49 mps: nice! Not my expertises but I'd keep track 2019-01-28 00:30:14 tmhoang: ok, thanks for hints, good night, it's late here :) see you 2019-01-28 00:31:26 late here too :D see you tomorrow. nite. 2019-01-28 07:51:39 mps, look at go 2019-01-28 11:44:21 <_ikke_> clandmeter: https://github.com/alpinelinux/aports/pull/6174 2019-01-28 11:44:32 <_ikke_> fix for redo, hope that it works 2019-01-28 12:09:17 _ikke_, doesnt seem to fix it. 2019-01-28 12:39:37 <_ikke_> :( 2019-01-28 12:40:22 <_ikke_> d'oh, now I didn't have to bump pkgrel :D 2019-01-28 12:42:33 <_ikke_> clandmeter: Can it be that /dev/tty exists, but it cannot write to it? 2019-01-28 12:42:50 i htink ncopa already mentioned it existed 2019-01-28 12:43:21 but you have access not me :p 2019-01-28 12:44:10 <_ikke_> Doesn't the existence of /dev/tty depend on whether a tty is available for a process? 2019-01-28 12:47:23 i think it always exist 2019-01-28 12:47:31 but it refers to another device 2019-01-28 12:47:46 /dev/pts/X 2019-01-28 12:47:49 <_ikke_> ah, ok 2019-01-28 12:48:02 which is your tty 2019-01-28 12:48:16 not sure how it exactly works 2019-01-28 12:48:25 <_ikke_> But background services don't have one, right? 2019-01-28 12:48:34 <_ikke_> there is no corresponding tty 2019-01-28 12:48:39 thats possible yes 2019-01-28 12:49:05 so the /dev/tty probably exist but not the /dev/pts/X (im guessing here) 2019-01-28 12:50:00 <_ikke_> Ok, I'll try to test it lcoally in a background process to see if I can reproduce it and provide a proper patch 2019-01-28 12:50:01 it sounds like a bug from upstream 2019-01-28 12:50:18 <_ikke_> Yeah, it's an assumption that /dev/tty is always available 2019-01-28 12:50:38 did you report it? 2019-01-28 12:50:53 <_ikke_> clandmeter: they have issues turned off :) 2019-01-28 12:51:07 <_ikke_> so not really a way to report. I'd probably have to mail or provide a PR 2019-01-28 12:51:30 a project without issues, thats my kind of project :) 2019-01-28 12:51:41 <_ikke_> heh 2019-01-28 12:59:18 _ikke_: is this 'redo' some of DJB's tools? 2019-01-28 12:59:43 <_ikke_> mps: It's an implementation of it, yes 2019-01-28 12:59:50 <_ikke_> afaik, djb never implemented it himself 2019-01-28 13:00:07 _ikke_: what do you mean by not writable? 2019-01-28 13:00:48 eh, then I understand you. expect unexpectable from his tools 2019-01-28 13:00:57 <_ikke_> AinNero: IOError: [Errno 6] No such device or address: '/dev/tty' 2019-01-28 13:01:23 <_ikke_> mps: it's just during testing that it fails 2019-01-28 13:01:34 <_ikke_> mps: on the build server 2019-01-28 13:01:55 and locally it works? 2019-01-28 13:02:04 oi 2019-01-28 13:02:04 <_ikke_> AinNero: that happens when you do open('/dev/tty', 'w') in python on the build server 2019-01-28 13:02:09 <_ikke_> mps: yes, and in travis as well 2019-01-28 13:02:31 <_ikke_> I think it fails when it's run by a background service / daemon 2019-01-28 13:02:49 yep, when tty is not availalbe for that process 2019-01-28 13:02:50 <_ikke_> mqtt-exec runs the build process on the builders 2019-01-28 13:03:28 probably, could it be patched to skip that in 'make test' or how it's check work 2019-01-28 13:04:03 <_ikke_> mps: yes, I tried that, but I assumed /dev/tty didn't even existed, but apprently it does 2019-01-28 13:04:32 I'm looking it's fails in #alpine-commits and few times tempted to try to fix, but ceased when look in implementation 2019-01-28 13:04:33 _ikke_: did you find this? 3 2019-01-28 13:04:46 https://stackoverflow.com/a/47714227 2019-01-28 13:05:26 <_ikke_> I don't think it has to do with su 2019-01-28 13:05:38 lack pof controlling terminal 2019-01-28 13:05:44 <_ikke_> yes, that's the case 2019-01-28 13:05:52 <_ikke_> Which we basically already concluded 2019-01-28 13:06:09 and it shouldnt need it 2019-01-28 13:06:30 aside from what clandmeter just said, where should mqtt-exec even get a controlling terminal from? 2019-01-28 13:06:45 <_ikke_> yes, that's all clear 2019-01-28 13:06:53 <_ikke_> I understand the problem 2019-01-28 13:07:07 that was more meant as a question, sorry 2019-01-28 13:07:27 <_ikke_> a background process doesn't have one, that's clear 2019-01-28 13:08:09 i would just send an email to their ml, seems active. (or fix it yourself thats also fine :) 2019-01-28 13:09:46 _ikke_: yes, that is true, problem is that it expect to be run from terminal 2019-01-28 13:10:09 _ikke_, have you tried the provided setup.py? 2019-01-28 13:10:16 <_ikke_> mps: which is most likely the case for redo 2019-01-28 13:10:39 <_ikke_> clandmeter: honestly, I haven't 2019-01-28 13:10:49 <_ikke_> Not sure if it would solve this issue. It would probably run the same code 2019-01-28 13:11:07 yes without the tests :) 2019-01-28 13:11:42 <_ikke_> Well, we can run without the tests ourselfs as well 2019-01-28 13:11:48 <_ikke_> just use !check 2019-01-28 13:11:55 <_ikke_> and remove the check function 2019-01-28 13:12:00 _ikke_: right, if check works from terminal maybe disable check in APKBUILD 2019-01-28 13:12:35 eh, we have similar thinking 2019-01-28 13:13:09 disable it and report it. you can enable it ones they fix it. 2019-01-28 13:13:19 <_ikke_> nod 2019-01-28 13:20:24 _ikke_, there is another issue with this aport 2019-01-28 13:20:36 <_ikke_> do tell 2019-01-28 13:20:50 you fix the permissions in check 2019-01-28 13:22:04 i think i had an issue that abuild couldnt clean leftovers 2019-01-28 13:23:06 yep 2019-01-28 13:23:25 "if" the tests fail late it will keep leftovers in src that are readonly 2019-01-28 13:23:34 abuild wont be able to fix it 2019-01-28 13:23:46 fix as in abuild clean 2019-01-28 13:24:10 its a similar issue im having with new go modules 2019-01-28 13:33:37 <_ikke_> So how do we properly deal with that? 2019-01-28 13:35:05 make sure abuild clean can clean :) 2019-01-28 13:35:51 <_ikke_> hehe 2019-01-28 13:35:54 not sure there is a proper solution from apkbuild 2019-01-28 13:38:09 probably need to add some abuild option to make it chmod the src dir 2019-01-28 13:40:58 offtopic, when or will be (ever) php v7.3 used for upcomming v3.9? 2019-01-28 13:42:01 <_ikke_> ViltusVilks: I think it's too late for 3.9 2019-01-28 13:42:56 so, not in the near future? 2019-01-28 13:43:16 what is it now? 2019-01-28 13:43:25 <_ikke_> 7.2.14 2019-01-28 13:43:39 i have idea how versioning works in php 2019-01-28 13:43:51 better ask andypost 2019-01-28 13:43:52 <_ikke_> 7.3 has some breaking changes 2019-01-28 13:43:57 yep, php@docker has own 7.3.1@v3.8 image 2019-01-28 13:44:33 ok, no problem, will stick to custom build. 2019-01-28 13:48:34 @ViltusVilks there's PR on hold for post 3.9 upgrade, basically not all php extensions ready for 7.3 and a lot of apps does not work with 7.3 for example phpldapadmin 2019-01-28 14:20:44 do we still use split packages for python packages which only support python 3? e.g. py-foobar & py3-foobar, vs just py3-foobar 2019-01-28 14:25:08 i think we dont 2019-01-28 14:26:43 there's not a lot of consistency in the python packages tbh 2019-01-28 14:27:01 heh 2019-01-28 14:27:02 I think using split packages would be nice for making everything consistent 2019-01-28 14:27:13 i have been working on some, its a mess 2019-01-28 14:27:44 I've settled on this template personally https://git.sr.ht/~sircmpwn/sr.ht-apkbuilds/tree/master/sr.ht/py-tinycss2/APKBUILD 2019-01-28 14:28:05 we have some info on the wiki 2019-01-28 14:28:06 gah mixed tabs and spaces 2019-01-28 14:28:10 it looks similar 2019-01-28 14:28:23 except you switch builddirs 2019-01-28 14:29:07 at some point I need to upstream a bunch of python packages I made for sr.ht 2019-01-28 14:29:16 I think when I do I'll start a discussion about nailing down the conventions 2019-01-28 14:29:21 and make a list of packages to fix 2019-01-28 14:29:49 its nice if they have proper depends 2019-01-28 14:29:59 thats what i bumped into a bit last few days 2019-01-28 14:30:14 like no depends at all. 2019-01-28 14:32:46 morning 2019-01-28 14:32:49 or good day 2019-01-28 14:32:58 <_ikke_> hi 2019-01-28 14:33:05 olla 2019-01-28 14:33:34 ncopa, before you tag any rel, please check modloop signing. 2019-01-28 14:33:54 my plan for today is: update rpi kernel and write release note for 3.9.0 2019-01-28 14:34:05 ...and check modloop signing 2019-01-28 14:34:09 :p 2019-01-28 14:34:16 i guess we need make another rc 2019-01-28 14:34:16 its enabled now 2019-01-28 14:34:28 but i think not for netboot as its independed 2019-01-28 14:34:33 and added later as my pr 2019-01-28 14:34:55 so we could use signing for all or move it to netboot. 2019-01-28 14:35:00 whatever you prefer 2019-01-28 14:54:37 i guess it does not hurt to sign it 2019-01-28 14:55:35 where is the signature? 2019-01-28 14:56:32 https://github.com/alpinelinux/aports/pull/4673 2019-01-28 14:57:27 /var/cache/misc 2019-01-28 14:59:07 ok, its embedded in the initramfs 2019-01-28 14:59:18 yes ofc 2019-01-28 15:06:17 clandmeter: have you tested to modify the modloop so signature fails? 2019-01-28 15:06:47 will it actually fail or will it continue and load untursted kernel modules? 2019-01-28 15:07:05 good question 2019-01-28 15:07:11 i have tested things here and it seems to work 2019-01-28 15:07:22 i tested it long time ago 2019-01-28 15:07:29 ok 2019-01-28 15:08:10 can you modify the modloop without breaking it? 2019-01-28 15:10:15 well, that sort of the point, check if its broken 2019-01-28 15:10:26 flipping a single bit 2019-01-28 15:28:19 where's the code that the build boxen run? 2019-01-28 15:31:20 ddevault, lua-aports 2019-01-28 15:31:25 and https://git.alpinelinux.org/aports/tree/main/aports-build/aports-build 2019-01-28 15:31:32 tyvm 2019-01-28 15:31:52 https://git.alpinelinux.org/lua-aports/tree/bin/buildrepo.lua 2019-01-28 17:05:10 what is the purpose of noarch if all of the packages are dropped into the $(uname -m) dir on the mirror? 2019-01-28 17:11:29 it signals for which arch it is gonna be available. 2019-01-28 17:11:52 you can have all or an explicit list of target archs 2019-01-28 17:14:06 but why is noarch distinct from all 2019-01-28 17:20:38 ddevault: from /usr/bin/abuild: warning "No arch specific binaries found so arch should probably be set to \"noarch\"" 2019-01-28 17:21:06 this isn't helpful -_- 2019-01-28 17:21:12 I presume that you understand what that means 2019-01-28 17:22:19 mps: the question was why, "because there's a warning" doesn't seem like a good answer :) 2019-01-28 17:22:22 well, I'm not author of this, but I see it as for packages which doesn't have arch specific binaries (i.e. script) it could be set to noarch 2019-01-28 17:22:50 ddevault: I don't know myself, but I suspect it may have something to do with implied dependencies and scanning 2019-01-28 17:23:06 e.g if it's noarch, don't bother stripping / checking what libs are needed / etc (which is normally done) 2019-01-28 17:24:02 gotcha 2019-01-28 17:25:59 SpaceToast: also I don't know, but to me looks it is for packages without binaries 2019-01-28 17:26:20 the very word "noarch" kind of implies that :) 2019-01-28 17:26:34 the question was about why it exists, not what it is per se 2019-01-28 17:26:37 don't worry about it too much 2019-01-28 17:26:45 always had this mental image about it 2019-01-28 17:27:24 I think debian also have something like that 2019-01-28 17:32:11 for example packaged CSS, HTML, some docs etc.. files in apk. Final explanation should come from the author of abuild at the end 2019-01-28 17:34:29 noarch was supposed to share packages for all arches but builders does not yet support or use this, yet 2019-01-28 17:36:20 eh, my wild guess was wrong then 2019-01-28 17:42:38 before: https://git.sr.ht/~sircmpwn/sr.ht-apkbuilds/tree/73476f4260c7d818682639b0379d52f72cce2916/sr.ht/buildall.yml 2019-01-28 17:42:50 after: https://git.sr.ht/~sircmpwn/sr.ht-apkbuilds/tree/master/build.yml + https://git.sr.ht/~sircmpwn/sr.ht-apkbuilds/tree/master/submit-builds 2019-01-28 17:42:54 much better 2019-01-28 18:28:52 is something wrong with the aports mailing list? 2019-01-28 18:29:09 I've sent several patches in the last few days which aren't appearing 2019-01-28 18:29:23 <_ikke_> hmmm 2019-01-28 18:29:29 <_ikke_> clandmeter: ^? 2019-01-28 18:29:57 Appearing where? 2019-01-28 18:30:03 the online archives or patchwork 2019-01-28 18:30:11 List or pw? 2019-01-28 18:30:14 either 2019-01-28 18:30:16 both? 2019-01-28 18:30:18 neither? 2019-01-28 18:30:19 Or both 2019-01-28 18:30:21 Ok 2019-01-28 18:30:31 List has issues i think 2019-01-28 18:30:53 I got an email says it's holding mails 2019-01-28 18:31:30 My mails 2019-01-28 18:32:44 I can check later 2019-01-28 18:32:54 It's not managed by me 2019-01-28 18:33:34 fun fact: I am partway through packging lists.sr.ht for Alpine Linux as we speak 2019-01-28 18:34:36 getting off of GNU mailman sounds like a good idea to me regardless (whether it's to lists.sr.ht or something else) - just today we had a user resend something because it didn't immediately show up 2019-01-28 18:34:48 but this sounds like a topic for #alpine-infra :) 2019-01-28 19:02:03 we dont use gnu mailman, its mlmmj 2019-01-28 19:02:27 but yeah, its not optimal 2019-01-28 19:15:27 rc6 is out 2019-01-28 19:27:54 ncopa: can I send a few aports patches directly to you considering the mailing list outage? 2019-01-28 19:44:09 sure 2019-01-28 19:44:45 cheers 2019-01-28 19:53:06 ddevault: can you please report your issues with the mailing list to bugs.alpinelinux.org? 2019-01-28 19:53:11 sure 2019-01-28 19:53:14 and include the error message you get 2019-01-28 19:53:23 no error message, my emails disappear into a black hole 2019-01-28 19:53:48 can you include what email you send from and what you have in the "to" field 2019-01-28 19:53:53 sure 2019-01-28 19:53:53 and maybe a date 2019-01-28 19:53:59 so we can search the logs 2019-01-28 19:55:34 oh shit it's on my end 2019-01-28 19:55:36 bugger 2019-01-28 19:55:52 y'all outta add TLS support to your MTA 2019-01-28 19:56:22 to jump to llvm7 from llvm5, or to step to llvm6, is the question which don't let me to sleep last two days 2019-01-28 19:56:45 mps: I am, as usual, in favor of latest = greatest :) 2019-01-28 19:57:09 ddevault : same as this? https://bugs.alpinelinux.org/issues/9573 2019-01-28 19:57:29 aye 2019-01-28 19:57:36 mps: i would also want aim for llvm7 2019-01-28 19:57:37 SpaceToast: I'm too, but don't know if something need llvm6 2019-01-28 19:57:47 though if you enforce STARTTLS on your mail server you're asking for deliverability issues 2019-01-28 19:58:03 you here being me, that is 2019-01-28 19:58:29 I'm leaning toward llvm7, for now nothing depends on llvm6 2019-01-28 19:58:50 at least I know 2019-01-28 19:59:18 btw, llvm5 should stay 2019-01-28 19:59:33 ddevault: well it depends, incoming smtp might make sense to only strongly suggest tls, but for the submission port... 2019-01-28 19:59:44 how exactly does "bad TLS" = silent black hole though? 2019-01-28 19:59:48 some packages couldn't be built with llvm7 2019-01-28 19:59:56 SpaceToast: because the mail gets stuck up in my postfix queue 2019-01-28 19:59:59 and it hasn't told me about it 2019-01-28 20:00:09 :) 2019-01-28 20:00:15 we have starttls 2019-01-28 20:00:20 on the new box :) 2019-01-28 20:00:59 ah, postfix ;) 2019-01-28 20:01:01 okay, fixed on my box and queue flushed 2019-01-28 20:01:04 sorry for the noise 2019-01-28 20:01:57 you pushed the button twice :) 2019-01-28 20:02:23 ah 3 times even 2019-01-28 20:03:24 3rd time when preparing the ill-fated bug report 2019-01-28 20:03:28 cause ncopa wanted a date 2019-01-28 20:04:48 just blame me... :) 2019-01-28 20:04:59 blame me, I keep pushing for TLS everything :D 2019-01-28 20:32:01 rc6 already 2019-01-28 20:32:05 <_ikke_> aye 2019-01-28 20:32:07 <_ikke_> goes fast 2019-01-28 20:32:36 lets hope i'll have my testing rig ready for 3.10 then 2019-01-28 20:51:06 i think the v3.9 oven is getting on temperature 2019-01-28 20:51:40 i learned to use expect to automatically test diskless & installation of alpine via qemu serial 2019-01-28 20:52:22 still working out a proof of concept 2019-01-28 20:55:45 ok, I will archive llmv6, lld6, lldb6 and clang6 and try to build llvm7 and rest of it's batteries 2019-01-28 21:05:44 i think i just need to write the release notes 2019-01-28 21:06:22 and do the release 2019-01-28 21:06:27 will try do it tomorrow 2019-01-28 21:06:33 not convenient from where i am now 2019-01-28 21:10:00 there's no python upgrade in 3.9 right 2019-01-28 23:29:42 ncopa: I have looked into czmq code. It must be something with SHA1 functions on s390x. Tried Ubuntu, also same failure. I guess we gotta remove czmq support for rsyslog on s390x for at least 3.9.0. I gotta send a patch for hwclock on s390x to aports/openrc ... 2019-01-29 01:11:55 i just saw WIP openjdk9 in works. Is worth bothering or better simply wait Corretto 11 to get released? 2019-01-29 01:12:29 there are so many java implementations now it's crazy 2019-01-29 01:12:50 well, oracle started it, now they will enjoy :D 2019-01-29 01:16:07 i actually googled but didn't find much, is there really many? most of them are retired 2019-01-29 01:16:18 its just icedtea and newly arriving corretto 2019-01-29 01:17:09 icedtea is the webstart thing afaik 2019-01-29 01:17:42 you got openjdk, oracle jdk, IBM thing, amazon thing (corretto), libart (google's implementation of the API for android), the new oracle thing (static linking the interpretor) 2019-01-29 01:17:54 gcj is retired, at least, but you used to have that too 2019-01-29 01:41:01 thinking of oracle's project portola? 2019-01-29 01:41:30 no, I'm thinking of the new official non-enterprise way to distribute applications 2019-01-29 01:41:32 let me try and find it 2019-01-29 01:49:55 danieli: I'm not sure this is the specific one, but https://www.oracle.com/technetwork/java/javase/javaclientroadmapupdate2018mar-4414431.pdf (white paper) + https://docs.oracle.com/en/java/javase/11/tools/jlink.html 2019-01-29 01:50:07 I'm not sure if jlink is the actual thing, but if not the actual thing builds on it 2019-01-29 01:50:12 all right, gotcha 2019-01-29 01:50:19 oracle want you to bundle a partial set of the jre with your application to make it "standalone", basically 2019-01-29 01:50:31 and are deprecating / blocking uses other than that in the future (outside of servers) 2019-01-29 01:50:54 (tl;dr oracle found out about static linking and thought it was awesome, but then made it non-optional :) ) 2019-01-29 08:14:24 ncopa: I have looked into czmq code. It must be something with SHA1 functions on s390x. Tried Ubuntu, also same failure. I guess we gotta remove czmq support for rsyslog on s390x for at least 3.9.0. I gotta send a patch for hwclock on s390x to aports/openrc ... 2019-01-29 08:17:11 tmhoang, cant you just disable that plugin? 2019-01-29 08:18:42 clandmeter: yeah, that what I would like to do: disable czmq plugin in syslog for s390x only. 2019-01-29 08:18:54 other arch seem to work and there're people who need it 2019-01-29 08:19:04 btw, that channel is not private :p 2019-01-29 08:20:14 I wanted to look closer on SHA1 functions in czmq last night but needed to push the tod clocksource commits out (raise issues on openssl_client). I will try to look more today but in case I couldn't make it, it's better to disable for 3.9. 2019-01-29 08:20:22 thanks, joining again haha 2019-01-29 09:36:15 could someone repost the link to the testing matrix? 2019-01-29 09:36:25 for the rc's ? 2019-01-29 09:39:08 testing matrix? 2019-01-29 09:39:41 someone had a web document outlining the cases we should test for the RC's 2019-01-29 09:39:59 ok, i didnt see it sorry. 2019-01-29 09:40:32 yesterday i wrote an PoC of an expect script that automatically installs alpine via serial console in a qemu VM 2019-01-29 09:40:58 i see potential to use this to automatically test common usecases 2019-01-29 09:41:32 maybe you can find it on the irclogs? 2019-01-29 09:41:47 https://dev.alpinelinux.org/irclogs/ 2019-01-29 09:43:42 https://imgur.com/a/e56haN0 this one? 2019-01-29 09:44:14 yeah, just found it myself 2019-01-29 13:11:53 ncopa: regarding czmq s390x 2019-01-29 13:11:55 https://github.com/alpinelinux/aports/pull/6187 2019-01-29 15:00:44 anyone know why we have toolchains named with 'alpine' word and not 'unknown'. we have x86_64-alpine-linux-musl-gcc instead of x86_64-unknown-linux-musl-gcc 2019-01-29 15:07:20 mps: that slot is the "vendor" space, unknown is the default but you can always put the ... vendor name int it 2019-01-29 15:07:27 in this case, it's alpine 2019-01-29 15:13:13 SpaceToast: I know that, but would like to hear rationale why Alpine added vendor? 2019-01-29 15:13:32 because we are the toolchain vendor? 2019-01-29 15:13:36 ^ 2019-01-29 15:14:25 could be, but I'm not sure that is justified 2019-01-29 15:15:14 would be nice to hear rationale from the author of the decision :) 2019-01-29 15:17:42 problem could be with upstream author of toolchains, they have to add a lot of 'targets' if every one who feels self as 'vendor' want to send request to upstream to be added 2019-01-29 15:17:58 llvm is one example, rust is another one 2019-01-29 15:18:29 well, upstream rust (e.g "rustup"'s available stuff) is the vendor for the toolchains you get from them 2019-01-29 15:18:35 so they choose to put "unknown" 2019-01-29 15:18:51 x86_64-VENDOR-linux-musl is a generic target - the vendor tag really doesn't do much 2019-01-29 15:18:58 btw, I'm not against to have alpine as a vendor, just would like to hear rationale, nothing more 2019-01-29 15:19:02 it's common to see "unknown" there, but also "pc", "gentoo", etc :) 2019-01-29 15:19:20 it (at least SHOULD) matters a lot less than you seem to think 2019-01-29 15:19:33 ye 2019-01-29 15:19:44 compiler touples aren't a too reliable architecture identifier 2019-01-29 15:20:13 AinNero: absolutely true 2019-01-29 15:20:42 but is a some kind of mess 2019-01-29 15:20:51 the vendor isn't unknown 2019-01-29 15:22:25 'rustc --print target-list | wc -l' gives 109 2019-01-29 15:23:26 uh huh? 2019-01-29 15:23:37 llvm is a native cross-compiler, that's to be expected 2019-01-29 15:24:41 sorry, previous was overnumbered, better is such: 'rustc --print target-list | grep x86_64 | wc -l' which gives just 22 2019-01-29 15:26:04 i can only think of 4 matching x86_64 2019-01-29 15:26:21 except for the vendor sting, which is just arbitrary 2019-01-29 15:28:06 AinNero: look here: https://tpaste.us/wjg9 2019-01-29 15:29:01 hm, alpine is there, but the ones for debian and redhat are missing 2019-01-29 15:29:59 good notice, but this alpine is in alpine aports patches and not upstream 2019-01-29 15:30:09 i see 2019-01-29 20:14:16 Im about to tag v3.9.0 release 2019-01-29 20:14:28 any volunteer to help me write the release notes meanwhile? 2019-01-29 20:15:13 <_ikke_> I have time 2019-01-29 20:15:22 <_ikke_> Just need to know what to write about 2019-01-29 20:15:28 <_ikke_> new kernel probably 2019-01-29 20:15:33 <_ikke_> armv7 2019-01-29 20:15:54 copy the 3.8.0 release notes (md source) 2019-01-29 20:16:10 openssl instead of libressl as system ssl 2019-01-29 20:16:14 kernel 4.19 2019-01-29 20:16:17 whats going into 3.9, 4.19? 2019-01-29 20:16:34 yes 4.19, because its lts 2019-01-29 20:16:39 roger 2019-01-29 20:16:46 we need mention armv7 yes 2019-01-29 20:17:05 ncopa: would you mind taking a look at my tod clocksource for s390x ? 2019-01-29 20:17:09 then i think things that needs attention when upgrade 2019-01-29 20:17:10 that is essential 2019-01-29 20:17:14 tmhoang_ ugh.. 2019-01-29 20:17:15 its late... 2019-01-29 20:17:25 oh, I have a question about that actually, what should it be, armv7 or armhf? since they're the same thing really... 2019-01-29 20:17:28 im officially on vacation and the 3.9 release is 2 months late... 2019-01-29 20:17:41 should have had the s390x fixes 2 months ago 2019-01-29 20:17:44 understood 2019-01-29 20:17:49 or with rc1 2019-01-29 20:18:04 the fixes needs some work too i think 2019-01-29 20:18:13 yeah I was relocating for job at the time 2019-01-29 20:18:18 im not to happy with adding arch specific if ...else 2019-01-29 20:18:22 understood 2019-01-29 20:19:00 what i was thinking is that we can probably do *tool specific* if ... else 2019-01-29 20:19:11 or case $tool in ... 2019-01-29 20:19:29 and have a single if s390x then use tool X 2019-01-29 20:19:30 basically without it installing from netboot on any s390x hypervisor would fail and instead user needs an extra step to run things like : ntp -q -n -p pool.ntp.org before running setup-alpine 2019-01-29 20:19:54 understand 2019-01-29 20:20:26 similar problem with rpi and some arm machines with no rtc 2019-01-29 20:20:31 Okay I'd take the hit from this if any 2019-01-29 20:20:46 okay I would updat the wiki then 2019-01-29 20:20:47 <_ikke_> ncopa: shortlog starting from 3.8.2 or 3.8.0? 2019-01-29 20:20:56 hope we could do it in 3.9.1, soon. 2019-01-29 20:20:56 from 3.8.0 2019-01-29 20:21:18 wait with shortlog, i always do that after the tag 2019-01-29 20:21:27 in case there are last second changes 2019-01-29 20:21:43 tmhoang_: yeah, i thnk we could do it for 3.9.x 2019-01-29 20:21:50 okay, got you 2019-01-29 20:21:56 i have another idea how to work around missing rtc 2019-01-29 20:22:15 nice 2019-01-29 20:22:24 <_ikke_> ncopa: ok 2019-01-29 20:22:59 in initramfs, if some file (or / dir?) is newer than current time, then adjust then assume clock is broken and set current time to the tested dir (or file) 2019-01-29 20:23:23 that way we set the time to the time of creation of the initramfs 2019-01-29 20:23:37 which should not be many years off 2019-01-29 20:23:54 swclock 2019-01-29 20:24:04 right 2019-01-29 20:24:28 clandmeter: what is the source that swclock get feeds from ? 2019-01-29 20:24:39 i dont know if that is enough to get the s390x booted enough to get ntp started 2019-01-29 20:24:43 I mean we can do this clock thing later :D 2019-01-29 20:24:49 Some file from openrc iirc 2019-01-29 20:24:53 i think its from openrc 2019-01-29 20:25:01 same concept 2019-01-29 20:25:21 Init already sets it if missing rtc 2019-01-29 20:25:41 tmhoang: i think you should try get the patch upstream into openrc 2019-01-29 20:25:53 they can help you get it right 2019-01-29 20:25:55 But not sure it covers all hws 2019-01-29 20:26:04 :) yeah I know swclock from openrc but my question is it getting the clock from kernel (which is through host machine down to hypervisor, down to guest kernel) (like s390x) or somewhere 2019-01-29 20:26:30 ncopa: I only have legal clearance for Alpine :D and it took weeks for me to get Alpine's 2019-01-29 20:26:38 ugh! 2019-01-29 20:26:40 :D 2019-01-29 20:26:53 "welcome to ibm" i suppose 2019-01-29 20:27:07 but I will ask upper management. 2019-01-29 20:27:18 tmhoang: are you allowed to send bug reports? 2019-01-29 20:27:18 Commit it to Alpine and I'll upstream it ;) 2019-01-29 20:27:45 i'd start with bug report explaining the problem. 2019-01-29 20:27:55 ncopa: we can do it later :) 2019-01-29 20:28:16 "on s390x vm there are no rtc, instead this and this tool is needed to set the time" 2019-01-29 20:28:18 ok 2019-01-29 20:28:31 agree 2019-01-29 20:29:02 lets do v3.9.0 now 2019-01-29 20:29:05 agreed 2019-01-29 20:29:38 <_ikke_> trying to find siginificant updates 2019-01-29 20:29:56 gcc update ? 2019-01-29 20:30:22 <_ikke_> 8.2.0? 2019-01-29 20:30:27 Lxc 2019-01-29 20:30:36 I missed the gcc + gcj migration ... 2019-01-29 20:30:36 <_ikke_> 3.1 2019-01-29 20:31:03 2 to 3 2019-01-29 20:31:13 yeah 2019-01-29 20:31:24 anything that require special attention when upgrade 2019-01-29 20:31:31 Is big update 2019-01-29 20:31:34 for example gcc 8 update 2019-01-29 20:31:44 i dunno if postgresql was updated major version? 2019-01-29 20:31:46 i think it was 2019-01-29 20:31:54 should be mentioned 2019-01-29 20:31:58 no firefox or chromium on aarch64 2019-01-29 20:32:08 Singed modloop 2019-01-29 20:32:10 <_ikke_> postgresql 10.5 to 11.1 2019-01-29 20:32:12 Signed 2019-01-29 20:32:20 clandmeter> Singed modloop <<<<---- 2019-01-29 20:32:34 On mobile... 2019-01-29 20:32:45 no firefox on arm* due to lack of rust 2019-01-29 20:32:48 <_ikke_> Anything under "NOTEWORTHY NEW PACKAGES" 2019-01-29 20:33:13 hum.. i dont know 2019-01-29 20:33:22 clandmeter: modloop > typo :D 2019-01-29 20:33:27 <_ikke_> gcc went from 6.x to 8.x 2019-01-29 20:33:39 signed modloop is pretty nice to mention I guess 2019-01-29 20:33:45 <_ikke_> I added it 2019-01-29 20:34:04 yes, languages with major version should be mentioned 2019-01-29 20:34:11 php maybe? 2019-01-29 20:34:17 maybe ruby 2019-01-29 20:34:26 i dont think python was updated 2019-01-29 20:34:39 golang 2019-01-29 20:34:56 <_ikke_> php and ruby only got patch upgrades 2019-01-29 20:34:56 don't know if it is worth mention in release notes, crystal lang from 0.26 to 0.27 2019-01-29 20:35:14 <_ikke_> mps: is it a significant update? 2019-01-29 20:35:39 for crystal ccommunity it is 2019-01-29 20:35:40 if it require special attention or porting code, then yes, but i doubt 2019-01-29 20:35:58 if its not backwards compatible it needs to be mentioned 2019-01-29 20:36:06 they test crystal on alpine first 2019-01-29 20:36:11 ok, im gonna push the tag and do the git branching now 2019-01-29 20:37:17 <_ikke_> mps: Are there backwards incompattible changes? 2019-01-29 20:38:36 probably, but I'm not so deep in it, so don't know really, you decide. but alpine is important to them to test development 2019-01-29 20:38:36 <_ikke_> git 2.20 noteworthy enough? 2019-01-29 20:39:27 <_ikke_> from 2.18 to 2.20 2019-01-29 20:39:33 some of core devs asked me when the alpine will have new release 2019-01-29 20:40:21 it's my guess that is important to them, but to repeat, i'm not sure 2019-01-29 20:40:41 <_ikke_> I've decided to add it 2019-01-29 20:40:46 do what you think is right 2019-01-29 20:41:27 they can build static packages on Alpine only 2019-01-29 20:44:08 <_ikke_> Any features / changes I forgot? 2019-01-29 20:44:48 <_ikke_> https://tpaste.us/P0pY 2019-01-29 20:45:06 title: 'Alpine 3.8.0 released' 2019-01-29 20:45:17 We are pleased to announce the release of Alpine Linux 3.0.0 2019-01-29 20:45:43 <_ikke_> thanks 2019-01-29 20:46:16 improved grub support 2019-01-29 20:46:44 <_ikke_> added 2019-01-29 20:46:57 grub users should check if config is generated correctly and have emergency boot media prepared 2019-01-29 20:47:59 is bugs.a.o slow or is it only this internet connection that is insanely slow? 2019-01-29 20:48:14 fast for me 2019-01-29 20:48:31 <_ikke_> fast for me 2019-01-29 20:49:22 _ikke_: would you mind reminding me a little bit about the gcc6 + gcc-gcj change to gcc8 ? Did we drop gcj ? Is openjdk7 still compiled from source using gcj ? 2019-01-29 20:49:34 took me 5mins to change a resolved ticket to closed 2019-01-29 20:49:36 <_ikke_> tmhoang: I know very little about that 2019-01-29 20:49:52 <_ikke_> ncopa: Seems a 3.9.0 version on bugs is missing? 2019-01-29 20:49:59 no, its locked 2019-01-29 20:50:02 <_ikke_> I see 3.9.1 2019-01-29 20:50:09 <_ikke_> I check the roadmap 2019-01-29 20:50:14 you cannot report issues to 3.9.0 anymore 2019-01-29 20:50:22 <_ikke_> Yeah, was not looking there 2019-01-29 20:50:27 <_ikke_> but it was hidden under more versions 2019-01-29 20:50:36 its because i just locked it 2019-01-29 20:51:10 :)) 2019-01-29 20:51:20 <_ikke_> http://tpaste.us/65nz 2019-01-29 20:51:23 i will close the 3.9.0 release in redmine when release is done and all builders anr branched 2019-01-29 20:51:44 im pushing tag now 2019-01-29 20:52:16 just need change music... 2019-01-29 20:52:26 <_ikke_> patch form: http://tpaste.us/65nz 2019-01-29 20:52:44 <_ikke_> wrong one 2019-01-29 20:52:49 <_ikke_> http://tpaste.us/VapM 2019-01-29 20:52:51 <_ikke_> this one 2019-01-29 21:02:26 is the 3.9.0 uploaded? 2019-01-29 21:02:32 i think its only s390x that is missing 2019-01-29 21:02:51 <_ikke_> 3.9.0 what? 2019-01-29 21:03:00 <_ikke_> iso? 2019-01-29 21:03:42 yes 2019-01-29 21:03:43 <_ikke_> alpine-standard-3.9.0-s390x.iso exists 2019-01-29 21:03:46 <_ikke_> on master.a.o 2019-01-29 21:04:10 so all are done! 2019-01-29 21:04:36 o/ 2019-01-29 21:04:56 <_ikke_> armv7 is missing? 2019-01-29 21:05:01 <_ikke_> http://master.alpinelinux.org/alpine/v3.9/releases/armv7/ 2019-01-29 21:05:20 <_ikke_> or are there no iso's for armv7? 2019-01-29 21:05:46 _ikke_: I think so 2019-01-29 21:06:02 and no for armhf 2019-01-29 21:06:44 <_ikke_> the tar.gz of the 3.9.0 is missing 2019-01-29 21:06:52 <_ikke_> armv7 that is 2019-01-29 21:06:55 yeah 2019-01-29 21:06:58 i just saw 2019-01-29 21:08:06 rc6 is also missing :( 2019-01-29 21:13:34 something is broken on armv7 2019-01-29 21:17:41 <_ikke_> ncopa: anyhting I can help you with? 2019-01-29 21:18:02 i think armv7 is ok now. can you check if it got uploaded? 2019-01-29 21:18:21 <_ikke_> yes, it got 2019-01-29 21:18:26 _ikke_: thank you very much for helping with release notes 2019-01-29 21:18:35 <_ikke_> no problem 2019-01-29 21:18:39 <_ikke_> rc6 is still missing 2019-01-29 21:18:48 <_ikke_> but the release is there 2019-01-29 21:18:51 we dont care about rc6 i guess 2019-01-29 21:18:56 <_ikke_> nod 2019-01-29 21:20:32 _ikke_: can you update: https://wiki.alpinelinux.org/wiki/Alpine_Linux:Releases 2019-01-29 21:20:45 thanks for asking. i appreciate! 2019-01-29 21:21:40 <_ikke_> No problem, releasing things is tricky enough 2019-01-29 21:22:07 <_ikke_> what would end of support for 3.9 be? 2019-01-29 21:22:47 <_ikke_> Apparently I don't have permissions to edit? 2019-01-29 21:23:00 <_ikke_> "This page has been protected to prevent editing or other actions." 2019-01-29 21:26:17 _ikke_: whats your login? 2019-01-29 21:26:37 <_ikke_> ikke 2019-01-29 21:27:11 try now 2019-01-29 21:27:16 maybe logout and login 2019-01-29 21:27:16 <_ikke_> thanks 2019-01-29 21:27:21 <_ikke_> No need 2019-01-29 21:27:21 i made you admin 2019-01-29 21:27:36 <_ikke_> thanks 2019-01-29 21:28:36 _ikke_: can you please commit https://tpaste.us/VapM and do git format-patch -1 --stdout | tpaste 2019-01-29 21:28:45 and i'll take it from there 2019-01-29 21:29:05 <_ikke_> yes 2019-01-29 21:29:45 i think we should remove scaleway from there 2019-01-29 21:29:52 <_ikke_> yes, indeed 2019-01-29 21:29:52 um 2019-01-29 21:30:07 actually, they sponsered up to the release 2019-01-29 21:30:13 so i think we can include them this time 2019-01-29 21:30:51 <_ikke_> ok 2019-01-29 21:31:33 <_ikke_> http://tpaste.us/mZpj 2019-01-29 21:32:49 They extended for a year again 2019-01-29 21:32:57 There many mails 2019-01-29 21:33:12 So i consider it end 2019-01-29 21:33:26 After.... 2019-01-29 21:33:58 I'm pulling everything and removing my acc 2019-01-29 21:35:57 <_ikke_> Will 3.6 be security only now? 2019-01-29 21:36:05 <_ikke_> Or still full support? 2019-01-29 21:36:24 <_ikke_> Oh, it was already security only 2019-01-29 21:38:03 <_ikke_> Something like this? https://imgur.com/a/RIOKp0N 2019-01-29 21:39:42 seems like wwwtest.alpinelinux.org does not auto update 2019-01-29 21:40:10 <_ikke_> Might be due all the changes on bld1/2 2019-01-29 21:40:26 _ikke_: yes, i think ther is also a line aboce the table that needs change 2019-01-29 21:40:33 which i often foget 2019-01-29 21:41:38 <_ikke_> I see, yes 2019-01-29 21:42:39 yeah, it was due to dns change 2019-01-29 21:42:47 <_ikke_> Ugh, an error when saving :( 2019-01-29 21:43:38 <_ikke_> Now it worked 2019-01-29 21:44:15 <_ikke_> mqtt-exec is still running 2019-01-29 21:44:33 apparently i used an obsolete internal dns 2019-01-29 21:45:10 desthost=wwwtest.bld.alpinelinux.org 2019-01-29 21:45:19 i changed it to wwwtest which seems to work 2019-01-29 21:46:15 <_ikke_> I don't see it updated yet 2019-01-29 21:46:29 just refreshed 2019-01-29 21:46:38 <_ikke_> ah, right 2019-01-29 21:46:43 https://wwwtest.alpinelinux.org/posts/Alpine-3.9.0-released.html 2019-01-29 21:46:45 <_ikke_> yes 2019-01-29 21:46:46 looks ok? 2019-01-29 21:47:05 i'll ask in the other channels too 2019-01-29 21:48:13 i wonder if Lxc should be all capitals 2019-01-29 21:48:45 <_ikke_> Hm, probably 2019-01-29 21:48:49 was perl updated? 2019-01-29 21:48:59 <_ikke_> hmm, checking 2019-01-29 21:49:13 <_ikke_> No, wasn't 2019-01-29 21:49:41 PostgreSQL? 2019-01-29 21:49:48 <_ikke_> Is in there 2019-01-29 21:49:51 with capital SQL 2019-01-29 21:49:55 <_ikke_> ah, yes 2019-01-29 21:50:37 NodeJS? 2019-01-29 21:51:07 no, its Node.js 2019-01-29 21:51:19 <_ikke_> yea, indeed 2019-01-29 21:51:22 <_ikke_> should I use the same? 2019-01-29 21:51:33 im fixing 2019-01-29 21:51:42 i wonder if its GCC or Gcc 2019-01-29 21:51:47 <_ikke_> http://tpaste.us/nMX9 2019-01-29 21:52:53 https://wwwtest.alpinelinux.org/posts/Alpine-3.9.0-released.html 2019-01-29 21:52:54 pushed 2019-01-29 21:53:21 <_ikke_> Looks goo 2019-01-29 21:53:23 <_ikke_> d 2019-01-29 21:53:30 <_ikke_> Verified links 2019-01-29 21:56:22 http://tpaste.us/zBg1 2019-01-29 21:56:31 im afraid im forgetting someone 2019-01-29 21:56:44 helped us with user support 2019-01-29 21:57:04 <_ikke_> s/maintained/maintaining 2019-01-29 21:57:06 "or that has contributed in any other way" 2019-01-29 21:58:49 http://tpaste.us/Xnpe 2019-01-29 21:59:02 i wonder if we should mention busybox version and musl version 2019-01-29 21:59:09 the core componenents 2019-01-29 21:59:41 <_ikke_> musl changed from 1.1.19 to 1.1.20 2019-01-29 21:59:53 and busybox from 1.28 to 1.29 2019-01-29 21:59:56 i think we should mention those 2019-01-29 22:00:02 <_ikke_> ok 2019-01-29 22:00:11 musl 1.1.21 was recently released 2019-01-29 22:00:16 and busybox 1.30 2019-01-29 22:00:50 _ikke_: do you have push access to alpine-mksite? 2019-01-29 22:01:16 <_ikke_> no 2019-01-29 22:02:01 <_ikke_> R alpine-mksite 2019-01-29 22:05:01 i made it a part of infrarepos so now you do 2019-01-29 22:05:13 <_ikke_> thanks 2019-01-29 22:12:20 i wonder if we should sort the git stats in name order instead of number order 2019-01-29 22:12:43 it looks like a ranking 2019-01-29 22:13:00 <_ikke_> it sure does look like it 2019-01-29 22:21:32 mps: http://tpaste.us/ZgJ6 2019-01-29 22:21:34 ok? 2019-01-29 22:22:12 <_ikke_> Rest of the items don't end with a . 2019-01-29 22:23:07 looks ok to me 2019-01-29 22:23:10 the lists 2019-01-29 22:23:18 dont have . 2019-01-29 22:23:25 the sentances has 2019-01-29 22:23:48 "The full list of changes can be found in the [git log][8] and [bug tracker][9]." for example 2019-01-29 22:23:52 <_ikke_> right 2019-01-29 22:24:04 yes. sentence looks a little 'strange', but that should comment someone who is native speaker 2019-01-29 22:24:27 not, that sentence, sorry 2019-01-29 22:24:49 I mean that one: Firefox is only available on x86_64 due to Rust. 2019-01-29 22:25:47 im open to better suggestions 2019-01-29 22:25:52 im not the great writer here :) 2019-01-29 22:26:17 nor I'm. 2019-01-29 22:26:56 SpaceToast: can you have a look at the release notes? https://wwwtest.alpinelinux.org/posts/Alpine-3.9.0-released.html 2019-01-29 22:27:00 any native English speaker here? 2019-01-29 22:27:35 kaniini? 2019-01-29 22:28:52 needs a full stop at the end of the line re grub 2019-01-29 22:29:29 couple of other tiny things but that would be nitpicking, looks fine 2019-01-29 22:31:34 jwh: how this look to you: Firefox is only available on x86_64 due to Rust, 2019-01-29 22:32:13 well it's ridiculous, but the English looks fine :) 2019-01-29 22:33:11 could you propose better formulation for that sentence? 2019-01-29 22:33:33 nope, straight to the point, as it should be 2019-01-29 22:33:53 thanks 2019-01-29 22:34:41 I was being facetious (not sure of a word that translates easy) - firefox being unavailable due to rust is silly, but the grammar is fine 2019-01-29 22:37:10 <_ikke_> night all 2019-01-29 22:37:33 night 2019-01-29 22:39:41 jwh: well, maybe: Firefox is only available on x86_64 due to Rust is not yet ported on other architectures 2019-01-29 22:39:57 ncopa: just a second 2019-01-29 22:39:59 jwh: well, maybe: Firefox is only available on x86_64 due to Rust is not yet ported on other Alpine architectures 2019-01-29 22:40:01 yeah, I just think it's absurd these browsers have all these stupid dependencies 2019-01-29 22:40:01 sorry, was distracted :) 2019-01-29 22:40:26 ncopa: "if config" -> "if their config" 2019-01-29 22:40:30 mps: if you want to be verbose yeah 2019-01-29 22:40:47 SpaceToast: don't assume I'm a person ;) 2019-01-29 22:40:57 jwh? 2019-01-29 22:41:02 lol, nm 2019-01-29 22:41:11 if config works there, it's non-specific 2019-01-29 22:41:14 otherwise looks good! 2019-01-29 22:41:28 I suppose there will be a lot of issues on bugs.a.o because that and a lot questions on IRC 2019-01-29 22:41:41 jwh: the original phrasing is "GRUB users should check if config is generated correctly and have emergency boot media prepared" 2019-01-29 22:41:47 might be worth making a note in that case 2019-01-29 22:42:09 surely you don't expect some random user to be inspecting *your* config ;) 2019-01-29 22:42:24 SpaceToast: perhaps if the config, but English is great, contracted it still means the same thing :D 2019-01-29 22:43:38 although perhaps for the sake of translations you're right 2019-01-29 22:46:24 thanks algitbot for extended shorthand :) 2019-01-29 22:47:02 lol 2019-01-29 22:57:37 im back. the wifi expired 2019-01-29 23:02:34 SpaceToas: "if config" -> "if their config" is the only needed change? 2019-01-29 23:10:29 ncopa: from what I can tell, everything else is fine 2019-01-29 23:10:43 and even that one is arguably optional (as per jwh), though I think it's better to have it 2019-01-29 23:16:52 SpaceToast: thanks! 2019-01-29 23:16:54 https://wwwtest.alpinelinux.org/posts/Alpine-3.9.0-released.html 2019-01-29 23:17:14 i think its good for prod now 2019-01-29 23:17:42 looks good :D 2019-01-29 23:18:00 it's not a literary contest, so :D 2019-01-29 23:18:11 lol 2019-01-29 23:25:46 topic on this channel is 'wrong' :) 2019-01-29 23:26:54 im getting there 2019-01-29 23:27:05 its the second last on my checklist 2019-01-29 23:27:19 seems like the 3.9.0 is not on downloads page yet 2019-01-29 23:27:57 uh, right. 2019-01-29 23:28:03 i think i need to update the latest-release symlink 2019-01-29 23:37:11 hum, i think i may need to sign the releases when im back home 2019-01-29 23:42:52 mps: big thanks for your help with doing this release 2019-01-29 23:43:21 \o/ 2019-01-29 23:43:35 you are welcome, it is pleasure to work with you all 2019-01-29 23:44:03 badass, now, python 3.7 ? :D 2019-01-29 23:44:26 and, now is a time for a glass of good homemade red wine. cheers! :) 2019-01-29 23:45:04 dimon222[m]: patches are welcome, I hear ;) 2019-01-29 23:45:25 last point on my release checklist is "celebrate" 2019-01-29 23:45:44 i still need to make sure the downloads page is updated 2019-01-29 23:46:45 I'm doing my part on the celebrate bit! 2019-01-29 23:46:47 \o/ 2019-01-29 23:47:58 and i need to do the docker image release 2019-01-29 23:48:21 but i think ill celebrate a bit later tonight 2019-01-29 23:49:15 I'm already in ' too late night', 00:48 2019-01-29 23:56:30 armv7 is missing on https://alpinelinux.org/downloads/ 2019-01-29 23:56:54 beer! 2019-01-29 23:57:27 jwh: wine! :) 2019-01-29 23:58:46 maybe when I understand the language enough to figure out what I'm buying :D 2019-01-30 00:44:22 beer! 2019-01-30 00:45:00 no wine in this house atm, so beer will have to do 2019-01-30 06:23:08 Can't wait to try 3.9! ncopa is there a reason for the switch to openssl though? 2019-01-30 06:32:41 my understanding is, openssl has improved a lot, libressl causes a lot of patching and the two are slowly diverging causing more patching 2019-01-30 07:03:07 TBB: Thanks! I just found the devel message on the ml - http://lists.alpinelinux.org/alpine-devel/6308.html 2019-01-30 10:17:55 clandmeter: if you're here, https://github.com/alpinelinux/aports/pull/6172 for ^ b.a.o 2019-01-30 10:22:07 You mean bugs.a.o? 2019-01-30 10:24:20 tmhoang: can you add ref: #9946 2019-01-30 10:24:34 To commit msg 2019-01-30 10:24:42 sure thing, 1 min 2019-01-30 10:26:34 clandmeter: done 2019-01-30 10:27:00 👊 2019-01-30 10:27:52 @ ->-->-- 2019-01-30 10:28:58 :) 2019-01-30 10:29:45 tmhoang: so next time you dont have to open another tab :) 2019-01-30 10:30:25 understood 2019-01-30 13:44:15 ncopa: it looks fine to me 2019-01-30 13:48:14 kaniini: are you talking about issue #9947 2019-01-30 13:48:23 no 2019-01-30 13:48:28 the release notes 2019-01-30 13:48:56 ah, ok 2019-01-30 14:01:23 grats on the release! 2019-01-30 16:03:36 out of interest - does alpine support / use / know / care about NERF and LinuxBoot? 2019-01-30 16:03:40 (also, congrats on the release :) 2019-01-30 16:04:42 mort___: why in go 2019-01-30 16:05:09 aiui is an alternative to uefi that uses linux kernel and a small initramfs 2019-01-30 16:05:50 i know 2019-01-30 16:05:54 but why in go? 2019-01-30 16:06:06 why in go? who knows :) i can't stand go as a language myself 2019-01-30 16:06:16 same 2019-01-30 16:06:35 and compiling go programs is not a nice thing for distributors 2019-01-30 16:07:03 but i've just found out one of the folk involved (ron minnich @ google) is visiting the dept here tomorrow so wondered if there was anything alpine-related worth talking to him about … (given aiui focus on small, secure etc - uefi is perhaps necessary at present but doesn't seem ideal as a way to meet those goals) 2019-01-30 21:34:31 ay 2019-01-30 21:35:54 long time no noise. anyone use jenkins or drone pipelines to build their packages? 2019-01-30 21:36:39 <_ikke_> Nope, I've been looking at buildbot 2019-01-30 21:40:21 i really need to get back into maintaining (and adding) some alpine packages, but so many of mine are out of date, that it would be a good time to try some pipelines 2019-01-30 21:41:38 _ikke_: what did you have in mind? 2019-01-30 21:42:19 <_ikke_> Well, we were looking at both a ci solution and something for the builders 2019-01-30 21:42:22 buildbot builds inside containers right? 2019-01-30 21:42:42 <_ikke_> it can 2019-01-30 21:42:51 <_ikke_> I don't think it will spawn containers 2019-01-30 21:43:34 what would your steps look like, if you started from an APKBUILD file in a repo 2019-01-30 21:44:44 <_ikke_> I haven't come that far yet :P 2019-01-30 21:44:51 <_ikke_> I was mainly looking in the working of buildbot 2019-01-30 21:46:29 so far, my thoughts are pull a alpine container with drone, add alpine-sdk, pull a private repo (not the entire aports repo), run abuild -r, send patch to alpine-aports 2019-01-30 21:51:28 but there are issues, like getting your build keys in the container, and setting up sending email, and the paths would be different in the patch because of the private repo 2019-01-31 04:07:10 is there a variable that holds the arch during APKBUILD ? 2019-01-31 04:09:03 CARCH? 2019-01-31 04:12:36 prolly, ty 2019-01-31 08:57:18 seems we made lwn.net front page with the release this time... i think this is first time 2019-01-31 08:57:28 <_ikke_> fabled: :) 2019-01-31 08:57:31 <_ikke_> nice 2019-01-31 09:28:16 fabled: is there no way we can skip (or make it automatic) to do --available? 2019-01-31 09:36:41 fabled: or alternatively add something like apk dist-upgrade to automatically imply --available? 2019-01-31 12:10:26 anyone know why cgroup is not mounted by default ? 2019-01-31 12:25:27 tmhoang: should it be? 2019-01-31 12:26:39 @ncopa: we are not having alpine docker image s390x, mostly because cgroup is not mount on an alpine host when I'm trying 2019-01-31 12:26:47 trying to debug why cgroup is not mounted by default 2019-01-31 12:28:15 the kernel config for cgroup is there 2019-01-31 12:29:07 maybe not mounted by default on s390x only 2019-01-31 12:32:56 iirc, I removed it on my x86* and arm* because I don't need them, and start them 'by hand' where I need them 2019-01-31 12:37:25 clandmeter: on another note, do you know why the builder doesnt pick up new fuse3 commit ? should be 3.2.6-r1 by now 2019-01-31 12:45:14 mps: cgroup is not mounted by default on x86_64 2019-01-31 12:46:59 could be, can't remember exactly. but 'have in head' that I did 'rc-update del cgroups' on my box because not needed it. but not 100% sure 2019-01-31 12:49:12 hey, will try here instead of gliderlabs :) 2019-01-31 12:49:51 i have little issue with Docker.. builded extensions are big in Docker, but aports packaged versions very small. 2019-01-31 12:50:57 this one is builded from scratch : 2.3M Jan 31 11:56 redis.so 2019-01-31 12:51:25 this is from package php7-redis-4.1.1-r11 installed size: 475136 (edited) 2019-01-31 12:51:50 5x larger 2019-01-31 12:53:29 inspected APKBUILD code... nothing special, also PHP binaries builded like in "main" php APK 2019-01-31 12:53:54 <_ikke_> perhaps compiled with symbols? 2019-01-31 13:00:18 how can i check it? 2019-01-31 13:01:36 I have compiled without debug 2019-01-31 13:01:37 '--disable-phpdbg' 2019-01-31 13:01:56 but this is on PHP, so assume phpize knows it 2019-01-31 13:02:51 <_ikke_> that's php debug, that's something different 2019-01-31 13:03:15 <_ikke_> you can try install -s redis.so /tmp/redis.stripped.so 2019-01-31 13:21:51 damn, it is really debug 2019-01-31 13:22:28 strip --strip-debug redis.so -o redis.stripped.so ---> 601736 Jan 31 15:21 redis.stripped.so 2019-01-31 13:28:35 ncopa: http://tpaste.us/5woj 2019-01-31 13:31:32 afaik the docker image is done by gliderlabs 2019-01-31 13:42:47 never mind, there must be a delay somewhere. It's online now. 2019-01-31 13:44:09 tmhoang: cgroup is normally started by something that depends on it. 2019-01-31 13:45:41 its an openrc service 2019-01-31 13:46:25 tmhoang: pkgs show fuse3 r1 2019-01-31 13:47:16 clandmeter: understood cgroups. but dl-cdn.a.o and master.a.o still r0. 2019-01-31 13:47:39 thats almost impossibe :) 2019-01-31 13:47:50 master is source for all mirrors 2019-01-31 13:47:57 pkgs uses one of the mirrros 2019-01-31 13:49:02 http://master.alpinelinux.org/alpine/v3.9/main/x86_64/fuse3-3.2.6-r0.apk 2019-01-31 13:49:13 3.9 2019-01-31 13:49:24 im talking about ege 2019-01-31 13:49:33 s/ege/edge 2019-01-31 13:49:33 clandmeter meant to say: im talking about edge 2019-01-31 13:50:01 aw my bad, do you mind if I send a pr for 3.9 ? or you could do it ? 2019-01-31 13:50:50 they have good IPA in germany? 2019-01-31 13:51:22 India pale ale ? Never had the time to try one lol busy moving days ... 2019-01-31 13:51:34 but ? 2019-01-31 13:51:36 it will cost you one 2019-01-31 13:51:39 :))) 2019-01-31 13:51:44 :p 2019-01-31 13:52:05 I would send you a racket of them, give me the address 2019-01-31 13:54:30 i need to bring life back to my stable container 2019-01-31 13:55:07 hm,.. strange see in compile time: -g -O2 but still with debug symbols.. 2019-01-31 13:55:31 alpine by default strips binaries 2019-01-31 13:56:20 <_ikke_> -g is adding symbols 2019-01-31 14:06:09 clandmeter : https://github.com/alpinelinux/aports/pull/6198 2019-01-31 14:09:33 if i run abuild in docker, like this: sudo -H -u scrumpyjack abuild checksum, i get: 2019-01-31 14:09:45 sed: can't create temp file 'APKBUILDXXXXXX': Permission denied 2019-01-31 14:10:19 where is abuild trying to write to? 2019-01-31 14:11:12 running abuild as superuser ? 2019-01-31 14:11:51 but to answer your question probably /tmp/ 2019-01-31 14:12:13 not quite. building a pipeline with drone 2019-01-31 14:14:17 ScrumpyJack: use -v 2019-01-31 14:14:32 good point! 2019-01-31 14:17:48 we really get a lot of entropy issues 2019-01-31 14:18:05 <_ikke_> Why is this an issue for alpine speciifc? 2019-01-31 14:18:06 together with ppl who dont know how to properly version upgrade 2019-01-31 14:18:24 its not specific 2019-01-31 14:18:45 it depends on what the distro builder chooses 2019-01-31 14:18:59 ncopa choose to disable cpu entropy generation 2019-01-31 14:19:25 its rather new and included in 4.19 2019-01-31 14:24:37 looks like sed can't create temp file https://ilet.to/5YZE 2019-01-31 15:26:11 managed to get a build pipeline in drone for alpine packages working 2019-01-31 15:27:30 when repo is updated, it builds, but it currently only works with my repo. any suggestions on how to integrate that with aports? 2019-01-31 15:32:10 hi, i was wondering if 3.9.0 was updated with the newer bootloader, etc. files for raspberry pi 3 A+ support 2019-01-31 15:32:43 else i'd be happy to push the nescessary changes since i tweaked 3.8.1 to support that board around a month ago 2019-01-31 16:06:52 geosmin: i dont think so 2019-01-31 16:07:05 i just upgraded them 2019-01-31 16:07:12 i forgot to do so :| 2019-01-31 16:09:28 geosmin: are they in the latest version (1.20181112)? 2019-01-31 16:35:56 clandmeter: i'm not sure what you're referring to with that version number but all relevant files can be pulled from https://github.com/raspberrypi/firmware/tree/master/boot 2019-01-31 16:36:03 though i'm guessing you knew that :) 2019-01-31 16:37:26 one thing i'm fuzzy on though is the firmware issue we were seeing for wlan0 on the 3B+ SoC as detailed here: https://bugs.alpinelinux.org/issues/9549 2019-01-31 16:42:41 clandmeter: i have a board i can test on if you'd like 2019-01-31 16:47:01 im refering to https://github.com/raspberrypi/firmware/releases 2019-01-31 16:49:58 geosmin: would be nice if you can verify if the latest version supports what you need. 2019-01-31 16:50:16 i looked over the commits history but couldnt find much. 2019-01-31 16:52:48 I don't know if someone mentioned it here already but it looks like some packages in edge need a bump 2019-01-31 16:52:53 I'm getting `so:libnftnl.so.7` missing errors 2019-01-31 16:54:18 <_ikke_> MartijnBraam: in testing or another repo? 2019-01-31 16:55:07 I guess it's main because the only packages that depend on it I can find are iptables and nftables 2019-01-31 17:03:01 clandmeter, please backport https://github.com/alpinelinux/aports/pull/6168 2019-01-31 17:08:39 clandmeter: did a cursory look but can't seem to find where to download the latest dev fs snapshot for aarch64 2019-01-31 17:10:51 i remember some folk build aports from their own repo, anyone here? 2019-01-31 17:12:58 <_ikke_> You mean outside of aports, or? 2019-01-31 17:13:03 yes 2019-01-31 17:13:16 in your own git repo somewhere 2019-01-31 17:13:42 <_ikke_> I have a smallish repo 2019-01-31 17:13:57 <_ikke_> nothing special 2019-01-31 17:22:59 ScrumpyJack: I have private repo with aports which I didn't tested enough and some apps which I not sure if they are useful for other users 2019-01-31 17:23:43 just created dir, git init, and creating subdirs with packages 2019-01-31 17:24:53 nothing special, only the root dir will apear under ~/packages when you build apk 2019-01-31 17:25:13 <_ikke_> yeah, that's what I have as well 2019-01-31 18:10:09 hey uh, wheres the builder status again? 2019-01-31 18:15:01 MartijnBraam: oh, I just hit that 2019-01-31 18:16:28 yeah, .11 is in the package, iptables needs to be rebuilt 2019-01-31 18:16:34 at least 2019-01-31 18:17:44 maybe not been done yet though if its still in the queue 2019-01-31 18:29:35 hm, pretty out of date anyway 2019-01-31 18:52:49 jwh: it hasn't been bumped and the armhf builder is idle 2019-01-31 18:56:08 ah 2019-01-31 18:56:24 maybe needs a depend if the library stuff isn't bumping it 2019-01-31 18:56:29 it's the same on x86 also 2019-01-31 18:56:35 x86_64, rather 2019-01-31 18:58:28 yeah it's kinda breaking new installs on edge currently 2019-01-31 18:58:35 mmhmm 2019-01-31 19:11:32 whats up? 2019-01-31 19:13:05 MartijnBraam: which package trows errors? 2019-01-31 19:14:39 clandmeter: iptables and nftables need a bump because libnftnl.so.7 is now libnftnl.so.11 2019-01-31 19:15:12 hmm 2019-01-31 19:15:20 its a patch release bump 2019-01-31 19:19:42 we are a bit behind with iptables 2019-01-31 19:20:13 yeah 2019-01-31 19:20:39 i wonder if there is a reason for it 2019-01-31 19:26:22 jwh, MartijnBraam: rebuild pushed 2019-01-31 19:26:28 o/ 2019-01-31 19:26:52 thanks 2019-01-31 19:27:08 thanks for reporting! 2019-01-31 19:27:38 geosmin: i found the issue with wifi 2019-01-31 19:28:23 forgot what I was doing now that needed me to install iptables lol 2019-01-31 19:28:27 i think we can have a fixed rpi images with 3.9.1 2019-01-31 19:29:59 nmeum: libnftnl broke iptables and nftables. 2019-01-31 19:32:48 hmmm, can't the build stuff pick up on soname changes? 2019-01-31 19:34:01 clandmeter: yay 2019-01-31 19:35:33 clandmeter: postmarketOS works again, thanks! 2019-01-31 19:36:08 not sur ehow to download the latest snapshot 2019-01-31 19:36:20 would it just be a matter of pulling 3.9.1 and upgrading to edge? 2019-01-31 19:37:18 we need to do a new release 2019-01-31 19:37:24 but only one person can do that :) 2019-01-31 19:38:35 not exactly related to rpi but i'd love to see this fixed for 3.9.1, should be extremely trivial: https://bugs.alpinelinux.org/issues/9744 2019-01-31 20:05:29 clandmeter: whoops, why? soname change i missed? 2019-01-31 20:05:39 yup 2019-01-31 20:05:44 just a headup for next time 2019-01-31 20:05:50 it was just a patch release 2019-01-31 20:06:28 oh, sorry 2019-01-31 20:06:32 thanks for fixing it though