2017-06-01 04:18:34 ACTION is working on the greatest apk feature of all 2017-06-01 04:19:39 you're going to love it 2017-06-01 04:20:27 One feature to rule them all, one feature to find them, one feature to bring them all, and in the system bind(8) them? 2017-06-01 04:45:59 TemptorSent: http://i.imgur.com/YsM4N0c.png 2017-06-01 04:47:03 TemptorSent: greatest apk feature of all 2017-06-01 04:47:21 a solid progress bar? 2017-06-01 04:47:29 yes 2017-06-01 04:47:32 GREATEST FEATURE EVER 2017-06-01 04:47:33 APK DONE 2017-06-01 04:47:44 i preferred a nonsolid one 2017-06-01 04:47:44 Shiz: solid if utf-8 is enabled 2017-06-01 04:47:49 Shiz: # if not 2017-06-01 04:47:57 my utf-8 is always enabled 2017-06-01 04:47:59 :P 2017-06-01 04:48:33 ya well 2017-06-01 04:48:35 all the kids these days 2017-06-01 04:48:39 want their solid progress bars 2017-06-01 04:48:44 and beer keg emojis 2017-06-01 04:49:04 clearly there should be APK_PROGRESS_CHAR= 2017-06-01 04:49:09 so i can have my progress bar in beer keg emoji 2017-06-01 04:49:33 or :100:s 2017-06-01 04:50:37 yes 2017-06-01 04:50:39 that is basically 2017-06-01 04:50:41 what i did 2017-06-01 04:50:50 *lol* NICE! 2017-06-01 04:51:12 with a default to solid on utf-8 2017-06-01 04:51:16 and to # on not utf-8 2017-06-01 04:51:25 look 2017-06-01 04:51:32 we gotta show up ubuntu 2017-06-01 04:51:43 they added a progress bar 2017-06-01 04:52:21 Hey, we could even change the color from red to yellow to blue to green ;) 2017-06-01 04:53:08 Change colors each quartile. 2017-06-01 04:53:40 no. use the colours as an apk performance meter, like in parappa the rappa: https://www.youtube.com/watch?v=F5Pm7BL-hyo 2017-06-01 04:54:30 Have the background go red on error :P 2017-06-01 04:55:33 i cant believe somebody lets played that 2017-06-01 04:55:36 anyway 2017-06-01 04:56:39 Shiz: better yet 2017-06-01 04:56:46 Shiz: if you set APK_PROGRESS_CHAR to :100: 2017-06-01 04:56:58 Shiz: it should render an ascii art version of it at the end 2017-06-01 04:57:12 lol 2017-06-01 04:57:18 Preferably animated. 2017-06-01 05:06:48 Shiz: http://i.imgur.com/44vthce.png 2017-06-01 05:07:07 excellent 2017-06-01 05:08:00 Nice! 2017-06-01 05:08:47 Can the rest of the line to be filled use a different char too? 2017-06-01 05:09:13 i've created a monster 2017-06-01 05:09:17 yes 2017-06-01 05:09:22 Yup, and fed it too! 2017-06-01 05:13:06 You could even improve the resolution by using U+2588-U+258F :) 2017-06-01 05:16:26 i tried 2017-06-01 05:16:31 that's what mulmod() was about 2017-06-01 05:16:34 couldnt get it working :P 2017-06-01 05:17:04 Hmm, that's high on the TODO ;) 2017-06-01 05:17:17 patches accepte 2017-06-01 05:17:17 d 2017-06-01 05:17:29 what i actually 2017-06-01 05:17:31 want to do is 2017-06-01 05:17:31 Pushed to repo? 2017-06-01 05:17:36 have it as 2017-06-01 05:17:50 (16/17) Installing blah (...) PROGRESS BAR HERE 2017-06-01 05:17:56 and then the previous shit above it 2017-06-01 05:18:01 or something 2017-06-01 05:18:02 i dont know 2017-06-01 05:18:30 Shouldn't be too hard, just need to set the tabstop. 2017-06-01 05:18:38 now you woke up fabled with your nonsense 2017-06-01 05:18:40 hide yo progress bars 2017-06-01 05:19:32 the a e s t h e t i c of apk 2017-06-01 05:19:57 Shiz: well 2017-06-01 05:20:11 Shiz: tbh the progress bar that is there was my doing 2017-06-01 05:20:27 before that progress bar it was like 2017-06-01 05:20:54 some tiny progress bar 2017-06-01 05:20:56 i forget even 2017-06-01 05:21:03 it was like 2017-06-01 05:21:09 -[%%%%%%%%%]- 2017-06-01 05:21:11 or something 2017-06-01 05:26:05 762e0c717bcae8c2d0f46ba4f35232b773ac8419 2017-06-01 05:26:07 literally in that 2017-06-01 05:26:07 lol 2017-06-01 05:31:07 Need to add U+023F3 to the end :) 2017-06-01 05:31:12 call me blind but i don't see a # initialisation in your commt 2017-06-01 05:34:41 Shiz: +static const char *apk_progress_char = "#"; 2017-06-01 05:35:01 yeah, so blind 2017-06-01 05:48:09 somebody 2017-06-01 05:48:15 changed the aesthetic of the progress bar 2017-06-01 05:48:19 because of serial consoles 2017-06-01 05:48:26 so it had to be redesigned 2017-06-01 05:48:34 because the off-by-one ] 2017-06-01 05:48:38 was bugging the shit out of me :D 2017-06-01 06:00:05 someone hook up apk to a line printer 2017-06-01 06:00:25 preferrably one that interprets \r literally, so the progress bar gets REALLY black as it goes 2017-06-01 06:00:56 it wont print the progress bar to a dumb terminal 2017-06-01 06:01:16 you mean now I have to remember not only how to connect a line printer to linux 2017-06-01 06:01:21 but also how to make a termcap to fool it 2017-06-01 06:01:25 ugh, too much work 2017-06-01 06:01:43 no, it just uses ioctls for it 2017-06-01 06:01:45 no termcap 2017-06-01 06:02:21 oh. 2017-06-01 06:03:14 so if I want to start a flamewar/bikeshed over "should there be a libapk? and should apk then become a consumer of it in .a form?" 2017-06-01 06:03:20 would I do it here, or on the mailing list? 2017-06-01 06:03:47 #alpine-devnull 2017-06-01 06:04:19 *lol* You want to start a nuclear war you said, right awilfox? :) 2017-06-01 06:04:33 rationale: muon/synaptic/whatever pretty package UIs, aptitude/yast/whatever console package UIs, horizon/whatever installer UIs, auto-updater gui thingies 2017-06-01 06:05:27 and I'm sure plenty of other utilities that I am not even thinking of 2017-06-01 06:05:44 hell, you could wire up a packages.alpinelinux.org site directly off a mirror with libapk 2017-06-01 06:05:47 We were discussing earlier the need to expose apks's guts better for interfacing with scripts and external programs. 2017-06-01 06:05:53 then the index is maintained by the apkindex file 2017-06-01 06:05:58 and the site just processes it using libapk 2017-06-01 06:07:57 Yep, see kaniini's latest manifest work and the discussed applet to interact with the database objects more directly. 2017-06-01 06:08:28 there is already a libapk 2017-06-01 06:08:38 awilfox: And now you have me tempted to drag out my old Star line printer :) 2017-06-01 06:08:39 no bikeshed needed 2017-06-01 06:08:44 TemptorSent: discussions are boring, I want to actually dig in and make it happen, I just really wanted to know: is this something that I can upstream, or is it staying in adelie, because it'd be super cool to have alpine get all the tools I want to write around it. 2017-06-01 06:08:53 yes upstream it all you want 2017-06-01 06:09:05 kaniini: there is? 2017-06-01 06:09:06 we want libapk to be a first-class citizen in apk 3 2017-06-01 06:09:08 kaniini: like, .a or .so? 2017-06-01 06:09:09 yes 2017-06-01 06:09:12 .so 2017-06-01 06:09:30 awilfox: Discussion as in it's in the process of happening and determining what we need it to do. 2017-06-01 06:09:43 how does one build it? 2017-06-01 06:09:52 ACTION checks makefile 2017-06-01 06:09:59 make SHARED_LIBAPK=y 2017-06-01 06:13:01 Once the various internal functions are exported in a cohesive manner, interacting with apk from just about any language should be rather clean. 2017-06-01 06:13:12 TemptorSent: that is exactly what I want 2017-06-01 06:14:10 TemptorSent: I would like to see this working in C (something I'm writing), C++ (horizon, an apk-based distro installer I'm writing), Perl (CPAN module I'm planning), Python (flask app to show package info on a repo by reading its APKINDEX), and possibly Rust 2017-06-01 06:14:11 kaniini's progress over the past week or two has already gone a long way towards making it much more usable. 2017-06-01 06:14:30 yaaaaa 2017-06-01 06:14:33 we gonna rewrite apk 2017-06-01 06:14:37 in rust 2017-06-01 06:14:51 hang on i need to pop another microdot 2017-06-01 06:15:28 You sharing kaniini? ;) 2017-06-01 06:15:33 unsafe impl Package { ... 2017-06-01 06:15:35 } 2017-06-01 06:17:05 one reason why i avoided .so is that I wanted to be able to modify the in-memory structs 2017-06-01 06:17:08 But yeah, generally a little wrapping should be all that's needed. 2017-06-01 06:17:25 the new format being TLV should be more easily isolated as .so 2017-06-01 06:20:45 well i should rephrase 2017-06-01 06:20:56 we want apk to be consumable in some way from other programs 2017-06-01 08:12:22 https://txt.shiz.me/YTkzMjg0OG 2017-06-01 08:12:29 current llvm toolchain status caross architectures 2017-06-01 08:17:27 3 out of 7 currently, not bad... 2017-06-01 08:18:00 How ugly is fixing the 32bit arm support? 2017-06-01 08:18:20 you sure? compiler-rt definitely supports ppc32, I'd be surprised if it didn't do ppc64 also 2017-06-01 08:18:31 apple were hacking on llvm before they even went intel 2017-06-01 08:20:48 awilfox: it supports ppc64le 2017-06-01 08:20:50 not ppc64 2017-06-01 08:20:52 :P 2017-06-01 08:22:02 at least 2017-06-01 08:22:07 it told me 'no supported targets' whe ni tried 2017-06-01 08:22:14 maybe the config just went awry 2017-06-01 08:22:22 huh 2017-06-01 08:23:50 https://github.com/llvm-mirror/compiler-rt/commit/612bed15f9652384a92a7967c0b62f068bd00088 2017-06-01 08:23:57 it definitely supports both be and le 2017-06-01 08:23:58 :) 2017-06-01 08:31:35 <^7heo> moin freunde 2017-06-01 08:40:40 ncopa, I've just figured that gns3 does not work with aiohttp 2 2017-06-01 08:41:05 I've opened a bug on gh: 2017-06-01 08:41:06 https://github.com/GNS3/gns3-server/issues/1054 2017-06-01 08:41:25 but it seems that is not going to be fixed soon 2017-06-01 08:41:43 here there's aiohttp-2: 2017-06-01 08:41:44 https://github.com/aio-libs/aiohttp 2017-06-01 08:41:55 whiel here there's aiohttp-1 2017-06-01 08:41:55 https://github.com/arthurdarcet/aiohttp-1/releases 2017-06-01 08:42:15 it seems that just gns on community relies on aiohttp 2017-06-01 08:42:22 and home-assistant in testing 2017-06-01 08:43:05 so I'm wondering to have two py-aiohttp versions 2017-06-01 08:48:42 clandmeter, ^ 2017-06-01 08:48:45 jirutka, ^ 2017-06-01 08:48:54 any opinions on that? 2017-06-01 08:49:01 Or whoever.. 2017-06-01 09:25:38 fcolista: hm, what we can do, so let’s create py-aiohttp1 :/ 2017-06-01 09:26:04 jirutka, yes, i was wondering the same.. 2017-06-01 09:26:21 jirutka, we don't have "conflicts" in APKBUILD right? 2017-06-01 09:26:38 fcolista: we have, depends="!py-aiohttp" 2017-06-01 09:27:02 umh 2017-06-01 09:27:12 bypassed the arm abi issue 2017-06-01 09:27:19 I'm wondering who's going to install py3-aiohttp and py3-aiohttp1 2017-06-01 09:27:27 they will get conflicts 2017-06-01 09:27:36 so I should put "replace" on py3-aiohttp 2017-06-01 09:27:43 py3/py 2017-06-01 09:28:02 conflict is more clean 2017-06-01 09:28:09 as i said, depends="!" 2017-06-01 09:28:27 so depends="!py3-aiohttp" 2017-06-01 09:29:19 replaces= really should not be used in this case 2017-06-01 09:29:43 jirutka, what's the purpose of this, if i set on gns3server depends="py3-aiohttp1" rather than depends="py3-aiohttp" ? 2017-06-01 09:30:20 fcolista: depends="!py3-aiohttp" shold be in py-aiohttp1 pkg, not in gns3server 2017-06-01 09:30:36 fcolista: or have I misunderstood you? 2017-06-01 09:30:39 but this is not pulled automatically 2017-06-01 09:30:46 ah 2017-06-01 09:30:47 ok 2017-06-01 09:30:49 no 2017-06-01 09:30:53 I get your point 2017-06-01 09:31:28 yes 2017-06-01 09:31:40 thx jirutka 2017-06-01 09:31:47 fcolista: you’re welcome 2017-06-01 09:47:32 jirutka, another question: 2017-06-01 09:47:41 py3-aiohttp-cors has depends="py3-aiohttp" 2017-06-01 09:47:54 i think i should remove it 2017-06-01 09:49:55 dunno 2017-06-01 09:50:07 why do you think you should remove it? 2017-06-01 09:51:20 cause py3-aiohttp-core is pulled by gns3, as well as py3-aiohttp1. If i have depends="!py3-aiohttp", when the -cors is installed, i get error 2017-06-01 09:51:34 and py3-aiohttp-core can work with aiohttp1 2017-06-01 09:51:41 https://github.com/aio-libs/aiohttp-cors 2017-06-01 09:51:47 "Note that aiohttp_cors requires versions of Python >= 3.4.1 and aiohttp >= 1.1." 2017-06-01 09:52:17 with depends="py3-aiohttp" i forced py3-aiohttp-cors to work with aiohttp 2 2017-06-01 09:52:21 hi 2017-06-01 09:52:26 can we tag 3.6.1 now? 2017-06-01 09:52:30 hi ncopa 2017-06-01 09:53:09 i think we should do #5381 for 3.7 instead of 3.6.x 2017-06-01 09:53:12 and without depends you get broken (missing) dependencies… 2017-06-01 09:54:30 jirutka, yes. You are right too. 2017-06-01 09:54:49 Umh 2017-06-01 09:55:05 I should have py3-aiohttp1-cors then 2017-06-01 09:55:59 btw, i updated the downloads page 2017-06-01 09:56:22 fcolista: or use provides= 2017-06-01 09:57:07 oh. That's smart 2017-06-01 09:57:26 I can set py3-aiohttp1 with provides="py3-aiohttp" 2017-06-01 09:57:29 fcolista: py3-aiohttp1 provides="py3-aiohttp", not entirely sure if it will work as you want 2017-06-01 09:58:10 umh 2017-06-01 10:02:48 doesn't work :/ 2017-06-01 10:14:34 re #7338 : https://dpaste.de/9EmD/raw 2017-06-01 10:17:03 we can fix it quite easily before 3.6.1 tag ncopa ^ 2017-06-01 10:19:01 ok, lets do that then 2017-06-01 10:20:26 *yawn 2017-06-01 10:20:47 with a little hack i got compiler-rt to work on arm too 2017-06-01 10:23:37 fcolista: you need add wget to makedepends too 2017-06-01 10:24:08 ncopa, yes= 2017-06-01 10:24:10 ? 2017-06-01 10:24:14 yes 2017-06-01 10:24:33 if for example package "foo" depends on lxc-download 2017-06-01 10:24:40 and we build repository from scratch 2017-06-01 10:24:56 it will successfully build lxc 2017-06-01 10:25:19 but will fail install lxc-download because wget might not be built yet 2017-06-01 10:25:26 aaah 2017-06-01 10:25:31 ah ok 2017-06-01 10:25:37 that's why 2017-06-01 10:25:40 so we need to tell the builder that wget needs to be built early 2017-06-01 10:25:40 ok good 2017-06-01 10:25:41 yes 2017-06-01 10:25:56 ncopa, i don't bump pkgrel anyway 2017-06-01 10:25:56 https://dpaste.de/pBT8/raw 2017-06-01 10:26:00 just adding wget ^ 2017-06-01 10:26:29 i suppose thats ok 2017-06-01 10:26:31 re ppc mentioned earlier: not latest ppc stuff is not the easiest to work with. you cannot build stuff for powerpc64 and expect it to run on, e.g. T2080 (freescale's e6500 core), because you may be hit by lacking instructions (like fsqrt). even in 32-bit world it's hard to find sensible common denominator for various vendors, so your best bet is building for your particular core (or vendor's 2017-06-01 10:26:37 older core compatible with the range of cpus used by you). e6500 for instance theoretically supports little-endian mode, but not in altivec unit, so it's half-baked le in fact... powerpc64le target fixes a bit this mess somehow by increasing requirements (ISA 2.07 w/ complete fp and vsx IIRC), so mentioned e6500 is simply not living up to these reqs. funilly e6500 is even mentioned as complying 2017-06-01 10:26:43 to PowerISA 2.07, yet lacking fp instructions kind of negates this claim. 2017-06-01 10:28:48 fcolista i pushed it to 3.6-stable 2017-06-01 10:28:50 thanks! 2017-06-01 10:28:57 yes, saw that 2017-06-01 10:29:04 thx to you 2017-06-01 10:29:13 any opinion regarding the aiohttp1 ? 2017-06-01 10:29:43 i havent digged in to the details 2017-06-01 10:30:21 i'm basically adding py3-aiohttp1 and py3-aiohttp1-cors due to a bug on gns3 2017-06-01 10:31:13 and adding those two packages to gns3 2017-06-01 10:32:13 przemoc: I don't think I've seen a 2.07 CPU yet haha 2017-06-01 10:32:17 and I'm the local power head 2017-06-01 10:42:36 awilfox: T2080 (e6500) is the latest stuff I had my hands on a bit, previously only P2020 (e500v2) and possibly something older too. so what did you dirty your hands on? 2017-06-01 10:46:13 przemoc: locally I've just Cell BE, 970fx, and some 700s; in my days I've done BRE440s and P6+ 2017-06-01 10:46:25 przemoc: strictly IBM, don't think I've ever even seen freescale stuff. 2017-06-01 10:46:39 mm well obviously I /have/, just, not irl 2017-06-01 10:47:26 oh. does the dual 7447 quicksilver mac count? bahaha.. 32-bit.. poor thing 2017-06-01 10:50:17 hehe 2017-06-01 10:50:20 lld failed to link clang 2017-06-01 10:52:12 <^7heo> so basically, ldd executes the binary to retrieve the linkings; so if it cannot load the libc, it will just fail to load any dependency and therefore return "not a dynamic executable", did I get it right? 2017-06-01 10:53:41 <^7heo> (i.e. tried with a glibc linked binary without `mkdir /lib64; ln -s /lib/ld-musl-x86_64.so.1 /lib64/ld-linux-x86_64.so.2`) 2017-06-01 10:54:23 <^7heo> s/linux-x86_/linux-x86-/ 2017-06-01 10:54:51 uh, don't pretend that the musl linker is the glibc linker 2017-06-01 10:55:04 <^7heo> the ABI is supposed to be compatible 2017-06-01 10:55:17 sure, but still, don't 2017-06-01 10:55:19 <^7heo> when I need something to work quickly, that's what I do. 2017-06-01 10:55:25 <^7heo> skarnet: why, is there a better way? 2017-06-01 10:55:29 <^7heo> I don't know of any. 2017-06-01 10:56:41 <^7heo> (I thought about modifying the binary I want to run to refer to /lib/ld-musl-x86_64.so.1 instead of /lib64/ld-linux-x86_64.so.2 in its symbol table (or whatever that section is called - feel free to correct me)) 2017-06-01 10:57:02 check on #musl. I'm not experienced enough in unholy voodoo to know exactly what is dangerous and what is not 2017-06-01 10:57:11 <^7heo> I should spend more week ends on the linux executable format and assemblers/disassemblers. 2017-06-01 10:57:26 as soon as it involves blood, I run away - call me a wussy 2017-06-01 10:57:26 <^7heo> skarnet: alright; thanks for the suggestion, will do now. 2017-06-01 10:57:31 <^7heo> huhu 2017-06-01 10:57:47 <^7heo> skarnet: I won't call you a wuss, I know you value your brain 2017-06-01 10:58:11 that actually is the best/only way to run glibc binaries 2017-06-01 10:58:18 without actually putting in glibc 2017-06-01 10:58:25 the symlink I mean 2017-06-01 10:58:39 it's dangerous-ish, but hey, you only live twice - that's what James Bond told me 2017-06-01 10:59:25 awilfox: it feels like horror sci-fi when you rip off your arm and plug a gun directly into the dangling nerves 2017-06-01 10:59:35 "I can control this gun no problem" 2017-06-01 11:02:23 lol 2017-06-01 11:03:28 it doesn't even faze me any more; I was doing low-level crap like this before I even finished primary school :P 2017-06-01 11:04:27 <^7heo> skarnet: < skarnet> awilfox: it feels like horror sci-fi when you rip off your arm and plug a gun directly into the dangling nerves 2017-06-01 11:04:46 <^7heo> Why on earth would you call that a 'horror' themed story? 2017-06-01 11:04:52 <^7heo> it's just sci-fi! 2017-06-01 11:05:26 <^7heo> let's all rip our limbs off, plug various augmented artificial prosthetic limbs instead and go to offtopic to talk about all this. 2017-06-01 11:05:26 and those people are supposed to be my friends 2017-06-01 11:05:56 it's 6:06 AM on a Thursday morning and I am discussing horror sci-fi amongst unix neckbeards on IRC while The Weeknd croons soulfully about doing cocaine in my ear 2017-06-01 11:06:04 I have either the best, or worst, life 2017-06-01 11:06:09 I haven't decided which one yet 2017-06-01 11:06:14 #whynotboth 2017-06-01 11:06:21 <^7heo> awilfox: look, at least you're not in Germany. 2017-06-01 11:06:23 +1 I like your thinking 2017-06-01 11:06:26 replacing leg with machine gun is equally legit? if so, then planet terror may be good for you, but it's more gore than horror, and a grindhouse pastiche at that, but quite entertaining 2017-06-01 11:07:33 <^7heo> awilfox: in Germany, if anyone is going to have to do construction work in your building; you can be SURE that 1. they come between 6 and 7 AM, and 2. they do ALL the heavy noisy shaky stuff with the industrial powertools for 3-4 hours immediately after arriving. 2017-06-01 11:07:40 Grindhouse was actually good! 2017-06-01 11:08:16 <^7heo> (so after 9-11 (ahah) AM, they merely move stuff around and drink while chatting. But then you can't sleep anymore...) 2017-06-01 11:08:27 <^7heo> and yeah Grindhouse <3 2017-06-01 11:08:32 ^7heo: I was awoken at 7:45 AM last month by roofers spastically hammering above my head (I live on the top floor) 2017-06-01 11:08:44 <^7heo> ah 2017-06-01 11:08:53 <^7heo> top floors during summer != good place to sleep 2017-06-01 11:09:15 ^7heo: jwz is my spirit animal: https://www.jwz.org/gruntle/bang.html 2017-06-01 11:09:19 <^7heo> ACTION lived on top floors for 20 years or so, cumulated 2017-06-01 11:09:49 <^7heo> "They have been hammering since around 11:30am. I went to bed at 7am." 2017-06-01 11:09:53 <^7heo> Ahaha. Amateur. 2017-06-01 11:10:06 hey, that was written in 1996; he was an amateur by then 2017-06-01 11:10:07 what's going on here "x 2017-06-01 11:10:09 <^7heo> Try going to bed at 7AM with people hammering since 6 AM until 10 AM... 2017-06-01 11:10:11 nscpdorm hadn't even been written yet. 2017-06-01 11:10:49 <^7heo> scadu: #itfeelslikefriday 2017-06-01 11:11:14 <^7heo> przemoc: also planet terror <3 2017-06-01 11:11:18 ^7heo: 3PM when production is burning? ;f 2017-06-01 11:11:31 <^7heo> scadu: yeah I basically got 3 hours of sleep last night. 2017-06-01 11:11:35 <^7heo> scadu: that exactly. 2017-06-01 11:11:37 scadu: I have documentation to write, so I'll use any pretext to get distracted 2017-06-01 11:11:43 <^7heo> scadu: fortunately it wasn't production burning, it was another issue 2017-06-01 11:11:52 <^7heo> skarnet: see ya :) 2017-06-01 11:12:17 skarnet: yeah, you can get a lot distraction on -devel last time ;f 2017-06-01 11:12:34 I look at the weechat 2017-06-01 11:12:35 I meant grindhouse as movie style, you apparently meant it as combined name for Tarantino+Rodriguez's double film, which in fact consists of death proof and planet terror. I found planet terror much more entertaining than the first film, though. 2017-06-01 11:12:38 fuck, something happened 2017-06-01 11:12:54 and then some zombie-related, erm, discussion 2017-06-01 11:13:04 przemoc: -offtopic :> 2017-06-01 11:13:44 skarnet lured me into this OT area with his weird associations... :> 2017-06-01 11:14:00 * achievement unlocked * 2017-06-01 11:14:35 ACTION will resist harder in future 2017-06-01 11:14:58 <^7heo> someone please think of the jirutka ! He will have hundreds of lines to read and nothing of importance... 2017-06-01 11:15:33 jirutka: ignore all this shitlog today. over. 2017-06-01 11:24:12 ^7heo: it won't execute the binary, it will load it 2017-06-01 11:24:19 well, glibc ldd executes the binary 2017-06-01 11:24:24 but glibc ldd is bad 2017-06-01 11:25:11 <^7heo> ah ok. 2017-06-01 11:25:34 <^7heo> So "usually" (since glibc is virtually everywhere) it does execute the binary 2017-06-01 11:25:52 <^7heo> But with the implementation we're using (the one from musl I'd presume?) it does not. 2017-06-01 11:25:56 <^7heo> correct? 2017-06-01 11:26:10 i think glibc is fairly unique in being that silly 2017-06-01 11:26:41 <^7heo> it's also fairly unique in being a libc actually used by more than 0.01% of the world population. 2017-06-01 11:26:57 <^7heo> the other one being potentially musl. 2017-06-01 11:50:43 uh 2017-06-01 11:50:45 msvcrt? 2017-06-01 11:50:47 libSystem? 2017-06-01 11:50:51 bsd libc? 2017-06-01 11:52:40 Question: suppose someone wants to maintain an Alpine package repository on a non-Alpine machine. (silly, I know, but bear with me). 2017-06-01 11:53:12 To add or update apks in this repository, they'd have to upload the apk, but also the APKINDEX.tar.gz, right? 2017-06-01 11:53:44 and the APKINDEX.tar.gz is essentially maintained by abuild when the apks are built? 2017-06-01 11:54:21 so they would have to maintain a complete repository on the Alpine system running abuild, and mirror it on the other distribution. Am I getting this right, or is there a simpler way? 2017-06-01 11:55:46 'apk index' is responsible for APKINDEX.tar.gz generation. abuild just uses it, and is therefore not necessary 2017-06-01 11:56:51 xentec: ok, but you still need the Alpine system with apk and the packager's key. 2017-06-01 11:57:01 And all the packages you want to index. 2017-06-01 11:57:22 My point was, you can't add packages to a foreign-hosted repository incrementally. 2017-06-01 11:57:24 Is this right? 2017-06-01 11:59:30 not without apk (or apk.static, allowing it to run on any linux host) and trusted keys, no 2017-06-01 11:59:54 but apk.static may be a solution for you 2017-06-01 11:59:56 :P 2017-06-01 12:00:02 apk.staic is your friend 2017-06-01 12:00:39 ok, thanks for the hints. 2017-06-01 12:01:10 Or rsync it over including the index? 2017-06-01 12:01:34 sure, but that means you need to maintain the repo on the Alpine system, which is what I'm trying to avoid. 2017-06-01 12:01:45 skarnet: I build Alpine pkgs on Travis that runs Ubuntu just fine https://github.com/jirutka/user-aports, just install Alpine into chroot https://github.com/alpinelinux/alpine-chroot-install 2017-06-01 12:02:08 "it's easy: just duplicate the universe" 2017-06-01 12:02:25 skarnet: 5MiB universe… 2017-06-01 12:02:33 :P 2017-06-01 12:03:25 skarnet: I use sshfs to mount remote FS with packages https://github.com/jirutka/user-aports#set-up-repository 2017-06-01 12:03:41 i just realised you also need abuild-sign/abuild-tar to actually sign the index... 2017-06-01 12:03:48 ACTION is not a fan of how abuild is implemented currently 2017-06-01 12:03:58 skarnet: it was the easy way, you can also handle signing separately and just use rsync/scp 2017-06-01 12:04:15 apk3 probably should have signing integrated int oit 2017-06-01 12:04:21 if it also has stuff like apk gen 2017-06-01 12:05:04 int oit? 2017-06-01 12:05:26 Shiz: ok, so there's no way out of keeping the repo on the Alpine system 2017-06-01 12:05:37 jirutka: into it 2017-06-01 12:05:53 skarnet: abuild doesn't have any special dependencies so it's easy to build, but yeah 2017-06-01 12:05:57 you'll need both abuild and pk 2017-06-01 12:05:59 apk* 2017-06-01 12:06:02 at least 2017-06-01 12:06:21 skarnet: how would you link native stuff against musl on non-musl system, without messing with paths and rewriting every abuild…? 2017-06-01 12:06:32 wut 2017-06-01 12:06:42 nobody's at all talking about building packages 2017-06-01 12:06:50 it's about updating an existing repo index with new packages (.apk files) 2017-06-01 12:06:55 aha 2017-06-01 12:07:07 then you don’t need abuild, just apk.static… 2017-06-01 12:07:10 right? 2017-06-01 12:07:15 you need abuild 2017-06-01 12:07:16 if you already have .apk files 2017-06-01 12:07:19 abuild-sign signs the index file 2017-06-01 12:07:43 aha, ok, but abuild-sign can be compiled as standalone binary, can’t be? 2017-06-01 12:07:57 so just build statically linked apk, abuild-sign, abuild-tar(?) 2017-06-01 12:08:13 that's a lot of DIY 2017-06-01 12:08:23 a lot? 2017-06-01 12:08:33 compile single C file? 2017-06-01 12:09:02 just create package for the target distro you want to use… omg 2017-06-01 12:09:05 I'm not afraid of that, and you're not afraid of that, but the people I'm doing this for want a streamlined, polished, documented process 2017-06-01 12:09:15 aha 2017-06-01 12:09:24 then write a manual for them ;) 2017-06-01 12:09:27 imo signing should be able to be handled by apk 2017-06-01 12:09:31 just like it already verifies 2017-06-01 12:09:34 yeah 2017-06-01 12:09:50 either that 2017-06-01 12:09:54 or move index generation out of it too 2017-06-01 12:09:59 afk 2017-06-01 12:10:02 it makes no sense to do index generation but not signing or vice-versa 2017-06-01 12:10:13 either be a dedicated consumer of stuff or a competent producer as well 2017-06-01 12:10:15 :P 2017-06-01 12:12:56 https://txt.shiz.me/NDQ3YTEyND 2017-06-01 12:13:08 results of arch research for LLVM toolchain viability for our supported arches 2017-06-01 12:13:16 cc kaniini ncopa 2017-06-01 12:14:41 clang: 6/6, compiler-rt: 5/6, llvm-libunwind: 4/6, libc++: 6/6, lld: 3/6 2017-06-01 12:14:57 made a mistake, fixed: https://txt.shiz.me/NTc4ZDc1ZW 2017-06-01 12:42:53 jirutka, i've gns3 working with those patches: 2017-06-01 12:42:54 https://dpaste.de/bdW9/raw 2017-06-01 17:03:49 ncopa: id want to fix the kb problem before tagging 3.6.1 2017-06-01 17:10:41 hi 2017-06-01 19:04:33 hi 2017-06-01 19:04:39 the kb problem? 2017-06-01 19:05:51 kaniini: do you any idea what #7372 might be? 2017-06-01 19:06:07 i have a feeling it might be related lazy loading 2017-06-01 19:10:56 no idea 2017-06-01 19:11:01 could be 2017-06-01 19:11:08 but don't think so 2017-06-01 19:11:14 because lazy loading would just cause segfault 2017-06-01 19:56:10 ncopa: seems like there's issues with keymaps... 2017-06-01 20:02:18 ok 2017-06-01 20:02:26 i tagged release 3.6.1 2017-06-01 20:03:57 what was fixed? 2017-06-01 20:04:14 rpi kernel 2017-06-01 20:04:16 didnt boot 2017-06-01 20:04:18 apk tools 2017-06-01 20:04:33 and i wanted push it before 4.9.31 kernel is out 2017-06-01 20:05:07 https://git.alpinelinux.org/cgit/aports/log/?h=v3.6.1 2017-06-01 20:05:56 okay 2017-06-01 20:06:10 ncopa: do you have time later to talk/brainstorm about this llvm thing? :P 2017-06-01 20:06:18 not today 2017-06-01 20:06:20 not tomorrow 2017-06-01 20:06:27 monday possibly :-/ 2017-06-01 20:06:34 it's fine 2017-06-01 20:06:40 what are the main issue? 2017-06-01 20:06:41 some place on your schedule will do 2017-06-01 20:06:58 well, the main issue is that it's going surprisingly well :P 2017-06-01 20:07:04 it seems to work on x86, x86_64 and aarch64 completely 2017-06-01 20:07:36 while on armhf, and ppc64 we will still need binutils ld 2017-06-01 20:08:24 so i'd like to discuss where we can take this :) 2017-06-01 20:09:09 you mean if we can use clang as default c compiler for alpine 3.7? :) 2017-06-01 20:10:21 or 3.8, or if it's on the table at all :P 2017-06-01 20:10:41 and not just clang, but possibly other components as well 2017-06-01 20:10:44 like libc++ and compiler-rt 2017-06-01 20:11:10 lets talk about it on monday 2017-06-01 20:11:22 sounds good 2017-06-01 20:11:26 i will ask you: what is the benefit? what is the cost? 2017-06-01 20:11:47 sure 2017-06-01 20:11:50 GNULess/Alpine :) 2017-06-01 20:12:19 i mean, not using the gnu toolchain is a nice thought, but not really a concrete benefit 2017-06-01 20:12:24 i've got some other benefits in mind though 2017-06-01 20:12:35 lets talk about it on monday 2017-06-01 20:12:40 yep 2017-06-01 20:13:16 last points on my release checklist: 2017-06-01 20:13:19 Update topic in IRC channels 2017-06-01 20:13:19 Celebrate! 2017-06-01 20:13:28 :) 2017-06-01 20:13:33 woo 2017-06-01 20:14:51 \o/ 2017-06-01 20:14:59 have a nice weekend everyone! 2017-06-01 20:15:30 same! 2017-06-01 22:45:20 so, as we were saying earlier 2017-06-01 22:45:49 evening skarnet 2017-06-01 22:46:04 let's say I have an apk repository with an index. I also have apk, abuild, anything I need (it's an Alpine system), and developers' keypair in the right place 2017-06-01 22:46:34 but I did not build an apk on this machine, I fetched it from some other place. Or I want to delete an apk from this repo. 2017-06-01 22:46:45 I want to modify the repository, and rebuild (and sign) the index. 2017-06-01 22:46:48 right 2017-06-01 22:46:53 What command do I need to run ? 2017-06-01 22:47:30 cd repofolder; apk index *.apk -o mynewindex.tar.gz 2017-06-01 22:47:51 abuild-sign -k keyfile mynewindex.tar.gz 2017-06-01 22:47:51 thanks 2017-06-01 22:47:53 i think that should work 2017-06-01 22:48:36 and then mv -f mynewindex.tar.gz APKINDEX.tar.gz ? 2017-06-01 22:49:36 yup 2017-06-01 22:49:55 thanks 2017-06-01 22:53:49 <^7heo> actually nothing prevents you from using APKINDEX.tar.gz from the start 2017-06-01 22:53:56 <^7heo> right Shiz ? 2017-06-01 22:54:00 wrong 2017-06-01 22:54:04 well 2017-06-01 22:54:06 I want the index change to be atomic 2017-06-01 22:54:08 if people update before you sign it 2017-06-01 22:54:09 yeah that 2017-06-01 22:54:13 <^7heo> ah 2017-06-01 22:54:20 also if something goes wrong 2017-06-01 22:54:20 <^7heo> yeah ok 2017-06-01 22:54:23 you'd lose your previous index 2017-06-01 22:54:28 <^7heo> yeah 2017-06-01 22:54:33 <^7heo> atomic 2017-06-01 22:54:45 Shiz: is the -k option to abuild-sign necessary if I have the private key in the right place described by PACKAGER_PRIVKEY in $HOME/.abuild/abuild.conf ? 2017-06-01 22:54:59 good question 2017-06-01 22:54:59 (if you don't know I'll look into the code) 2017-06-01 22:55:15 <^7heo> technically there's nothing preventing it. But to have a safefail... you need to yes 2017-06-01 22:55:25 i don't think it's necessary 2017-06-01 22:55:32 privkey="$PACKAGER_PRIVKEY" 2017-06-01 22:55:34 yeah it's not 2017-06-01 22:55:46 <^7heo> I did it without 2017-06-01 22:56:09 <^7heo> skarnet: are you doing this on your mirror? 2017-06-01 22:57:05 <^7heo> because I was doing it on an offline repo on my usb key; and I assumed the same when saying you could directly replace it. 2017-06-01 22:57:08 I mostly use my mirror for washing my face and shaving, personally, but to each their own 2017-06-01 22:57:14 lol 2017-06-01 22:57:26 <^7heo> tsssk 2017-06-01 23:11:24 The key management system really shouldn't require the APKINDEX to be regenerated every time an apk is added to the repo. 2017-06-01 23:12:45 Package-level signatures would eliminate that entire hassle. 2017-06-01 23:13:21 Can we delay the world-rebuilding discussion until I'm done with my current practical matter? Thanks. 2017-06-01 23:17:55 lol 2017-06-01 23:18:09 and yes it should 2017-06-01 23:18:32 Anyway, short answer is you can currently use apk index with a several options set (--description, --index, and --output come to mind) followed by abuild-sign on the resultant file. 2017-06-01 23:18:34 db integrity is just as important as pkg integrity 2017-06-01 23:20:09 I'm not sure if kaniini's apk gen work also includes the machinery for signing yet, but in theory apk itself should soon be able to create the signed index directly without the need for abuild. 2017-06-01 23:27:54 TemptorSent: apk already signs things. that's what APK_VERIFY_SIGN_AND_GENERATE is about 2017-06-01 23:28:08 Shiz - Each entry in the index should be individually signed so building the resulting composiited index is a simple concat operation. 2017-06-01 23:28:36 kaniini: Oh! How do you tell it to do that without abuild? Can apk index generate the signed index directly? 2017-06-01 23:28:41 TemptorSent: apk index can even sign itself 2017-06-01 23:28:56 Cool! Another easter egg :) 2017-06-01 23:29:04 i think 2017-06-01 23:29:10 humm 2017-06-01 23:29:12 What's the appropriate invocation? 2017-06-01 23:29:20 doesnt seem to be implemented, which is funny considering the core supports it 2017-06-01 23:29:21 :D 2017-06-01 23:29:24 i'll ummm 2017-06-01 23:29:25 fix that 2017-06-01 23:29:48 *lol* Another wish-list item down! Awesome :) 2017-06-01 23:29:52 there you go skarnet 2017-06-01 23:29:55 can even just use apk.static 2017-06-01 23:30:39 plus apk3 has proper a e s t h e t i c 2017-06-01 23:30:39 Eagerly awaiting your next push kaniini! \o/ 2017-06-01 23:30:43 (when in utf-8 mode) 2017-06-01 23:31:44 Almost all of my major pain points scripting with apk are now fixed or in progress, you rock! 2017-06-01 23:32:05 hm, that'd be neat, then I could get rid of that awful script 2017-06-01 23:32:38 Yeah, I'm looking at all the crap I can strip out of my code now and it's more than the actual logic! 2017-06-01 23:34:21 kaniini: Can apk generate keys as well? 2017-06-01 23:34:39 TemptorSent: https://bpaste.net/raw/74955c00e95c 2017-06-01 23:34:47 apk keys are just openssl genrsa 2017-06-01 23:34:49 so please no 2017-06-01 23:34:53 TemptorSent: no, trying to emulate abuild's more arcane stuff is Not Fun lol 2017-06-01 23:35:59 what's tarcut do? 2017-06-01 23:36:12 Shiz: abuild-tar --cut implemented in terrible perl 2017-06-01 23:36:25 lovely 2017-06-01 23:36:29 awilfox: Yeah, I encountered that and found a slighly different work around just stripping the last header from the first file and catting the second. 2017-06-01 23:37:18 But now that apk can generate a valid .apk format directly, all that uglyness can be defenestrated 2017-06-01 23:38:11 TemptorSent: yeah, my entire ~600 line python module can now be cut to 20 lines of posix sh 2017-06-01 23:38:15 TemptorSent: it's amazing 2017-06-01 23:38:51 Shiz: Considering I believe the library is already included, it would eliminate the need for several other deps for people wanting to use a custom kernel or such. 2017-06-01 23:39:35 awilfox: Yeah, this is why I stopped working on rewriting mkimage and adding tools until apk was fixed. 2017-06-01 23:40:24 Once a few packaging changes are complete, life will be downright easy for scripting apk. 2017-06-01 23:43:11 kaniini: how feasible would it be to allow apk to export the metadata for files in a format that something like libfakeroot could consume? 2017-06-01 23:44:30 kaniini: thanks, but unless the push makes it into main in less than a week, it's of no use to me 2017-06-01 23:45:05 (for now. Later on, I'm sure I'll be in awe.) 2017-06-01 23:46:30 skarnet: It sounds like he just needs to do the wiring to allow the index applet to use already existing functionality in apk's core -- I wouldn't bet against it working by tomorrow :) 2017-06-01 23:49:03 Okay, WTF -- my /dev/null randomly got chmnodded to 755 somehow? 2017-06-01 23:49:59 Nothing odd done except playing with llvm bootstrap per Shiz's notes... 2017-06-01 23:50:33 er 644 :P 2017-06-01 23:52:31 TemptorSent: what is your umask 2017-06-01 23:52:34 TemptorSent: is it 022? 2017-06-01 23:53:40 awilfox: Probably, but the issue is that something chmodded /dev/null in the first place! 2017-06-01 23:53:54 TemptorSent: it could have gotten erased 2017-06-01 23:53:56 TemptorSent: and then recreated 2017-06-01 23:53:58 Some script in bootstrap I'm guessing. 2017-06-01 23:54:31 Bloody hell, yeah - and recreated as a REGULAR FILE! 2017-06-01 23:54:31 nop 2017-06-01 23:55:41 Broken script somewhere in bootstrap or one of the dep packages I'm guessing. 2017-06-01 23:57:50 kaniini: Is the manifest-from-file in git yet? 2017-06-01 23:58:01 I've seen that already. Don't remember where exactly. It's when something run when you haven't mounted devtmpfs yet, oslt. 2017-06-01 23:58:07 runs* 2017-06-01 23:58:15 yes 2017-06-01 23:59:33 kaniini: Ahh, okay - found it, still has the TODO comment for it :) 2017-06-02 00:00:27 Also, is there any sane way of reading a directory directly in the same manner as a tar file, so that we can manifest a directory and compare it to the manifest of a set of apks? 2017-06-02 00:02:49 you mean for the metadata or the file contents? 2017-06-02 00:03:57 metadata+checksums 2017-06-02 00:04:16 filesystem dirents 2017-06-02 00:04:38 And checksum of file content. 2017-06-02 00:05:21 well there's no checksum in a struct stat, and no hook to do so, so it's possible but pedestrian 2017-06-02 00:05:47 you still have to scan everything and checksum it manually 2017-06-02 00:05:56 The convoluted way that would probably work right now is to pipe the output of apk-gen for the directory to the input file for apk manifest 2017-06-02 00:07:06 Somewhere in apk, the mechnanism is already more or less existent since it already knows how to encode a directory to a .apk and it knows how to parse a .apk and output a manifest. 2017-06-02 00:10:11 If there's an easy way to allow apk to take dirctory or file lists and handle them as if they were .apks (including the xattrs), we would have a very clean way of handling custom packages without having to create a physical .apk file every iteration for testing. 2017-06-02 00:17:03 Just an fyi: there are now Early-Access builds of the JDK for Alpine/musl on the JDK 9 EA page 2017-06-02 00:17:17 http://jdk.java.net/9/ 2017-06-02 00:17:28 announcement here: http://mail.openjdk.java.net/pipermail/portola-dev/2017-June/000191.html 2017-06-02 00:18:51 Very cool! 2017-06-02 00:19:33 I wonder what it'd take to get there rest of the archs supported... 2017-06-02 00:19:51 would very much appreciate feedback, can't stress that enough 2017-06-02 00:21:13 if my experience getting it all to work on x86_64 is at all representative I don't think other architectures will be hard to add 2017-06-02 00:21:42 the changes I had to make were not arch specific, they were more related to cleaning up the C/C++ code 2017-06-02 00:21:51 mikeee_: Is there a direct link without the web interface? 2017-06-02 00:21:53 mikeee_: for the ARM builds, would suggest mentioning which ARM specifically, eg at least the architecture number... 2017-06-02 00:22:03 (refering to that webpage) 2017-06-02 00:22:42 presumably "Alpine Linux" means x86_64 but with musl rather than glibc, correct? 2017-06-02 00:22:48 temptor: something, something license approval needed, something 2017-06-02 00:23:38 mikeee_: Got it :/ 2017-06-02 00:23:59 rfs613: indeed - Alpine Linux in that context is x86_64. I'll let the page owners know that having the architecture there would be helpful 2017-06-02 00:24:49 mikeee_: actually i see they have a footnote for Alpine that makes it fairly clear. But they could add one for ARM builds. 2017-06-02 00:25:05 It would also be nice to specify the musl version used. 2017-06-02 00:26:20 I' 2017-06-02 00:26:48 I'm developing on a all-text console, so it might be an issue grabbing the file currently. 2017-06-02 00:28:09 Ahh, never mind - I figured out the URL ;) 2017-06-02 00:28:19 With buildroot you can build the whole rootfs with whatever components you TemptorSent: looks like the page requires javascript, then the urls work 2017-06-02 00:28:26 temptor: for various reasons this is built on Alpine 3.4.6, so it's musl 1.1.14. that said, it's dynamically linked and has been verified on Alpine 3.5/musl 1.1.15 as well 2017-06-02 00:29:15 temptor: would it be helpful to say 1.1.15+ or something like that? 2017-06-02 00:29:33 Hmm apparently I had some text in my clipboard ;-) 2017-06-02 00:29:37 mikeee_: Ahh, okay - there have been some changes that may or may not be an issue in newere releases, you might want to test against 3.6.1 2017-06-02 00:30:36 mikeee_: Do you have an APKBUILD for it? 2017-06-02 00:30:47 the testing we've done so far is all good, but we've mostly tire-kicked it so far. will keep 3.6.1+ in mind 2017-06-02 00:31:25 temptor: no APKBUILD yet, but should be straightforward to put together 2017-06-02 00:31:51 mikeee_: Okay, just curious if you were building it by hand or through abuild currently. 2017-06-02 00:32:51 right now "by hand", although it's less manual than it may sound :) 2017-06-02 00:33:35 Do you have a cross-build environment setup? 2017-06-02 00:36:08 temptor: let's just say that it's *not* blocked on any technical issues ;) 2017-06-02 00:36:25 see #musl for a related question 2017-06-02 00:38:17 Glad to see Alpine and musl gaining more widespread support! 2017-06-02 00:38:47 secret confession: I've had a blast porting the JDK to Alpine/musl 2017-06-02 00:39:45 You probably uncovered a lot of bugs and questionable code in the process too :) 2017-06-02 00:40:43 most of it was build issues, so relatively straightforward to address. a couple of more interesting bugs uncovered: one in musl, and one "latent" bug in the JDK 2017-06-02 00:42:26 the key is that the JDK is pretty portable already, so many/most issues have already been addressed in the past 2017-06-02 00:43:22 Yeah, but porting to a new system always turns up surprises. 2017-06-02 00:43:46 tru dat 2017-06-02 01:00:24 Does the JDK have an included test framework? 2017-06-02 01:00:37 several! ;D 2017-06-02 01:01:12 That are self-contained, so no circular deps? 2017-06-02 01:02:06 Or does it require bootstrapping? 2017-06-02 01:03:49 I should be clear: there are a large-ish number of tests in the JDK, implemented for several different test frameworks. in part this is needed since there are several different languages involved (C vs. Java being the most obvious ones). the frameworks/runners are not in the actual JDK sources 2017-06-02 01:04:15 jtreg is the primary test framework used for Java tests 2017-06-02 01:04:46 Ahh, okay - so the tests can not be run on initial building of the jdk because the frameworks aren't available and require the jdk to compile. 2017-06-02 01:05:34 right. normally we use pre-built versions of jtreg 2017-06-02 01:06:32 Okay, that's going to require some fun for bootstrapping :) I'm not the resident Java expert though... 2017-06-02 01:07:21 remember that Java (and therefore jtreg) is platform independent though, so can be built on another platform 2017-06-02 01:08:33 but if building everything from source there are indeed interesting bootstrapping problems. the JDK build depends on a JDK for example :) 2017-06-02 01:08:45 Yes, but a proper build will still require bootstrapping at least one instance. 2017-06-02 01:10:07 So some lowest common denominator required to build the bootstrap environment needs to be available on each build host (and possibly target?) 2017-06-02 01:12:30 The fewer and more commoly available the packages required on the host side, the better. 2017-06-02 01:12:34 building JDK typically depends on a "boot JDK " 2017-06-02 01:12:57 but the JDK can be cross compiled 2017-06-02 01:14:19 Does it actually require a jdk to compile the jdk, or can you build it with a jre to bootstrap? 2017-06-02 01:14:33 JDK 2017-06-02 01:14:38 needs javaca 2017-06-02 01:14:39 javac 2017-06-02 01:15:26 Ug, yeah, I guess no way to get around it in Java :/ 2017-06-02 01:16:04 sorry :) 2017-06-02 01:16:53 Yeah, that's where the porting gets fun - figuring out how to fix bad assumptions build into the JDK. 2017-06-02 01:18:25 I removed the last one ;) 2017-06-02 01:19:31 Okay, so mininum requirements to cross-build are a jdk of at least the previous major version and what else? 2017-06-02 01:21:20 basically the usual suspects: gcc, alsa, various xlibs, … 2017-06-02 01:38:15 aaaanyways - for anybody reading this I'll just reiterate that I/we appreciate any and all feedback on the JDK port for Alpine/musl: what works/what doesn't work? is it useful? etc. 2017-06-02 01:38:34 let us know on portola-dev@openjdk.java.net 2017-06-02 05:17:16 mikeee_: what would be nice is if you guys could provide it as an APK repository 2017-06-02 05:18:52 understood. I take it that would mean producing a .apk, right? 2017-06-02 05:19:16 right 2017-06-02 05:19:24 APKBUILDs create .apks through abuild 2017-06-02 05:22:55 request registered :) 2017-06-02 05:24:30 using so:libfoo.so.X through abuild it is possible to generate an apk that works on any apk distribution that uses so: providers 2017-06-02 05:25:37 (which abuild will gladly infer automatically) 2017-06-02 06:37:27 ncopa: you sec-upgraded (CVE-2017-7650) mosquitto v4.11 to v4.12 in AL 3.6, but I believe that it should be at least sec-patched in AL 3.4 (v1.4.8) & AL 3.5 (v1.4.10) too. they provide the patch: https://mosquitto.org/files/cve/2017-7650/mosquitto-1.4.x_cve-2017-7650.patch (haven't tested whether it applies cleanly out of the box) 2017-06-02 06:44:47 I see that some issues (sec-related it seems) are no longer visible to everyone, like #7367 2017-06-02 06:50:44 przemoc: 403 here after signing in 2017-06-02 06:51:32 can confirm JDK 9 is nice: http://i.imgur.com/PiA7OC1.png 2017-06-02 06:52:14 on musl that is :) 2017-06-02 06:54:12 now show same thing in JDK 8, so we can see the difference 2017-06-02 06:55:16 scadu: I suspect that sec-officers can only see it. just didn't know such restrictions were introduced 2017-06-02 06:56:53 przemoc: seems so. I wasn't aware too. 2017-06-02 07:07:56 I can see the issue but I don't see any restrictions applied to it 2017-06-02 07:08:12 oh right, i see how it is 2017-06-02 07:08:14 yeah the issue is restricted 2017-06-02 09:01:56 vakartel: any opinions on adding a default provides= for php packages? 2017-06-02 09:02:37 also, can anyone with main push access/github access do the following PRs: 2017-06-02 09:02:39 merge: 1611, 1595, 1585, 1583, 1582 2017-06-02 09:02:41 close: 1602, 1591 2017-06-02 09:02:43 cc jirutka 2017-06-02 09:07:27 Shiz: I have provides=php-subpkgname for all php7-subpkgname ones in my APKBUILD but it's somehow wrong, so @jirutka was drop it in final APKBUILD. 2017-06-02 09:07:42 ah 2017-06-02 09:07:58 seems worthy to check it out then, there's a github PR that added them back again 2017-06-02 09:08:00 i pinged you in it 2017-06-02 09:10:31 <_ikke_> +65\4 2017-06-02 09:11:42 also merge: 1587 2017-06-02 09:44:31 jirutka: wasnt going to, php isnt my territory 2017-06-02 09:44:33 :P 2017-06-02 09:48:48 I think we should implement a yaml validation in the APKBUILD 2017-06-02 09:49:51 noo 2017-06-02 09:50:43 Shiz, why? 2017-06-02 09:50:50 yaml is gross 2017-06-02 09:51:03 we use it for secfixes 2017-06-02 09:51:20 but sometimes is not written correctly in the APKBUILD 2017-06-02 09:51:44 #7373 2017-06-02 09:57:39 #7373 should be reported upstream to clair ofc 2017-06-02 09:57:59 but we should do something to have a consistent yaml APKBUILD info 2017-06-02 16:05:31 Ouch! Just looked at https://git.alpinelinux.org/cgit/alpine-secdb/tree/3.6/community.yaml#n40 - Whatever is generating this file is broken! 2017-06-02 16:11:35 Is the format for the secfixes db defined anywhere? 2017-06-03 00:03:44 kaniini: What prevented the 1/8th bar resolution progress meter from working for you? 2017-06-03 00:14:12 kaniini: It looks like all that's needed is adding the additional characters to apk_progress_char, then multiplying bar by the strlen of that, and adding a couple modulos to the loop drawing the bar. 2017-06-03 00:15:00 yes 2017-06-03 00:15:05 but i didn't want to do it that way 2017-06-03 00:16:52 what approach did you want to use? 2017-06-03 00:25:54 i just wanted to do a modulus at the end 2017-06-03 00:27:17 Hmm, that's basically all you need is one modulo strlen at the end. 2017-06-03 00:28:32 You count the number of complete chars incrementing by strlen, then index the last char by modulo 2017-06-03 00:46:41 kaniini: Ahh, unicode bites us, got it :/ 2017-06-03 02:50:20 TemptorSent: you don't need to add the characters btw 2017-06-03 02:50:27 TemptorSent: you just need change last byte of the sequence 2017-06-03 03:11:21 TemptorSent: http://turtle.dereferenced.org/~kaniini/fractional-progress-bar.patch 2017-06-03 03:11:23 erf 2017-06-03 03:11:26 TemptorSent: http://turtle.dereferenced.org/~kaniini/fractional-progress-bar.patch.txt 2017-06-03 03:22:55 gonna just go ahead and ask this here and now: will there (eventually|ever) be support for a package category in apk? pretty much all other packagers have that, and it makes discovery possible 2017-06-03 03:24:57 yes, apk is adding support for that, and also custom data 2017-06-03 03:25:24 nice 2017-06-03 04:44:43 kaniini: Yes, that certainly works easier than tryiung to support the general case :) 2017-06-03 04:54:51 Also, why skip the five-eigths block? 2017-06-03 05:10:33 it renders wrong on my terminal 2017-06-03 05:11:21 Ahh, that's funny... 2017-06-03 07:16:00 awilfox: pretty much all other package managers? which one except portage :P 2017-06-03 07:46:18 Shiz: https://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections 2017-06-03 07:46:25 Shiz: https://en.opensuse.org/openSUSE:Package_group_guidelines / https://en.opensuse.org/openSUSE:Specfile_guidelines#Preamble 2017-06-03 07:47:07 Shiz: https://www.freebsd.org/ports/categories-grouped.html 2017-06-03 07:47:18 neat 2017-06-03 07:54:30 awilfox, Shiz yum as well has groups categories 2017-06-03 07:54:48 groups are something ele though, no? 2017-06-03 07:54:52 they're more like collections of packages 2017-06-03 07:57:01 mmmh true that's quite different than debian categories 2017-06-03 08:06:00 yeah fedora deprecated groups in f18 2017-06-03 08:06:05 it's done repo-side now 2017-06-03 08:06:11 so the repo has to have lists of the packages in a category 2017-06-03 11:24:55 could someone close this one: https://github.com/alpinelinux/aports/pull/1610 2017-06-03 11:24:59 algitbot didnt catch on it 2017-06-03 11:39:54 and this: https://github.com/alpinelinux/aports/pull/1592 2017-06-03 11:40:35 and this https://github.com/alpinelinux/aports/pull/1591 2017-06-03 12:38:56 enough PRs reviewed for now 2017-06-03 12:38:58 :P 2017-06-03 17:33:38 kaniini: Out of curiosity, do the codepoints U+2581-U+2588 render properly for you? 2017-06-03 17:34:02 those are the wrong code points :) 2017-06-03 17:35:27 I know that's not the left-partial blocks, it's the lower-partial blocks :) 2017-06-03 17:36:04 So each fraction would grow the last block upwards until it's full, then start the next. 2017-06-03 20:00:12 kaniini: In apk manifest, is there a compelling reason not to print entries for .PKGINFO and .SIGN.*? 2017-06-03 20:02:52 (or perhaps have a means of displaying the control files as an option?) 2017-06-03 21:37:19 Wiki request: Can we split 'apk' (or 'apk-tools') off as a distinct node from Alpine_Linux_package_management to clarify the documentation? 2017-06-03 21:40:46 i 2017-06-03 21:41:16 *lol* Wrong term :) 2017-06-04 01:45:38 kaniini: Please take a look at (and update to reflect reality :)) https://wiki.alpinelinux.org/wiki/TODO:apk 2017-06-04 01:46:03 Shiz, jirutka - comments? 2017-06-04 02:54:46 TemptorSent: i don't like the \t format 2017-06-04 02:55:15 kaniini: Fair enough, what would be preferable that parses well? 2017-06-04 02:57:33 tab is quite convenient for use in most unix utilities (awk, cut, sort, etc..) and tends not to appear in filenames, so less escaping is required. 2017-06-04 02:59:52 But if there's a better option, I'm all ears :) 2017-06-04 03:03:14 Regarding the rest of the page, that's as best I could recall from previous discussions combined with a reading of the pax spec and tar. 2017-06-04 03:07:02 There, that reads much better (\t to pasted char) 2017-06-04 03:09:12 Grr. Wiki eats real tabs it seems. 2017-06-04 03:09:35 no 2017-06-04 03:09:52 i do not want apk to output tabs for end-user consumers 2017-06-04 03:10:12 because tab behaviour is not consistent across terminals 2017-06-04 03:10:21 Okay? Fixed width columns then perhaps by default? 2017-06-04 03:11:04 Or \t -> n spaces for terminal output by default? 2017-06-04 03:13:21 tab= 2017-06-04 03:13:45 ACTION is largely more interested in update-manager right now 2017-06-04 03:14:20 tab=" " by default, --tabs or --tab="\t" to override. 2017-06-04 03:14:49 ACTION likes tools which have usable terminal output 2017-06-04 03:15:01 Okay, what do you have in mind as 'update-manager' 2017-06-04 03:15:15 ACTION is still largely more interested in update-manager and gnome 3 right now 2017-06-04 03:15:49 TemptorSent: notification applet to invoke apk-gtk upgrade --available 2017-06-04 03:16:32 Oh -- been entirely too long since I messed with gtk in any depth, probably back to 1.2 :) 2017-06-04 03:16:37 TemptorSent: http://github.com/kaniini/apk-gtk 2017-06-04 03:19:24 Looks cool if you have X up. 2017-06-04 04:21:26 kaniini - have you taken a look at #7373? It looks like something that apk should handle rather than the current broken script. 2017-06-04 04:55:10 The secfixes should probably be part of .PKGINFO and be exposed via apk (perhaps apk info --security?) 2017-06-04 06:48:03 the hell is /appp 2017-06-04 06:48:28 apk gen is useless 2017-06-04 06:48:33 for keys 2017-06-04 06:48:53 wait, msiread 2017-06-04 06:55:24 msiwrote too 2017-06-04 06:55:30 anyway i don't recall anything at all related to '/app' in our discussions 2017-06-04 06:55:39 don't invent new things and put them on todo lists 2017-06-04 06:56:00 TODO: stop inventing new things 2017-06-04 06:56:45 likewise, the distinction between gen and archive is not at all clear to me 2017-06-04 06:57:04 gen should be enough on its own 2017-06-04 07:01:19 /app is a complete application stack root, one of the possible plugable layouts as an example. 2017-06-04 07:02:25 apk gen creates a signed apk file using a keyfile, a control directory, and a data directory. 2017-06-04 07:02:29 you said "application stack", any further point you may try to make is invalid 2017-06-04 07:02:48 skarnet: How so? 2017-06-04 07:06:33 What would you consider something like postgresql+postgis+gdal for instance? Or redmine for that matter? 2017-06-04 07:08:47 Anyway Shiz, presumably apk archive would provide a tar-like interface to raw .apk (pax) archives for use from scripts and package build systems. 2017-06-04 07:09:14 this was never even remotely discussed, so don't put it on a todo list as if it was 2017-06-04 07:09:30 you've been told multiple times not to start adding arbitrary new things you come up with 2017-06-04 07:09:39 (re: /app) 2017-06-04 07:09:42 (also: re apk archive) 2017-06-04 07:10:58 Actually, the apk archive functions were discussed and kaniini has a partial implementation in his local repo IIRC. 2017-06-04 07:11:33 apk gen was discussed 2017-06-04 07:11:35 not apk archive 2017-06-04 07:12:10 /app wasn't given a name, but the functionality was discussed as being one of the possible configurations enabled by adding a pkgroot to the apk database. 2017-06-04 07:15:37 kaniini has also discussed 'apk extract' along with several other functions. No, naming isn't defined (and there's a TODO for that) 2017-06-04 07:20:36 Do you have any critique aside from the names I assigned to previously unnamed or ambiguous functionality? 2017-06-04 07:21:05 just because something was briefly mentioned as a possibility does not mean it should be on our todo 2017-06-04 07:21:09 and something like /app should not be 2017-06-04 07:21:25 and i still do not see the point of anything archive-related but apk gen 2017-06-04 07:21:32 Would you prefer I call it 'altroot' 2017-06-04 07:21:44 it is 2017-06-04 07:21:46 not 2017-06-04 07:21:48 about 2017-06-04 07:21:50 naming 2017-06-04 07:22:41 So you'd prefer to just ignore one of the means that planned functionality of apk can be used? 2017-06-04 07:22:48 yes 2017-06-04 07:22:53 WTF? 2017-06-04 07:23:01 just because something can be done, doesn't mean it should 2017-06-04 07:23:21 What's the point of PLUGABLE layout if you don't actually allow plugging the layout? 2017-06-04 07:23:42 you know what 2017-06-04 07:23:48 i'm going to stop right here before i actually get frustrated 2017-06-04 07:24:14 https://www.pgi.com/blog/wp-content/uploads/2014/12/ian-malcolm-meme.jpg 2017-06-04 07:24:15 As for apk archive - would you care to name a tool that can actualy create/list/extract pax archives AND all attributes correctly? 2017-06-04 07:27:41 I'm sorry, I don't understand why showing examples of how a planned feature can be used in several ways is pissing people off. 2017-06-04 07:28:18 Looks like you still have a lot to learn about people. 2017-06-04 07:28:59 Clearly. 2017-06-04 07:32:19 I didn't realize documenting features and proposals was an evil act; I was looking for comments improve clarity, not get reamed for daring to flesh out some details. 2017-06-04 07:35:09 If someone else feels like spending the time searching through the past couple months of -devel archives and documenting the discussions in a cohesive manner, please, by all means - I can find much more entertaing ways to was^H^H^Hspend my time. 2017-06-04 10:02:02 wtf2. why TemptorSent proposal would harm anyone? especially if it's just idea to discuss, not some 12 Angry Alpinists :s 2017-06-04 10:02:32 ideas go on idea boards, not on todo lists 2017-06-04 10:04:27 so let's seperate this on todo list and 'looks cool for me, what do you think?' list then. unecessary flame. 2017-06-04 10:04:46 sure 2017-06-04 10:04:50 my issue is not the idea itself, mind you 2017-06-04 10:05:07 well, aside from other reasons, but not the main issue i got upset 2017-06-04 10:05:23 it's it being expressed in inappropriate venues, and i've complained about this before 2017-06-04 10:05:28 I know, but it's totaly useless to fight, especially when the team is small 2017-06-04 10:05:29 if you have an idea, great, discuss it here or on the ML 2017-06-04 10:05:52 well I didn't want to fight, that's why I left to de-escalate 2017-06-04 10:05:54 :P 2017-06-04 10:08:58 Shiz: so you suggest TemptorSent to continue on ML regarding his ideas? cool. 2017-06-04 10:09:39 no, here is fine too 2017-06-04 10:10:21 just as long as it doesnt hijack other discussions :p 2017-06-04 10:12:40 what bothered me was more that i told him undiscussed or only briefly mentioned ideas should not be on the todo list 2017-06-04 10:12:46 and it escalted into discussing the ideas itself 2017-06-04 10:12:57 which was not the point 2017-06-04 10:16:14 Shiz: if I was TemptorSent, I'd interpret this as an attack. what my point is it's really really useless to fight each other. I know it could be hard sometimes, but hey, we are no longer in pre-school ;) 2017-06-04 10:16:45 it's really exhausting 2017-06-04 10:18:47 i wasn't really clear on this, but it's not like i consider myself free of blame for how it escalated 2017-06-04 10:19:14 that doesn't change the fact that it did and i didn't want pursue the discussion further at the time :p 2017-06-04 10:19:31 me leaving was not some kind of blame game on temptor, but just a move to de-escalate the discussion 2017-06-04 10:21:58 I just want to avoid situation that happened when ^7heo, jirutka and barthalion didn't get along. there was nothing on this channel, but drama. eventually barthalion has left. 2017-06-04 10:23:19 i presume that somehow involved arch 2017-06-04 10:23:21 but point taken 2017-06-04 10:27:09 not sure if it involved Arch. anyway, have a nice Sunday ;) 2017-06-04 10:28:13 likewise 2017-06-04 10:28:24 sorry if i came across more crass or attacking than i intended to, TemptorSent 2017-06-04 10:29:43 y'aww :3 2017-06-04 10:30:03 shiz x temptorsent <3 2017-06-04 10:31:13 i think im claimed by skarnet already 2017-06-04 11:10:09 be a strong, independent man, not claimed by anyone! 2017-06-04 11:12:45 and fwiw I also told TemptorSent several times in the past that it was not the time and place for discussing certain things (which may very well be good ideas in a vacuum) because other things had priority and time and energy are not infinite; and it *is* hard for him to accept that others cannot immediately focus on what is capturing his attention at a given time 2017-06-04 11:13:21 which makes productive discussion difficult, and has a tendency to annoy people, me very much included 2017-06-04 15:03:19 I see distros are hard 2017-06-04 15:07:12 Sorry for annoying everyone - I'll stop trying to contribute as my contributions are clearly not required nor desired. 2017-06-04 15:07:50 TemptorSent: for me they are valuable 2017-06-04 15:08:37 TemptorSent: imo Shiz has raged because you placed suggestions in todo list and then you know. 2017-06-04 15:09:10 TemptorSent: for me they are valuable 2017-06-04 15:09:13 same here 2017-06-04 15:10:38 It doesn't appear to matter much the particulars, every time I try to discuss anything that's not preexisting, I'm instantly shot down by at least 3 people (not always the same ones) 2017-06-04 15:12:50 TemptorSent: maybe you are too cool for them ;f 2017-06-04 15:13:01 I wrote several thousands of lines of code that's essentially been wholesale rejected out of hand because nobody is willing to look at the individual components and give me feedback, they just look at the whole repo and say 'fuck it, it's too much!' 2017-06-04 15:14:00 well 2017-06-04 15:14:03 right 2017-06-04 15:14:23 even OpenBSD people seem to be more tolerant 2017-06-04 15:14:42 I'm not 'cool' at all, I'm an old fart who's been there and done that in the software and hardware world and who has mostly retired. I don't really give a shit about anything other than making software work better for my needs and hopefully the needs of others. 2017-06-04 15:15:18 TemptorSent: this. 2017-06-04 15:17:00 TemptorSent: btw. have you tried OpenBSD? It's has a bit more "traditional" environment/community if that's what you're looking for 2017-06-04 15:17:42 Yeah, OpenBSD doesn't fit my current needs (embedded) so well unfortunately. 2017-06-04 15:19:31 hm? 2017-06-04 15:19:36 I came to Alpine because it appeared to fit 80% of my requirements out of the box and has much lower maintenance overhead than funtoo, which was my primary dist for many years. 2017-06-04 15:19:39 why it fails with embedded? 2017-06-04 15:19:54 I'm getting curious 2017-06-04 15:19:54 Hardware support is lacking. 2017-06-04 15:20:42 One of my porjects requires a rpi with GPU drivers for doing math. 2017-06-04 15:21:35 Another I'm going to try to cram into the cpu of an SD card. 2017-06-04 15:21:47 is gpu in rpi able to do math? :D 2017-06-04 15:22:10 Yep, so I can use the CPU to process the result. 2017-06-04 15:23:00 FFTs and DCTs are easy to abuse the GPU for. 2017-06-04 15:30:05 Anyway, it seems there is nothing productive coming out of my involvment here, so I might /lurk around for a while, but I really do have better things to do with my time and I'm sure the devs do too. 2017-06-04 15:30:24 That's how Alpinelinux dies slowly. 2017-06-04 15:33:42 I don't see Alpine dying any time soon, just maturing slowly. 2017-06-04 15:34:03 skrzyp: alpine is dying? 2017-06-04 15:34:12 how do you figure, i dont see systemd in it 2017-06-04 15:35:22 leo-unglaub: it's about people, not systemd 2017-06-04 15:38:29 leo-unglaub: plenty of systemd distributions will be alive a decade from now 2017-06-04 15:38:58 skrzyp: could you just cut the doom, gloom and overdramatization? thanks 2017-06-04 15:39:22 you guys are sounding like the Devuan ML right now, and it's not a compliment 2017-06-04 15:39:46 skarnet: ok. 2017-06-04 15:39:49 thank you. 2017-06-04 15:40:08 and that was a bullshit overreaction 2017-06-04 15:40:46 but if it's what it takes to get back to productive conversation in this channel, so be it 2017-06-04 15:49:17 ACTION wonders about locale/unicode support in alpine. 2017-06-04 15:49:34 I found a ticket from 2011 or so, where CHARSET=UTF-8 was added to /etc/profile 2017-06-04 15:50:21 but despite this, it seems my system doesn't handle non-ASCII. Can't find any mentin in the wiki. 2017-06-04 15:50:38 Was wondering if this works for others? Did you have to setup anything special? 2017-06-04 15:51:04 test case: echo -e "\xc3\x96" -> should print an "O" with umlaut. 2017-06-04 15:55:15 https://github.com/gliderlabs/docker-alpine/issues/144 2017-06-04 15:56:01 suggests missing support in musl. Is this still current? 2017-06-04 16:29:56 it works on my system, both in a TTY, in xfce4-terminal and over ssh to another alpine box... wish I could help you but in my case it just worked 2017-06-04 16:31:09 my env is TERM=rxvt-256color, CHARSET=UTF-8, and I have ncurses installed (not that it should matter) 2017-06-04 18:24:18 trfl: thanks, appreciated. Have figured it out on my side: works on TTY and via SSH, just like you described (I don't have any GUI stuff installed). 2017-06-04 18:25:25 The problem for me was tmux. It tries to guess if UTF-8 is availble, by looking at $LANG and some other variables. But these are empty on apline since musl has its own variable. 2017-06-04 18:25:38 So the fairly simple fix is to run "tmux -u" to force utf-8. 2017-06-04 21:06:48 what went on here when i was away 2017-06-04 21:30:28 Shiz, tl;dr welcome to bs distro politics! it's ok, that drama was festering underneath the channel for weeks 2017-06-04 21:30:42 it's probably good you got it out in the open so it stopped 2017-06-04 21:30:52 sigh... 2017-06-04 22:10:17 i wouldn't give it the word politics really 2017-06-04 22:10:50 i haven't read the 'todo' list that was proposed but apk archive was not ever on my todo list :p 2017-06-04 22:11:15 i think largely it came off as like some dude comes in and is like do this this and this 2017-06-04 22:11:23 and it's like who the fuck are you 2017-06-04 22:11:35 if i were to guess reading the backscroll 2017-06-04 22:14:17 rfs613, oh yeah I have tmux aliased to tmux -2u 2017-06-04 22:14:28 the problem is that TemptorSent is an "idea man" 2017-06-04 22:15:06 rfs613: CHARSET=UTF-8 is not supported by musl; you have to set a proper locale e.g. LANG="C.UTF-8" 2017-06-04 22:15:31 rfs613: we should probably fix it 2017-06-04 22:15:42 rfs613: if you open a bug, i'll try to get to it sometime this week 2017-06-04 22:42:59 kaniini: my understanding is that C.UTF-8 is the default for musl. Adding support for others is another matter (based on musl maintainer's email on openwall list in 2014) 2017-06-04 22:43:41 so I'm not sure if adding an explicit LANG in alpine is worthwhile... it might give impression of full locale support. 2017-06-04 22:44:21 however it might be worth noting in the wiki/faq 2017-06-05 03:52:48 awilfox: you're welcome 2017-06-05 03:57:38 now let me be explicit and clear 2017-06-05 03:57:47 This situation was mismanaged from the start. 2017-06-05 03:58:15 I saw it and I didn't do anything - I left the channel for personal convenience - because it was *not my job* 2017-06-05 03:58:30 I came back and nothing had changed 2017-06-05 03:59:10 so you guys need to grow a spine. Seriously. 2017-06-05 03:59:31 If you have things to say to someone, SAY IT. Without being mean. Without aggressivity. 2017-06-05 03:59:53 Just lay things out on the table and work on a solution together. 2017-06-05 04:00:02 (If people won't listen, then escalate.) 2017-06-05 04:00:24 But yesterday was *far too late* for a drama-less, peaceful resolution, it seems. 2017-06-05 04:01:10 "drama festering for weeks" should not be happening 2017-06-05 04:01:11 ever 2017-06-05 04:01:40 I just said what I had to say, and people overreacted - of course they did, since nobody had been open with them before. 2017-06-05 04:04:13 So now, I'm the bad guy. I don't mind, but I feel the need to point out that I hate drama and politics, that I generally do everything I can to avoid it, and that any attempt to pin any kind of blame on me will end up very badly. 2017-06-05 04:04:55 This happened because somebody here (a collective) didn't do their job. 2017-06-05 04:05:40 So now would be the time for some introspection. 2017-06-05 08:48:56 it seems like i missed some more 2017-06-05 09:04:34 Shiz: nothing of value. algitbot should be able to tell you what you want to know anyway. 2017-06-05 09:06:22 morning 2017-06-05 09:06:47 oha 2017-06-05 09:07:24 how are things going? 2017-06-05 09:08:20 could've gone better as evidenced by yesterday :P 2017-06-05 09:11:40 Shiz: anything new on your sys-llvm experiment? :) 2017-06-05 09:12:12 didn't get past the bootstrap stuff yet since nothing to run it on ;p but good otherwise 2017-06-05 09:12:20 made a list of what components are supported by which arches 2017-06-05 09:14:56 what happened? 2017-06-05 09:15:02 what happened yesterday? 2017-06-05 09:15:28 i guess tensions rose and now temptorsent left 2017-06-05 09:17:35 should i read the backlog? 2017-06-05 09:17:42 someone give me a resume? 2017-06-05 09:18:16 i presume you mean a summary :p 2017-06-05 09:19:27 mostly temptor not feeling like his contributions were not appreciated, while me being annoyed at his ideas not being presented in the right ways (e.g. new discussions on #alpine-devel or the ML) 2017-06-05 09:22:16 ncopa: if there's one person who should read the backlog, it's you 2017-06-05 09:22:19 and I mean it 2017-06-05 09:24:54 skarnet: ok i will 2017-06-05 09:41:31 skarnet and shiz did a good job at providing reasonable feedback at ts, he however seems to lack a feedback loop and instead of adjusting he aborted protocol instead, wouldn't call it drama, drama is jakegate/grsecgate, this was much less dramatic 2017-06-05 09:41:55 feedback came way too late 2017-06-05 09:42:00 that's why he overreacted 2017-06-05 09:42:12 no, there was constant feedback 2017-06-05 09:42:36 ok, I can't judge that, I wasn't there 2017-06-05 09:42:57 but it's often the case that feedback that may seem explicit to you isn't at all for the person it's directed at 2017-06-05 09:43:29 sure, you were, you also engaged previously in some. even TS admits it: "17:10:37 TemptorSent: I'm instantly shot down by at least 3 people (not always the same ones)" 2017-06-05 09:43:40 yes, that was early 2017-06-05 09:44:03 then I left because I was tired of doing it, had other things to do, and didn't want to step on other people's job 2017-06-05 09:44:04 i remember being one of them weeks, if not months ago 2017-06-05 09:44:13 once 2017-06-05 09:44:22 yes 2017-06-05 09:44:34 but I don't know what happened for the next month 2017-06-05 09:44:41 and i remember you also engaging him multiple times 2017-06-05 09:45:10 you and shiz deserve lots of respect, not only for providing feedback, but also doing it in a very civilized way 2017-06-05 09:45:58 over the last weeks, not just yesterday 2017-06-05 09:48:04 Thank you. TemptorSent has interesting ideas and is smart, my only issue is he's write-only. I left when I figured that out. But I *did* expect other people to say what needed to be said - core Alpine devs with a more official badge than I have. I thank Shiz for doing it. 2017-06-05 09:48:48 On a completely unrelated topic: is there a way to tell apk "delete this package and everything that depends on it" ? 2017-06-05 09:49:14 <^7heo> kaniini: as a side note "completed" and "with errors" are mutually exclusive, for the user semantics. 2017-06-05 09:49:24 pk del -r 2017-06-05 09:49:27 apk del -r * 2017-06-05 09:49:31 Shiz: thanks 2017-06-05 09:49:31 skarnet: ^ 2017-06-05 09:49:43 apk del -r * is probably a bad idea :p 2017-06-05 09:52:07 trfl: it looks like Shiz used '*' for correct his previous answer and it's not a part of apk command :P 2017-06-05 09:52:17 ACTION cpt obvious 2017-06-05 09:54:10 another unrelated topic: UX fail: "sys" install mounts the disk on /mnt/boot and /mnt, so doing stuff in /home and /usr does it in RAM, which fills up fast, and is not permanent 2017-06-05 09:54:43 on what planet does it make sense to mount a disk in /mnt and not have at least symlinks into it 2017-06-05 09:55:52 sys installs shouldn't be activated / take effect before a reboot right? like, I would assume the target to be unaffected by anything I do until I've rebooted into the actual installation 2017-06-05 09:56:17 <^7heo> scadu: also the problem with barthalion was much deeper than the visible drama. 2017-06-05 09:56:27 ah, you're supposed to reboot after a sys install? ok, my bad then, sorry. 2017-06-05 09:56:54 it would do well if the script informed you about this, i suppose 2017-06-05 09:56:59 also 2017-06-05 09:57:03 ok so i read the backlog 2017-06-05 09:57:18 ncopa: the xorg setup script should probably sed -i -e 's/nomodeset //g' /etc/update-extlinux.conf 2017-06-05 09:57:25 it won't work well if it doesn't for a lot of cases :P 2017-06-05 09:57:34 (and run update-extlinux) 2017-06-05 09:57:37 you [skarnet] and shiz deserve lots of respect, not only for providing feedback, but also doing it in a very civilized way 2017-06-05 09:57:44 +1 2017-06-05 09:58:11 <^7heo> Shiz: also the problem with barthalion didn't directly involve arch no. 2017-06-05 09:58:19 ^7heo: I'm not sure if I'm aware of all issues 2017-06-05 09:58:43 ^7heo: it was more poking fun than a serious comment :p 2017-06-05 09:59:06 can we please try look forward? and leave old conflicts behind 2017-06-05 09:59:14 right 2017-06-05 09:59:19 ncopa: on one condition 2017-06-05 09:59:59 that *you* (yes, you, as well as the other Alpine core devs) learn from the experience and do the dirty work yourself next time 2017-06-05 10:00:14 ok. point taken 2017-06-05 10:00:54 the problem is that i need to have time off 2017-06-05 10:01:07 i cannot constantly babysit the irc chan 2017-06-05 10:01:12 then appoint watchdogs 2017-06-05 10:01:30 people with @ infront of their names are all eligible i guess 2017-06-05 10:02:12 tbh, i think Shiz did a relatively good job too 2017-06-05 10:02:26 skarnet and thanks for helping handle the situation 2017-06-05 10:02:38 shiz has overall a very impressive performance over the last few months 2017-06-05 10:03:05 ncopa: no, nobody did a good job. If we had, it wouldn't have lasted so long. 2017-06-05 10:03:50 maybe I'm being severe, or demanding, but a lot of time and energy have been wasted and drama has occurred when it shouldn't have been the case in the first place. 2017-06-05 10:04:12 not sure, with writeonly subjects and civilized counterparts it takes some time, otherwise there might be more demand for CoCs 2017-06-05 10:04:30 Next time, Shiz or I or you or whoever else need to react *much sooner*. 2017-06-05 10:04:30 if people start kickbanning like yankees 2017-06-05 10:04:54 uneccessary time and energy has been wasted, i agree 2017-06-05 10:07:06 <^7heo> Shiz: right; but I read the backlog ('cause seriously this is -devel) and I figured I would answer as I read. 2017-06-05 10:09:10 i'm not sure how to have nipped this in butt earlier, but i will think about it 2017-06-05 10:09:21 ncopa: got time to talk about llvm? ;p 2017-06-05 10:09:50 hm... :-/ 2017-06-05 10:09:51 ok 2017-06-05 10:09:55 lets talk about llvm 2017-06-05 10:10:18 Shiz: nip in the butt? I don't think that's right, but I like it ;) 2017-06-05 10:10:30 :p 2017-06-05 10:10:38 <^7heo> < lxGzx53qO34r> shiz has overall a very impressive performance over the last few months 2017-06-05 10:10:43 <^7heo> I second that. 2017-06-05 10:10:47 he means decades 2017-06-05 10:11:02 <^7heo> He's a pleasure to deal with 2017-06-05 10:11:13 <^7heo> even when I'm underfed or in the wrong mood. 2017-06-05 10:11:19 <^7heo> So yeah +1 Shiz @ 2017-06-05 10:11:30 <^7heo> skarnet: also I wouldn't know about this. 2017-06-05 10:12:02 Shiz: what is the status on llvm? 2017-06-05 10:12:32 ncopa: so 2017-06-05 10:12:55 i've been testing various parts of a GNU-less toolchain on various arches 2017-06-05 10:13:41 x86, x86_64 and aarch64 can fully bootstrap a clang (instead of gcc), compiler-rt (instead of libgcc), llvm-libunwind (instead of libunwind), libc++ (instead of libstdc++), lld (instead of binutils ld), elftoolchain (instead of binutils) 2017-06-05 10:13:45 -based system 2017-06-05 10:14:08 fabled: i may want your opinion on this too ^^^ 2017-06-05 10:14:21 armhf can do that minus lld, ppc64le minus llvm-libunwind and lld, and s390x can basically only use clang and libc++ 2017-06-05 10:14:48 the reason why clang is interesting for us, and sorta by extension the other components minus elftoolchain 2017-06-05 10:15:01 is that significant development power is being switched to clang 2017-06-05 10:15:07 not only in general, but also with regards to hardening 2017-06-05 10:15:27 google has switched android to clang entirely, pretty much, and is putting significant effort into hardening efforts for clang 2017-06-05 10:15:31 we've been talking about going llvm/clang once in a while for past few years... mostly it's been llvm not been mature enough/not good enough optimizer 2017-06-05 10:15:33 think stuff like UBsan and CFI 2017-06-05 10:15:39 but afaik, it's getting better 2017-06-05 10:16:04 is compiler-rt a first class citizing in llvm nowadays? last i checked it was turned off by default, and required libgcc 2017-06-05 10:16:11 it does not require libgcc 2017-06-05 10:16:13 these days 2017-06-05 10:16:20 it has its own libgcc-compatible ABI implementation 2017-06-05 10:16:25 (compiler-rt builtins.a) 2017-06-05 10:16:47 you have to enable it explicitly to be used by default when configuring clang, but that's about it afaics 2017-06-05 10:17:07 cool 2017-06-05 10:17:13 only thing I had to add myself was crtbegin.s and crtend.s, which are mostly empty on modern toolchains except for a single __dso_handle symbol in crtbegin.s 2017-06-05 10:17:18 is there any recent comparisons on the optimizer results? 2017-06-05 10:18:00 lemme check 2017-06-05 10:20:09 https://www.phoronix.com/scan.php?page=article&item=gcc-61-clang39 2017-06-05 10:20:12 is a recent one i can find 2017-06-05 10:20:12 how about the other languages: Ada and Fortran ? 2017-06-05 10:20:30 it seems like they don't differ much overall, clang winning on some fronts, gcc on others 2017-06-05 10:21:04 we currently also do gcc-java ->openjdk7 -> openjdk8 bootstrap 2017-06-05 10:21:21 i suppose we will have to do that differently in future anyways 2017-06-05 10:21:34 since gcc-java is going away 2017-06-05 10:21:37 we already have a number of languages that need to be cross-bootstrapped, so i don't think that is a major issue 2017-06-05 10:21:39 and also that :p 2017-06-05 10:21:43 yeah 2017-06-05 10:21:57 fabled: i mostly focus on the system toolchain (build-base essentially), so i didn't look too much at ada and frotran 2017-06-05 10:21:58 i'm just wondering... do we need to keep gcc for them still 2017-06-05 10:22:03 but i don't think the llvm project has implementations for them 2017-06-05 10:23:20 linux kernel still needs gcc 2017-06-05 10:23:34 the kernel is one othe thing 2017-06-05 10:23:47 google and the likes already compile linux with clang and have patches for it submitted upstream 2017-06-05 10:24:03 e.g. https://lwn.net/Articles/717463/ 2017-06-05 10:24:40 but i would not be opposed to just building the kernel with gcc -- I think it's fine for specific packages to be compiled with gcc if it can't be helped 2017-06-05 10:24:56 the point is more what compiler builds the system overall -- the system compiler ;) 2017-06-05 10:25:09 of note is that freebsd also switched to clang as system compiler recently 2017-06-05 10:26:33 The following is personal opinion 2017-06-05 10:26:35 fabled: is Ada even needed? not a single packages in aports requires it (even as makedepends) 2017-06-05 10:26:56 To me, the main advantage of clang is that it provides an *alternative* to gcc 2017-06-05 10:27:05 we've had ada bugs and requests; but hmm... maybe it's used for private things only... 2017-06-05 10:27:21 iow, it breaks the gcc monopoly. It prevents depending on it. It removes extra power from gcc devs. 2017-06-05 10:27:22 there's no reason we can't include an ada package anyway 2017-06-05 10:27:36 we probably dont want remove gcc 2017-06-05 10:27:36 switching to llvm does not mean we nuke gcc from repos entirely, just like we dont keep llvm out just because gcc is our system compiler 2017-06-05 10:27:40 yes :) 2017-06-05 10:27:51 Moving into an all-clang world is not a desirable goal. 2017-06-05 10:28:13 Between a GNU-controlled world and an Apple-controlled world, I choose... neither? 2017-06-05 10:28:38 skarnet: well, by that same logic you wouldn't choose gcc as system compiler either 2017-06-05 10:28:38 Both projects need to be competing, in order for them to keep living and keep being good for users 2017-06-05 10:28:44 since it would be a GNU-controlled world :P 2017-06-05 10:28:52 i agree that competition is needed, but there can only be one system compiler (mostly) 2017-06-05 10:29:19 as long as the alternative exists, I suggest that the system compiler be chosen on pure technical merit 2017-06-05 10:29:30 right. 2017-06-05 10:29:34 i outlined some of that above 2017-06-05 10:29:44 mostly that more hardening development seems to be going into clang 2017-06-05 10:30:00 from what I picked up, gcc's sanitizer implementations are not particularly good or easy to salvage 2017-06-05 10:30:06 indeed, those are good arguments 2017-06-05 10:30:09 UBsan and CFI 2017-06-05 10:30:09 while clang's ubsan is supposedly quite decent and the CFI is interesting 2017-06-05 10:31:03 of course, I also have to outline the drawbacks of switching to LLVM 2017-06-05 10:31:10 from the top of my head, those are the following 2017-06-05 10:31:32 - clang/LLVM is bigger than gcc (in package/installed size, but likely also in code -- although the LLVM code is quite more readable despite being C++) 2017-06-05 10:31:53 - some packages will need fixing to compile with clang, and we need to do a full aports build to determine issues of course 2017-06-05 10:32:14 how the heck can you write something cleaner than gcc that's also bigger 2017-06-05 10:32:19 i feel like freebsd's ports can help us there since they switched to clang already, but undoubtedly some work has to be done by ourselves too 2017-06-05 10:32:25 skarnet: idk, try reading reload.c 2017-06-05 10:32:27 :P 2017-06-05 10:32:47 one specific issue i encountered with clang was that it does not support the -no-pie option 2017-06-05 10:32:53 it supports -nopie and -fno-pie, but not -no-pie 2017-06-05 10:33:01 it broke go and ghc cross-compiles, but that's an easy fix 2017-06-05 10:33:14 i have a patch for both in my tree 2017-06-05 10:33:20 what scares me most is the extra job with all the packages 2017-06-05 10:33:25 Shiz: I led the gentoo clang project until The Falling Out(tm) (i.e.: this 1 trick, actually filing useful bugs and expecting others to act on them, makes gentoo devs HATE you! click to find out more!) 2017-06-05 10:33:33 Shiz: and I upstreamed a lot of my work 2017-06-05 10:34:02 ncopa: i agree, which is obviously why i'd propose locally running a full aports build against clang and see what breaks 2017-06-05 10:34:04 Shiz: so hopefully clang-as-system-compiler is already easier than it would have been, but you can always ping me for help, as it is our(Adelie) goal too, to someday use clang instead of gcc for arches that are supported 2017-06-05 10:34:07 awilfox: that's good to hear :) 2017-06-05 10:34:20 yes, good to hear 2017-06-05 10:34:35 (by locally i mean: not against live systems - i'm not sure if i have a system powerful enough to complete a full aports build that takes shorter than say, a month) 2017-06-05 10:34:58 duncaen: is clang/llvm as system compiler a goal for void linux? 2017-06-05 10:35:21 virtualbox, spidermonkey, elfutils, ffmpeg, bird, esomidas, gnucap, iproute2, syslinux, efivar, glibc 2017-06-05 10:35:28 were the packages we had to build with gcc 2017-06-05 10:35:40 good news on that last one, for alpine :D 2017-06-05 10:35:42 i'm pretty sure ffmpeg should support clang now 2017-06-05 10:35:50 it's built for macos systems at the very least 2017-06-05 10:36:04 luckily i know some ffmpeg devs so i can poke them on the matter 2017-06-05 10:36:06 :p 2017-06-05 10:36:08 Shiz: IIRC it was some USE flag combination.. i.e. different plugins 2017-06-05 10:36:12 ah 2017-06-05 10:36:20 luckily we don't have to deal with that either :p 2017-06-05 10:36:29 it didn't /always/ need gcc, but some (maybe x264?) plugin did not like being built with clang 2017-06-05 10:36:32 (also, I didn't know there was a gentoo clang project -- interesting) 2017-06-05 10:36:41 ~ » x264 --version 2017-06-05 10:36:43 x264 0.148.2748 97eaef2 2017-06-05 10:36:44 Shiz: there isn't now \o/ 2017-06-05 10:36:46 built on Jan 28 2017, gcc: 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.42.1) 2017-06-05 10:36:47 :p 2017-06-05 10:38:13 so, what are the blockers for switching to llvm/clang as our system compiler? 2017-06-05 10:38:21 some of our architectures? 2017-06-05 10:38:26 like s390x 2017-06-05 10:38:36 Shiz: the only cool part is that I'm the only person (afaik) besides drobbins who got run out of gentoo by council@ and they still accept my patches XD 2017-06-05 10:38:46 ncopa: it depends on how many parts of the llvm toolchain we want to adopt 2017-06-05 10:38:57 clang itself is fine on all architectures 2017-06-05 10:38:59 ncopa: oh ppc64le is immature on clang. it will work but it may not generate good code. just fyi. 2017-06-05 10:39:11 :-/ 2017-06-05 10:39:12 like it won't generate /bad/ code, or SIGILL or anything 2017-06-05 10:39:14 the issue is to be able to use CFI, you need to use LTO 2017-06-05 10:39:21 but it isn't as fast as gcc's code because it's still WIP 2017-06-05 10:39:24 and for that you need either lld or binutils gold with the clang plugin 2017-06-05 10:39:37 also something about IBM putting effort into gcc and not getting to clang yet :P 2017-06-05 10:39:39 speaking of SIGILL 2017-06-05 10:39:44 and to not rely on libgcc, you'd want compiler-rt too 2017-06-05 10:39:48 any progress on the investigation on that point? 2017-06-05 10:39:58 which is not available on s390x (as the sole platform) 2017-06-05 10:40:00 Shiz: does gold work with musl now? last I knew it didn't 2017-06-05 10:40:08 awilfox: it should 2017-06-05 10:40:09 but that was late 2051 2017-06-05 10:40:12 2015 * woops 2017-06-05 10:40:15 we package it and i tried to compile something with it 2017-06-05 10:40:17 it worked fine 2017-06-05 10:40:17 I'm not a time traveler, I swear! 2017-06-05 10:40:26 skarnet: is the issue registered on bugs.a.o? 2017-06-05 10:40:47 probably not 2017-06-05 10:40:59 https://txt.shiz.me/YzdmOGE2OT 2017-06-05 10:41:32 skarnet: can you run down the issue for me again 2017-06-05 10:41:46 skarnet: I actually managed to get alpine to boot in virtualbox again after much ~manual labour~ 2017-06-05 10:41:53 (why oh why is lvm2 not on any alpine iso?!) 2017-06-05 10:42:15 skarnet: so I can take a stab at gdb 2017-06-05 10:42:16 i thought it was on extended 2017-06-05 10:42:24 awilfox: lvm2 should be on the extended iso? 2017-06-05 10:42:28 Shiz: no, I had to #apk add it on extended 2017-06-05 10:42:31 it was not there to start with 2017-06-05 10:42:41 luckily I did not need any special conf to get the network going 2017-06-05 10:42:49 I can imagine that going very bad if I had my wifi-only laptop 2017-06-05 10:43:02 since the extended iso doesn't have b43 (due to non-free blob, of course) 2017-06-05 10:43:02 awilfox: s6-rc-compile either succeeds, or segfaults, or busyloops, on Alpine 3.6 (.0 or .1) and the user code is good. Shiz and kaniini had a look and there's an unaligned return instruction somewhere IIRC. The usual suspect, grsec, was innocented because it breaks on vanilla too. 2017-06-05 10:43:22 skarnet: oooh, nasty 2017-06-05 10:43:25 skarnet: compiler bug! I'm out. 2017-06-05 10:43:37 ncopa: another note is that this is not a switch that we have to do for all architectures immediately, imo 2017-06-05 10:43:48 my tree makes it possible to switch between build-base variants freely 2017-06-05 10:43:50 awilfox: chicken! XD 2017-06-05 10:43:56 yes in fairness freebsd uses gcc on sparc64 and arm64, and clang on all others 2017-06-05 10:43:59 so we can decide to use LLVM on arches that it's mature for 2017-06-05 10:44:05 and keep gcc on others 2017-06-05 10:44:11 skarnet: can you please collect the details and reproducer on bugs.a.o 2017-06-05 10:44:27 skarnet: are we gcc7 in this crap now? or still 6? 2017-06-05 10:44:35 3.6 is 6.3 2017-06-05 10:44:37 (symmetry) 2017-06-05 10:44:40 I can, but Shiz and kaniini have more details than I do at this point 2017-06-05 10:44:45 and yes, 6.3 2017-06-05 10:44:46 Shiz: that was my next question, if we could use gcc on some archs 2017-06-05 10:44:53 7.1 has some "interesting" ideas on alignment for x86_64 but I only saw it on -march=haswell 2017-06-05 10:44:56 not =nocona or =generic 2017-06-05 10:44:58 ncopa: yes 2017-06-05 10:45:01 dunno what arch/tune alpine uses 2017-06-05 10:45:10 ncopa: essentially i talked it over with kaniini and my thing has the following behavior 2017-06-05 10:45:27 build-base is turned into another virtual for either build-base-gnu or build-base-llvm 2017-06-05 10:45:28 hmm, 6.3? haven't seen anything myself with 6.3 2017-06-05 10:45:31 build-base-gnu is the previous build-base 2017-06-05 10:45:37 build-base-llvm is the... llvm one 2017-06-05 10:45:43 do I need to register on bugs.a.o specifically? (I don't have an openid account) 2017-06-05 10:45:48 skarnet: yes 2017-06-05 10:45:52 skarnet: it's redmine 2017-06-05 10:45:53 unfortunally yes 2017-06-05 10:45:54 in build-base we can trivially add an arch switch to select which one to install by default 2017-06-05 10:46:10 Shiz: makes sense 2017-06-05 10:46:33 what about cross-compiling? 2017-06-05 10:46:38 Shiz: there is a way to tell apk to install a satisfying package for a virtual without user intervention? docs? 2017-06-05 10:46:55 we are talking about makeing the buildserver build some package with crosscompiler and some with native 2017-06-05 10:46:57 awilfox: install_if 2017-06-05 10:46:58 ncopa: llvm can be built with all architectures built in to itself, so that you can do cross-builds from a single clang installation 2017-06-05 10:47:02 ^ 2017-06-05 10:47:11 i modified bootstrap.sh 2017-06-05 10:47:17 it supports llvm-based bootstrapping now 2017-06-05 10:47:19 :P 2017-06-05 10:47:26 it has an optional second argument to determine the toolchain type 2017-06-05 10:47:30 defaults to gnu, other option is llvm 2017-06-05 10:47:36 so basically, crosscompiling works better with llvm 2017-06-05 10:47:40 advantage is that you only need to compile llvm/clang for the target system 2017-06-05 10:47:51 as opposed to both a cross-gcc and a gcc for the target 2017-06-05 10:48:01 that llvm cross stuff was quite the toy back when I was doing bootstrapping for stuff.. unfortunately musl had issues with clang back then 2017-06-05 10:48:09 https://github.com/Shizmob/aports/blob/system-llvm-elftoolchain/scripts/bootstrap.sh#L84-L135 2017-06-05 10:48:13 the beef of the script 2017-06-05 10:48:32 it's more lines because the packages in an llvm system are split up 2017-06-05 10:48:45 instead of like gcc where the gcc package builds gcc, libgcc, libstdc++, etc 2017-06-05 10:49:39 ok next question 2017-06-05 10:49:47 when we upgrade llvm 2017-06-05 10:49:59 how much needs to be rebuilt? 2017-06-05 10:50:36 with gcc we can normally just upgrade gcc to new version and thats it 2017-06-05 10:50:44 if we upgrade llvm, what is needed to be done? 2017-06-05 10:50:45 right 2017-06-05 10:51:21 currently we need rebuild mesa i think 2017-06-05 10:51:21 the packages that are version-locked and dynamically linked against llvm need to be rebuild 2017-06-05 10:51:37 iirc (this may have changed) minor versions are ABI compatible, major versions may not be, but a big warning is posted if they do actually change it 2017-06-05 10:51:40 which i think is llvm, clang, lld 2017-06-05 10:51:42 and that only happened once 2017-06-05 10:51:59 Shiz: and mesa, and clamav 2017-06-05 10:52:03 right. 2017-06-05 10:52:13 i was talking about packages within the llvm universe :p 2017-06-05 10:52:17 version locked is the clang,lld,libc++,compiler-rt? 2017-06-05 10:52:19 yes clamav on a clang-as-system-compiler system will dynamically link to clang so it can do some weird voodoo with its heuristics 2017-06-05 10:52:23 compiler-rt is not version locked 2017-06-05 10:52:27 nor is libc++ 2017-06-05 10:52:33 ok 2017-06-05 10:52:35 good 2017-06-05 10:52:45 lldb? 2017-06-05 10:52:53 idk if alpine ships qt; qt-creator will link to llvm libs too and need rebuilding on version bump 2017-06-05 10:53:11 [sorry if this information isn't relevant, I may have missed the question] 2017-06-05 10:53:13 yes, lldb too it seems 2017-06-05 10:53:29 gdb is not version locked against gcc 2017-06-05 10:53:31 ok 2017-06-05 10:53:54 give them time.. gcc 7 introduces dwarf 5 which requires new gdb 2017-06-05 10:53:55 awilfox: and qt-creator uses llvm even if we use gcc as system compiler? 2017-06-05 10:53:57 but it doesn't use it default 2017-06-05 10:54:13 ncopa: it will only link against llvm if it is available at compile time 2017-06-05 10:54:22 ok 2017-06-05 10:54:28 ncopa: it is used for code completion (like xcode or atom editor) 2017-06-05 10:54:42 and showing syntax errors/warnings before build 2017-06-05 10:55:07 so apps that uses llvm libs are: mesa, qt(-creator), clamav... ? 2017-06-05 10:55:10 https://txt.shiz.me/ZWZhZjNlMm 2017-06-05 10:55:17 this is from a quick apk search -r against the main llvm dynlib 2017-06-05 10:55:35 mesa already need llvm 2017-06-05 10:55:41 so it makes no diff 2017-06-05 10:55:51 im trying to figure out the maintenence impact 2017-06-05 10:56:03 if it means more maintenance work or not 2017-06-05 10:56:08 right 2017-06-05 10:56:15 i suppose the qt addition would mean more maintenance work 2017-06-05 10:56:24 the other packages already exist and already would need upgrading when we bump llvm 2017-06-05 10:56:26 no? 2017-06-05 10:56:33 yes, exactly 2017-06-05 10:56:37 so that makes not 2017-06-05 10:56:40 make no diff 2017-06-05 10:56:53 and clamav 2017-06-05 10:57:54 my impression is that it does not add too much maintenance work 2017-06-05 10:58:04 likewise 2017-06-05 10:58:39 at least, not in comparison to the regular maintenace work you'd have when you want to update your sys compiler 2017-06-05 10:58:41 :P 2017-06-05 10:58:49 yes 2017-06-05 10:59:14 ncopa, Shiz, kaniini: #7386 2017-06-05 10:59:21 skarnet: thanks! 2017-06-05 10:59:25 danke 2017-06-05 10:59:47 skarnet: thats nasty 2017-06-05 11:00:11 yes it is. That's why I'm inquiring about it, because it's not looking good at all 2017-06-05 11:00:48 Shiz: do you know how -Os compare? 2017-06-05 11:00:53 gcc and clang/llvm 2017-06-05 11:01:11 will size be bigger, smaller or approx the same 2017-06-05 11:01:35 i can compare the packages i've cross-compiled 2017-06-05 11:02:14 would also be interesting to know if there are any significant performance diff with -Os 2017-06-05 11:02:31 oh, libomp. you need that for OpenMP support in LLVM, whereas some gccs have it built in if you configure them that way 2017-06-05 11:02:37 not sure if that makes any difference 2017-06-05 11:03:57 i think we split it up into libgomp 2017-06-05 11:04:01 but yes, good point 2017-06-05 11:04:12 <^7heo> is llvm smaller than gcc? 2017-06-05 11:04:21 i think no 2017-06-05 11:04:31 <^7heo> I mean the source 2017-06-05 11:04:48 i dont think it is 2017-06-05 11:05:21 llvm's download sizes are misleading because they include a huge test suite btw 2017-06-05 11:08:21 Shiz: do you think we should switch now for some architectures? 2017-06-05 11:08:31 or wait til after 3.7 release 2017-06-05 11:08:54 oh 2017-06-05 11:08:59 one more question 2017-06-05 11:09:01 support time 2017-06-05 11:09:11 how long time can we expect upstream support? 2017-06-05 11:10:59 good question, i'll investigate the support 2017-06-05 11:11:12 in my experience, they have been very quick about responding to bug reports at least :) 2017-06-05 11:11:26 see e.g. http://bugs.llvm.org/show_bug.cgi?id=33243 (lld issue) 2017-06-05 11:12:07 as far as switching goes... I'd like to do some more testing, and do a full aports build 2017-06-05 11:12:26 i think given the time we'd want to spend testing it to make sure it works alright, i think it'd be wise to leave it to 3.8 2017-06-05 11:12:27 skarnet: mmm, not seeing anything about misaligned/unaligned returns in gcc6 or 7 or even head. this could be binutils issue! but I sleep now instead of looking at binutils bz. 2017-06-05 11:12:52 this may change if things go unexpectedly well of course 2017-06-05 11:13:06 awilfox: good idea! thanks for having a look anyway - did you reproduce the bug? 2017-06-05 11:13:43 Shiz: libunwind doesn't build with lld and needs binutils bfd/gold, just fyi, but I believe upstream is working on a fix. not sure how that is going. heard about that from FreeBSD colleague. 2017-06-05 11:13:54 awilfox: right 2017-06-05 11:15:55 Shiz: ok, very well 2017-06-05 11:16:27 skarnet: still waiting for it to upgrade to 3.6. was on 3.5.2. 2017-06-05 11:16:29 which leaves me with my question to you 2017-06-05 11:16:32 is there any infra i could use for that? :P 2017-06-05 11:16:45 Shiz: yes! any computer you have in your house :D 2017-06-05 11:16:51 well 2017-06-05 11:16:54 anything that doesn't take agse 2017-06-05 11:16:56 :P 2017-06-05 11:17:00 my desktop is an amd athlon 64 x2 6000+ 2017-06-05 11:17:20 a shame that I never got the builder that I was expecting 2017-06-05 11:17:31 I care about clang+musl enough that I'd just give you a slice on it 2017-06-05 11:17:46 (was going to be 64gb ram 2x8-core xeon with raid ssd) 2017-06-05 11:18:05 what happened to them? 2017-06-05 11:18:09 no idea \o/ 2017-06-05 11:18:19 so I just continue using my desktop for builder 2017-06-05 11:18:35 which is 24gb single 8-core xeon with 2x500gb spinning rust 2017-06-05 11:19:21 Shiz: that was one of my questions. what do you need? 2017-06-05 11:19:54 maybe we should take that in private 2017-06-05 11:19:58 sure :) 2017-06-05 11:20:02 or in -infra 2017-06-05 11:20:18 don't keep your hardware porn to yourselves 2017-06-05 11:20:37 ok, rebooting into 3.6 2017-06-05 11:20:57 HEY! it mounted root! 2017-06-05 11:21:04 that's better than I got 3.4 -> 3.5 2017-06-05 11:21:06 ;) 2017-06-05 11:21:09 XD 2017-06-05 11:22:26 ha 2017-06-05 11:23:29 skarnet: 2017-06-05 11:23:33 # rm -rf compiled 2017-06-05 11:23:39 rm: compiled: No such file or directory 2017-06-05 11:23:40 ncopa: btw, it may be worth seeing if we can merge my tree before 3.7 though 2017-06-05 11:23:44 # s6-rc-compile compiled main 2017-06-05 11:23:50 s6-rc-compile: fatal: unable to mkdir compiled/servicedirs/s6rc-oneshot-runner: File exists 2017-06-05 11:23:53 because as it is right now, it won't change anything to the defaults 2017-06-05 11:23:53 # rm -rf compiled 2017-06-05 11:23:56 rm: compiled: No such file or directory 2017-06-05 11:23:59 and it will setup infra for allowing diff toolchains 2017-06-05 11:24:01 # s6-rc-compile compiled main 2017-06-05 11:24:08 s6-rc-compile: fatal: out of memory 2017-06-05 11:24:10 # 2017-06-05 11:24:10 (and fixes some packages for cross-compiling) 2017-06-05 11:24:13 skarnet: ^ 2017-06-05 11:24:24 awilfox: yeah, the oneshot-runner error is also a possible outcome 2017-06-05 11:24:34 it's a memory corruption too 2017-06-05 11:24:35 skarnet: do I win anything for getting "fatal: out of memory"? 2017-06-05 11:24:42 the oom is a new one 2017-06-05 11:24:58 it only has 384 MB 2017-06-05 11:25:03 that could be the busyloop 2017-06-05 11:25:12 it could be leaking while busylooping, and just everyone has huge VMs 2017-06-05 11:25:19 you win the right to update #7386 with funny new outcomes! 2017-06-05 11:25:47 it's a possibility, I never let them busyloop for long, but I doubt it 2017-06-05 11:26:02 because strace showed it was busylooping in a place that doesn't allocate memory 2017-06-05 11:26:35 busyloops are 0 syscalls 2017-06-05 11:26:47 like label: jmp label 2017-06-05 11:28:04 (btw, your rm is weird if -f doesn't remove the warnings/errors on ENOENT) 2017-06-05 11:28:14 no debugging symbols found 2017-06-05 11:28:24 got a segfault with a coredump 2017-06-05 11:29:02 I'm afraid you'll have to repackage it if you want -g :P 2017-06-05 11:29:16 but again, I swear the user code is good 2017-06-05 11:29:30 I was terrified it wouldn't be, so I quadruple checked everywhere 2017-06-05 11:29:38 only the .apk is failing 2017-06-05 11:36:14 curious... 2017-06-05 11:36:43 ipxe fails to build on clang too 2017-06-05 11:36:52 ignore the reason I found that out >_> 2017-06-05 11:42:21 skarnet: http://bugs.alpinelinux.org/issues/7386 2017-06-05 11:42:33 skarnet: also, that reg date: http://bugs.alpinelinux.org/users/107 2017-06-05 11:42:43 does that make me officially user #107? XD 2017-06-05 11:45:48 awilfox: thanks a lot! was it with a vanilla kernel? 2017-06-05 11:46:49 because a grsec kernel also gives SIGILL and busyloops. And all the symptoms you get point to a memory corruption in the application code, but I've been unable to reproduce it on other machines. 2017-06-05 11:47:00 skarnet: nope, hardened 2017-06-05 11:47:06 skarnet: don't have alpine vanilla installed anywhere. 2017-06-05 11:48:37 weird. Anyway, thanks, and go to sleep 2017-06-05 11:55:19 skarnet: you write bloated software! 2017-06-05 11:56:12 skarnet: http://i.imgur.com/oZegkTl.png even systemd doesn't use so much! XD 2017-06-05 11:56:58 zomg 2017-06-05 11:57:20 it's offline! Offline resources don't count! XD 2017-06-05 11:57:26 lol 2017-06-05 11:57:54 anyway, that is duplicated with adelie libs but alpine s6-rc-compile binary. 2017-06-05 11:58:02 I just scp'd the /bin to my ~ 2017-06-05 11:58:31 want a working static binary for proof it's not the user code? 2017-06-05 12:00:29 skarnet: if it helps: http://foxkit.us/linux/results.txz 2017-06-05 12:00:39 skarnet: strace for each failure mode I hit. lots of mremap in the memory leak one. 2017-06-05 12:00:43 not sure if you ever call mremap. 2017-06-05 12:00:57 that's probably realloc 2017-06-05 12:01:10 thanks a lot. but... 403 atm :) 2017-06-05 12:01:27 doh silly umask 2017-06-05 12:01:29 fixed 2017-06-05 12:02:15 you have my permission (barring any personal data in there which I don't think strace has.) to upload that to the bug reporting that is what I got on adelie with the same s6-rc-compile binary 2017-06-05 12:02:18 too tired, already up late 2017-06-05 12:02:26 hope that strace is revealing, or at least helps pin down the cause. 2017-06-05 12:03:12 thanks 2017-06-05 12:03:33 np! =>bed 2017-06-05 12:05:21 ncopa: setup-xorg-base should also add grsec_sysfs_restrict=0 to update-extlinux.conf probably 2017-06-05 12:05:23 agree? 2017-06-05 12:08:51 yeah, makes sense 2017-06-05 12:12:07 Shiz: and i agree that it might make sense to add support for switching toolchain before v3.7, even if we stick to gcc for now 2017-06-05 12:21:34 ncopa: from the packages i compiled and measured, 160 of them 2017-06-05 12:21:53 the combined .apks take ~94.3% of the size of the gcc-compiled ones 2017-06-05 12:22:05 the one standout being musl, being bigger -- need to investigate 2017-06-05 12:23:10 interesting 2017-06-05 12:23:13 re musl 2017-06-05 12:23:17 and for clang, -Os is apparently the same as -O2 2017-06-05 12:23:31 i have been thinking of compiling musl as -O2 2017-06-05 12:23:32 oh 2017-06-05 12:23:33 :) 2017-06-05 12:23:44 :P 2017-06-05 12:23:52 lol 2017-06-05 12:25:41 https://github.com/llvm-mirror/clang/blob/6235d9b1ad493fbbd905e46b2b6afab52eeeb2cb/lib/Frontend/CompilerInvocation.cpp#L97 2017-06-05 12:25:42 source for that 2017-06-05 12:26:08 ah, there's a separate size optimisation level that -Os determines 2017-06-05 12:27:12 apparently -Oz is a more extreme version of -Os 2017-06-05 12:27:14 huh 2017-06-05 12:38:50 i think im gonna make a poll on twitter: which default toolchain do youthink #alpinelinux should use: 2017-06-05 12:38:54 - gcc 2017-06-05 12:39:00 - llvm/clang 2017-06-05 12:39:52 or: "which system C compiler do you think #alpinelinux should use?" 2017-06-05 12:42:51 are twitter polls the best way to decide this? :P 2017-06-05 12:43:39 no. twitter is only to give the impression that its a democracy :) 2017-06-05 12:46:48 :) 2017-06-05 12:50:47 actually making a poll without pros/cons of both will make it difficult to chose 2017-06-05 12:52:10 mm, as a result we will be even more confused by all those hurr durrs and herp derps 2017-06-05 12:58:24 gcc is more compatible, but on the other hand alpine linux already makes plenty of incompatible decisions 2017-06-05 12:58:36 (more compatible with existing code, that is) 2017-06-05 13:25:47 https://github.com/singularityware/singularity/issues/722 GLOB_TILDE issue, what would you advise to get that build on alpine? 2017-06-05 13:31:29 i'd implement a similar workaround as the i3 patch does 2017-06-05 13:40:47 so just taking care of "~/" -> "$HOME/" . I was not able to find if there was work in progress for more glob in the musl space. 2017-06-05 13:46:15 ncopa, if alpine goes out of GCC, then, we RMS can't call Alpine a GNU/Linux anymore 2017-06-05 13:46:24 s/we// 2017-06-05 13:50:17 lol 2017-06-05 13:50:23 he can still call it that 2017-06-05 13:50:29 he'd just be still as wrong in doing so as he was before 2017-06-05 13:51:37 there's a patch for GLOB_TILDE here http://www.openwall.com/lists/musl/2017/01/20/4 2017-06-05 13:51:42 tru_tru ^ 2017-06-05 13:51:47 but it's not upstream (yet?) 2017-06-05 13:53:52 Shiz: thx 2017-06-05 13:57:02 leitao: i have not considered Alpine a GNU/Linux distro for a while 2017-06-05 13:57:16 i actually think I never considered Alpine GNU/Linux 2017-06-05 13:58:21 ncopa, I think not a single distro consider themselves a GNU/Linux distro. GNU considers it because they use GNU bits. 2017-06-05 13:58:26 which might not be true anymore for Alpine 2017-06-05 13:59:37 https://git.alpinelinux.org/cgit/aports/commit/?id=dcec1161e5c692bfca7fbb51dec3968c3c3dbf98 2017-06-05 14:00:16 anyways.. i suppose we have more interesting things to work on than GNU/Linux naming issues :) 2017-06-05 14:01:17 https://twitter.com/n_copa/status/871728572318220288 2017-06-05 14:31:41 nice! 2017-06-05 14:47:32 ncopa: i like clang because they are making CFI which is like grsecurity RAP 2017-06-05 14:47:47 ncopa: but the ABI isn't stable yet 2017-06-05 15:05:06 are there any plans to make the ABI stable? 2017-06-05 15:18:05 only cross-DSO abi is unstable 2017-06-05 15:18:26 but the entirety of cross-DSO is experimental at this point 2017-06-05 15:18:28 :) 2017-06-05 16:47:33 speaking of llvm, https://www.phoronix.com/scan.php?page=news_item&px=Gollvm-Go-LLVM 2017-06-05 16:47:35 :p 2017-06-05 16:56:55 gollvm gollvm, my preciovssssssss 2017-06-05 17:53:42 ncopa: fcolista: re:fortran 2017-06-05 17:53:44 https://www.phoronix.com/scan.php?page=news_item&px=LLVM-NVIDIA-Fortran-Flang 2017-06-05 17:53:47 :P 2017-06-05 17:55:04 hi, sorry to interrupt, was there any discussion of adding secfixes to APKBUILD, 2017-06-05 17:55:08 eg, https://git.alpinelinux.org/cgit/aports/commit/?id=10d80c4a6dd266d82f42c9714fdef16c04b3a859 2017-06-05 17:56:01 just wondering if secfix[es].yaml would be a better idea, making it easy parse for db/analytics 2017-06-05 17:56:55 vkrishn, you mean a separate file? 2017-06-05 17:57:11 rather than inside the APKBUILD? 2017-06-05 17:57:16 yes 2017-06-05 17:58:12 so each can have its own file, eg. /main/mosquitto/secfix[ex].yaml 2017-06-05 17:59:31 well...the plan is having abuild parsing the APKBUILD also for the security/yaml section 2017-06-05 17:59:38 though one can extract the info if structured, but would be much easier if its json (using jq) or yaml (tool yet to be made) 2017-06-05 18:00:21 yes, the tool can look into the same directory for that file if present 2017-06-05 18:01:16 seperate file would help in making a analytic db for whole aports and do some analysis if required 2017-06-05 18:02:05 jirutka: why did you tell me that instead of telling the author? 2017-06-05 18:02:08 :P 2017-06-05 18:02:09 re:latest scala pr comment 2017-06-05 18:02:23 from my perspective, having a different file would be useful for external tools..but at the same time would add complexity in the abuild and duplicate the number of files 2017-06-05 18:02:39 I don't have strong opinions on that , though 2017-06-05 18:02:57 i have no opinion on that either way 2017-06-05 18:08:02 or maybe a generic NOTES.yaml 2017-06-05 18:08:54 no NOTES.yaml is too generic 2017-06-05 18:09:03 we need to know for sure about secfixes 2017-06-05 18:09:12 in the APKBUILD or either an external file 2017-06-05 18:09:18 but don't mess other info inside 2017-06-05 18:09:35 it can carry any notes, like special care for one perticular ARCH 2017-06-05 18:09:37 (imho ofc) 2017-06-05 18:10:08 but this is not related only to secfixes 2017-06-05 18:10:19 notes are notes, secfixes are secfixes 2017-06-05 18:10:51 notes , more like bunch of categorized notes 2017-06-05 18:10:55 if i want to parse the yaml file, i don't want to "grep -v" what i'm not interested to. 2017-06-05 18:11:28 but i think you're introducing another topic 2017-06-05 18:11:54 and i need to go to play football 2017-06-05 18:11:54 so there could be secfixes: ...... or ppc64le: 2017-06-05 18:12:15 ok, :) , thanks 2017-06-05 18:16:29 gtg, maybe ncopa, ^^^ notices it tomorrow 2017-06-05 18:18:04 hm, generis notes.yml with secfixes category should be enough 2017-06-05 18:18:09 like: 2017-06-05 18:18:15 secfixes: 2017-06-05 18:18:21 - cve1 2017-06-05 19:16:11 hi 2017-06-05 19:17:36 vkrishn : https://git.alpinelinux.org/cgit/alpine-secdb/ ? 2017-06-05 19:22:44 when someone adds a new aport to testing, how is the following process? how is this package moving to community so a user can apk add it? 2017-06-05 19:25:17 kernasi: someone needs to test that the package works, then make a PR of moving it to community 2017-06-05 19:25:55 the package also needs to have a proper init.d script if needed, and if needed, an install script that creates user 2017-06-05 19:26:32 ncopa, who is that one? someone from you alpine guys, I presume? 2017-06-05 19:26:51 make a normal PR 2017-06-05 19:27:14 someone with git push access will have to do it 2017-06-05 19:27:27 ah ok 2017-06-05 19:29:12 there is no automatic process so making a PR is good 2017-06-05 19:29:48 https://github.com/alpinelinux/aports/pull/1610 <-- I did that and I just wondered how this will get into community :) 2017-06-05 20:23:56 kernasi: send new PR 2017-06-05 20:24:02 yup 2017-06-05 20:24:06 thanks ncopa 2017-06-05 20:24:07 make sure that all deps also are in community 2017-06-05 20:27:07 !! 2017-06-05 20:27:11 almost have gnome 3 running 2017-06-05 20:27:17 :) 2017-06-05 20:28:30 guys, thanks for the good documentation and for your kind help; I'm out 2017-06-05 20:28:33 good night 2017-06-06 00:54:22 https://www.dropbox.com/s/128iwhyddv80zl8/Screenshot%202017-06-05%2019.54.03.png?dl=0 2017-06-06 00:59:16 thats a desktop 2017-06-06 01:01:50 that's gnome-shell running on alpine without EITHER systemd or logind 2017-06-06 01:02:10 (gnome-shell --replace) 2017-06-06 01:02:30 ncie 2017-06-06 01:03:03 it's a little unstable because it keeps trying to dlopen things that aren't there yet 2017-06-06 01:03:07 lols 2017-06-06 01:33:02 wew 2017-06-06 01:33:35 nice work 2017-06-06 05:11:49 http://i.imgur.com/c54VziD.png 2017-06-06 05:11:53 now its pretty stable 2017-06-06 06:36:29 kaniini: now flatpak and we will be even more cool 2017-06-06 06:36:54 fuck flatpak :) 2017-06-06 06:37:39 just kidding. jirutka suggested this some time ago :P 2017-06-06 06:38:23 question, what's the advantage of flatpak over, say, appimage? 2017-06-06 06:39:35 as I looked at both, combining those with something like firejail seemed like a good idea, and firejail has direct support for appimage 2017-06-06 06:41:59 firejail is a terrible idea 2017-06-06 06:42:08 i hope nobody has packaged it 2017-06-06 06:42:21 <_ikke_> https://pkgs.alpinelinux.org/packages?name=firejail&branch=&repo=&arch=&maintainer= 2017-06-06 06:42:36 welp 2017-06-06 06:42:39 they can enjoy their fake security 2017-06-06 06:42:42 lols 2017-06-06 06:44:22 can you elaborate on that a bit? 2017-06-06 06:45:17 do i really have to? 2017-06-06 06:45:29 just google "firejail CVE" and watch the fun 2017-06-06 06:49:39 kaniini: what would you suggest an an, erm, alternative? 2017-06-06 06:49:39 actually isolating your software in namespaces 2017-06-06 06:49:39 it is trying to secure arbitrary software 2017-06-06 06:49:39 by acting as a suid wrapper 2017-06-06 06:49:39 i mean, lets think about what firejail is trying to do here 2017-06-06 06:49:39 but seriously this is what LXC is for 2017-06-06 06:49:39 this is basically insane 2017-06-06 06:49:45 okay, so that pretty much trumps (bad choice of words, I know) that advantage. then there's bubblewrap and runc. 2017-06-06 06:49:46 how typical of IRC, lagged out when there was something interesting to talk about 2017-06-06 06:50:04 good old trustworthy 1990's tech :P 2017-06-06 06:50:06 i mean 2017-06-06 06:50:16 you should think about what firejail is trying to do, and how it allegedly does it 2017-06-06 06:50:19 and you will realize it's insane 2017-06-06 06:50:40 it is taking an suid binary, using that to contain an arbitrary binary to a user-specified security policy 2017-06-06 06:50:42 what could possibly go wrong 2017-06-06 06:50:56 but thinking through implications is hard 2017-06-06 06:51:04 don't know if my previous msg got through... so that trumps the (supposed) integration advantage of firejail; then there's bubblewrap and runc which do similar things 2017-06-06 06:51:39 the difference with the latter is that it's the application vendor, ideally, who is defining the security policy. 2017-06-06 06:51:58 which is, you know, more sane than giving some user a SUID binary and plenty of options for shooting themself in the foot 2017-06-06 06:51:59 bubblewrap at least seems to be in use by some container-centric environments 2017-06-06 06:52:20 firejail 2017-06-06 06:52:24 is not even about containers 2017-06-06 06:52:31 it's about containment 2017-06-06 06:52:37 which is a different concept altogether 2017-06-06 06:52:46 not entirely 2017-06-06 06:52:54 yeah, entirely 2017-06-06 06:53:04 firejail is not anything like runc or docker 2017-06-06 06:53:11 you can repeat that but it doesn't make it true 2017-06-06 06:53:47 really 2017-06-06 06:54:01 because runc and docker are frequently used to "protect" (ha ha) firefox and have a UI 2017-06-06 06:54:49 I don't see how restricting an application namespacewise would be a bad idea 2017-06-06 06:54:49 sure there is some vague similarity, but not really. goal of firejail is to apply seccomp policy (and some badly implemented namespacing) to a process already on your machine 2017-06-06 06:55:16 it's not if implemented correctly 2017-06-06 06:55:20 ah but it's not just seccomp 2017-06-06 06:56:00 anyway, like i say, use it if you really want to. but it isn't doing you any good whatsoever 2017-06-06 06:56:06 admittedly tho the second I saw seccomp even mentioned in firejail documentation I was like "okay, this is selinux all over again; who's going to write all the proper policies" 2017-06-06 06:57:24 I don't really want to; I'm in a phase with my work project where I'm evaluating the pros and cons of the alternatives for application isolation, and I appreciate you bringing up good points 2017-06-06 07:37:05 Hello guys,I am working on PyPy build and I have one question about cpython apk . Why is the depends variable empty ? Can it figure out the dependencies for run time by itself? 2017-06-06 07:40:34 <_ikke_> Or it does not have any run-time dependencies.. 2017-06-06 07:41:05 <_ikke_> though, the package db does mention dependencies 2017-06-06 07:43:27 but it has: bzip2, libfffi, sqlite, etc 2017-06-06 07:43:36 <_ikke_> right 2017-06-06 07:43:46 they are used both at compile time and runtime 2017-06-06 07:43:58 are they installed automatically? 2017-06-06 07:44:21 based on makedepends content? 2017-06-06 07:44:32 <_ikke_> makedepends are not installed at runtime 2017-06-06 07:44:45 then how does python work? :) 2017-06-06 07:45:47 <_ikke_> I guess throug so dependency tracking 2017-06-06 07:45:48 anyway, I am more curious about the fact if I need to explicitly add my runtime dependencies in my PR 2017-06-06 07:46:06 <_ikke_> apk info -R python 2017-06-06 07:47:08 oh, I see them. so it should be fine I think 2017-06-06 07:47:48 <_ikke_> during building the package, you see a phase where it's tracing the dependencies 2017-06-06 07:48:00 yes 2017-06-06 07:48:38 thank you for the info _ikke_ ! 2017-06-06 07:49:40 horrid: PyPy build will not be accepted upstream, we wish to deprecate python 2 2017-06-06 07:55:54 no? 2017-06-06 07:56:00 but why? 2017-06-06 07:56:42 not even pypy3? 2017-06-06 08:00:13 pypy3 is ok 2017-06-06 08:00:18 pypy 2 is not ok 2017-06-06 08:00:30 Shiz: http://i.imgur.com/qvrKHWu.png 2017-06-06 08:00:36 Shiz: systemd? who needs systemd? :) 2017-06-06 08:06:57 kaniini: ok then, I'll focus on PyPy3 then 2017-06-06 08:13:35 firejail is in community afaics 2017-06-06 08:13:55 yes 2017-06-06 08:13:55 well 2017-06-06 08:13:59 it should be removed 2017-06-06 08:25:46 are you also opposed to nsjail and minijail on a similar basis? 2017-06-06 08:42:54 see: https://github.com/google/nsjail and https://chromium.googlesource.com/chromiumos/platform/minijail/ 2017-06-06 08:51:50 hye...all you C coders: i've obs-studio which segfaults on start. 2017-06-06 08:51:58 I bet that is due to stack size 2017-06-06 08:52:13 https://dpaste.de/p5im 2017-06-06 08:52:28 how can I check in the source where is set the stack size? 2017-06-06 08:52:32 If not, i think is implicit 2017-06-06 08:52:39 so, how can I re-define it? 2017-06-06 08:53:16 https://github.com/jp9000/obs-studio/ 2017-06-06 08:55:51 brb 2017-06-06 09:55:45 fcolista: look in the source for pthread_create, and add a pthread_addr_setstacksize() call before it: http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_attr_setstacksize.html 2017-06-06 09:57:57 skarnet, this for each call to pthread_create ? 2017-06-06 09:58:55 yes 2017-06-06 09:59:16 okt this means pathc all of these: 2017-06-06 09:59:16 https://dpaste.de/XFZB/raw 2017-06-06 09:59:40 (not the deps/* files or test/* or cmake/*) 2017-06-06 10:00:47 write a small wrapper that does the right calls, replace all real pthread_create calls with calls to your wrapper 2017-06-06 10:01:19 skarnet, is what we did for libmiliter f i'm not wrong 2017-06-06 10:01:19 https://dpaste.de/SZmZ/raw 2017-06-06 10:01:55 indeed 2017-06-06 10:02:53 ok..gotcha... 2017-06-06 10:03:00 thanks skarnet! 2017-06-06 10:03:07 yw :) 2017-06-06 10:03:41 <^7heo> skarnet: is there an advantage to doing that with a wrapper rather than a macro? 2017-06-06 10:04:22 a wrapper is more flexible, if it's multi-instruction it's cleaner, etc. 2017-06-06 10:04:31 <^7heo> yeah ok :) 2017-06-06 10:04:56 and if the code you add is several instructions long then the code may even be smaller :P 2017-06-06 10:05:20 <^7heo> you mean the code after CPP? 2017-06-06 10:05:40 fcolista: you may not need to wrap all the calls, if for instance there's one thread that needs a lot of memory and the other ones can fit into musl's default stack size then you only need to patch the call to the big thread 2017-06-06 10:05:42 i can definea macro for stacksize 2017-06-06 10:05:53 ^7heo: I mean the binary 2017-06-06 10:05:57 <^7heo> ok 2017-06-06 10:06:01 skarnet, I don't have competence to understand that 2017-06-06 10:06:05 <^7heo> skarnet: yeah makes sense 2017-06-06 10:06:11 <^7heo> skarnet: thanks;) 2017-06-06 10:06:20 yeah, it requires deep understanding of the application 2017-06-06 10:06:46 but bumping the stack size for everything will probably significantly increase memory consumption 2017-06-06 10:06:50 what I know is that the application segfaults when start 2017-06-06 10:07:07 yes i agree 2017-06-06 10:07:18 and also i don't know the size i should set a stacksize 2017-06-06 10:07:25 probably 8MB is correct 2017-06-06 10:07:30 8 MB is huge 2017-06-06 10:07:35 since it's the glibc standard 2017-06-06 10:07:39 yes is huge 2017-06-06 10:07:44 glibc is oversize for most things 2017-06-06 10:07:48 try increments of 256 kB 2017-06-06 10:07:57 so I can try-by-errors 2017-06-06 10:08:05 yeah 2017-06-06 10:08:10 80 + 256 ? 2017-06-06 10:08:23 <^7heo> < fcolista> I bet that is due to stack size 2017-06-06 10:08:27 256, 512, 768, 1024 2017-06-06 10:08:36 ah ok 2017-06-06 10:08:45 <^7heo> So you are going to increase the stack to try and see if it still SIGSEGV? 2017-06-06 10:09:14 ^7heo, yes 2017-06-06 10:09:15 Thread 7 "obs" received signal SIGSEGV, Segmentation fault. 2017-06-06 10:09:29 (gdb) bt 2017-06-06 10:09:29 #0 0x00006c376d994692 in ?? () 2017-06-06 10:09:29 Backtrace stopped: Cannot access memory at address 0x6c376e7c97d0 2017-06-06 10:09:34 this is the bt ^ 2017-06-06 10:09:35 yeah you can start with 8 MB to be sure - if the segfault disappears then that's what it was, and then you can dichotomize to find the right stack size 2017-06-06 10:09:39 <^7heo> fcolista: ok 2017-06-06 10:10:07 ^7heo, i can be wrong that is not due to stacksize...but actually it smells of it 2017-06-06 10:10:39 <^7heo> yeah 2017-06-06 10:10:42 skarnet, so let's say: 2017-06-06 10:11:06 #define STACK_SIZE number_that_i_can_change 2017-06-06 10:11:18 so 2017-06-06 10:11:21 256*1024 2017-06-06 10:11:27 and hten: 2017-06-06 10:11:37 pthread_attr_setstacksize(&attr,STACK_SIZE); 2017-06-06 10:12:12 just like the milter patch 2017-06-06 10:12:28 *if* all the calls to pthread_create pass NULL as attribute 2017-06-06 10:12:40 if they're already using attributes, it's a bit more complex 2017-06-06 10:12:46 <^7heo> fcolista: what if increasing the stack has a side effect that mitigates the segfault? 2017-06-06 10:13:09 ^7heo: that's exactly the point :D 2017-06-06 10:13:22 and that wouldn't be a side effect, that would be the main effect 2017-06-06 10:13:35 <^7heo> skarnet: ok :) 2017-06-06 10:13:55 <^7heo> I really meant a side effect tho. 2017-06-06 10:14:28 it takes some serious imagination to find a case where increasing the stack size does something else than run the thread with a bigger stack 2017-06-06 10:14:41 <^7heo> yeah 2017-06-06 10:14:43 <^7heo> I was trying but... 2017-06-06 10:15:15 <^7heo> at the same time, gcc does a lot of black magic AFAIK (but I have never checked for myself) 2017-06-06 10:15:50 <^7heo> Anyway, I do not know enough about the internals of gcc to come up with a valid point where increasing the stack has side effects. 2017-06-06 10:18:17 ^7heo: there is one I can think of 2017-06-06 10:18:51 ^7heo: if the compiler does not inline a highly recursive method marked 'inline', then it could run out of stack space due to the function entrance stanza (on x86_64 anyway) 2017-06-06 10:19:10 ^7heo: but that would require either a broken heurustic or -fno-inline 2017-06-06 10:19:19 and would likely be a legitimate compiler bug 2017-06-06 10:19:25 if not caused by -fno-inline that is 2017-06-06 10:20:58 <^7heo> yeah 2017-06-06 10:21:23 <^7heo> Well, again, that requires quite some insider knowledge about gcc; and I don't have that. But kudos for finding it ;) 2017-06-06 10:24:44 lxGzx53qO34r: thanks for the tip on those two alternatives to firejail 2017-06-06 10:25:16 ^7heo: more appropriately, it requires knowledge of the C ABI for x86_64 (clang would do the same too, if it failed to inline a highly-recursed function marked inline) 2017-06-06 10:25:33 blargh, adelielinux.org keeps flapping on v6 (but is stable on v4) 2017-06-06 10:25:37 er wait 2017-06-06 10:25:39 wrong channel 2017-06-06 10:26:53 <^7heo> huhu 2017-06-06 10:26:57 <^7heo> yeah. 2017-06-06 10:27:06 <^7heo> About the C ABI, what's what I meant; yes. 2017-06-06 10:44:18 good morning 2017-06-06 11:49:20 <^7heo> moin leo-unglaub 2017-06-06 12:02:18 <^7heo> is it me or readline on 3.6 isn't in the same version as readline-dev? 2017-06-06 14:32:45 Is there a way to tell apk "add this package from edge, using the repository tagged as @edge in my /etc/apk/repositories" ? 2017-06-06 14:33:06 <_ikke_> skarnet: apk add pkg@edge? 2017-06-06 14:33:06 like --update-cache --repository blahblah but without having to spell blahblah out 2017-06-06 14:33:15 ah, will try, thanks 2017-06-06 14:34:06 <_ikke_> That's the whole reason you tag (pin) them in the first place 2017-06-06 14:34:22 <_ikke_> https://wiki.alpinelinux.org/wiki/Alpine_Linux_package_management#Repository_pinning 2017-06-06 14:35:20 indeed, but to be frank the wiki organization is a mess, even if there's lots of stuff in there - and I'm never sure what's up-to-date and what isn't 2017-06-06 14:35:27 but it works, thanks :) 2017-06-06 16:00:29 Hi everyone! I did a PR to include telnetd in busybox a while ago, which I was then asked to change to a busybox-extras package, and to move all the insecure protocols in there. I also did that - but I didn't get any feedback from you guys. Could someone review the workflow with busybox-extras and tell me if you would merge it, if I rebased it? Thank you! https://github.com/alpinelinux/aports/pull/1092 2017-06-06 16:44:51 ollieparanoid[m]: hi. thanks for working on it. will have a look 2017-06-06 16:45:57 ollieparanoid[m]: would it be possible to have a /bin/busybox-extras binary? 2017-06-06 16:46:04 and symlink the applets to this? 2017-06-06 16:46:58 and the config would only include the applets thats not included in the /bin/busybox 2017-06-06 16:47:44 the idea is that you would only need `apk del busybox-extras` to uninstall it 2017-06-06 16:48:10 that's a lot of code duplication though :P 2017-06-06 16:48:37 busybox is small thanks to its tightly integrated library, if you split it you'll mostly duplicate the library into 2 binaries 2017-06-06 16:49:46 that's a minor inconvenience compared to the maintenance benefits of putting insecure stuff in a separate binary, but since you're obsessed with disk size, that's something to keep in mind :) 2017-06-06 16:50:01 yes it would be code duplication 2017-06-06 16:50:07 i wonder how much though 2017-06-06 16:50:49 a busybox binary with only the "mdev" applet selected is more than 150kB or so 2017-06-06 16:51:25 the thinking is that for majority it will reduce size, and those who whats the network servers, telnet, httpd etc, will get a penalty 2017-06-06 16:51:48 which hopefully still will be smaller than installing separate ftpd, telnet, httpd 2017-06-06 16:52:00 there's no busybox httpd in the default? 2017-06-06 16:52:30 it currently is 2017-06-06 16:52:45 what i want avoid is: https://github.com/ollieparanoid/aports/blob/4dfcdd03bdd0fb7bc275c0589e2884b1110579e2/main/busybox/busybox-extras.post-install 2017-06-06 16:53:09 yeah 2017-06-06 16:53:14 so my question is, how much is the overhead? 2017-06-06 16:53:18 to fix it 2017-06-06 16:53:33 is it possible? might be busybox doesn ot support alternative suffixes 2017-06-06 16:53:53 I'm the wrong interlocutor for this because I'd package busybox-extras as a separate binary without even wondering 2017-06-06 16:54:01 you're the one who cares about disk space :P 2017-06-06 16:54:17 :) 2017-06-06 16:54:38 thanks for pointing it out. i am aware of it 2017-06-06 16:54:55 and i wonder how big the extra duplication is 2017-06-06 16:55:12 well it can't be bigger than a busybox binary 2017-06-06 16:55:31 AL being small is one of its virtues, so it's good that ncopa cares 2017-06-06 16:56:07 yeah yeah, I know the drill 2017-06-06 16:56:13 skarnet: and if mdev alone is 150k, then I'd guess it would end up as 200-300k 2017-06-06 16:56:23 but thats a wild guess 2017-06-06 16:56:29 probably around that figure, yes 2017-06-06 16:57:56 ideally everything present in normal bb should be removed from bb-extras, to avoid duplication. haven't stripped bb that much ever, but theoretically it should be possible, at least to some extent (some common code will surely get in anyway) 2017-06-06 16:58:17 that's the point, you can remove applets, but the lib will be duplicated 2017-06-06 16:58:24 at least large parts of it 2017-06-06 17:06:39 Would anyone by any chance be familiar with the "buildout" Python build system? jirutka for instance? 2017-06-06 17:13:24 <^7heo> not me, sorry. 2017-06-06 17:13:26 <^7heo> never tried it. 2017-06-06 17:24:52 reverse debugging with gdb fails: ./nat/x86-linux-dregs.c:146: internal-error: void x86_linux_update_debug_registers(lwp_info*): Assertion `lwp_is_stopped (lwp)' failed. 2017-06-06 17:25:19 does anybody now if that ever worked on alpine/musl? 2017-06-06 17:25:51 knows 2017-06-06 17:50:05 oh, nice its only broken with multi-threading, so I have to get rid of the thread to debug this... 2017-06-06 18:07:52 Shiz: do you think this is ok to merge? https://github.com/alpinelinux/aports/pull/1574 2017-06-06 19:04:00 evening 2017-06-06 19:20:33 <^7heo> ncopa: does alpine offer official install CDs? 2017-06-06 19:20:48 no 2017-06-06 19:20:57 you mean like selling cdroms? 2017-06-06 19:21:11 <^7heo> yes 2017-06-06 19:21:17 no, we dont 2017-06-06 19:21:30 there are isos and CDs are easy to burn. 2017-06-06 19:22:15 <^7heo> skarnet: it's a different channel. 2017-06-06 19:22:41 <^7heo> skarnet: my connection isn't really as secure as a CDROM 2017-06-06 19:23:02 ^7heo: your gpg is not secure either? 2017-06-06 19:23:15 <^7heo> well, I have not asked ncopa for his key last time we met. 2017-06-06 19:23:17 <^7heo> so... 2017-06-06 19:23:29 <^7heo> I kinda sucked about that, retrospectively. 2017-06-06 19:23:37 :) 2017-06-06 19:24:24 <^7heo> plus, CD-ROMs are really cheap; with a wide-availability... 2017-06-06 19:24:45 <^7heo> and it's possible to sign the whole content while burning the public key on it too. 2017-06-06 19:24:52 ACTION doesn't have a cd drive anymore 2017-06-06 19:24:55 because snail mail obviously can't be mitmed! 2017-06-06 19:25:09 <^7heo> skarnet: well I'd obviously go get it. 2017-06-06 19:25:26 <^7heo> (and get the keys verified at the same time) 2017-06-06 19:25:49 I wanted to try out arcaOS (the new os/2 distribution) and they asked me to burn the image onto a dvd...I had to get out of my apartment and buy dvds :P 2017-06-06 19:26:11 <^7heo> look, I understand your point about things not being miraculous solutions; I'm just saying that we can't really rely on HTTPs, so obviously we need other solutions. 2017-06-06 19:26:49 <^7heo> kernasi: also, I have a CD drive but... I removed it to store more hard drives ;) 2017-06-06 19:26:54 heh 2017-06-06 19:27:00 <^7heo> (still in my storage tho) 2017-06-06 19:27:14 I have a usb drive to be honest 2017-06-06 19:27:18 usb dvd driver 2017-06-06 19:27:19 -r 2017-06-06 19:27:21 ^7heo: so the only secure way to obtain Alpine image is changing a key with ncopa in person? XD 2017-06-06 19:27:30 <^7heo> anyhow, I was searching for ROM/WORM usb keys 2017-06-06 19:27:39 ncopa: yo, do you have a while? :> 2017-06-06 19:27:40 <^7heo> when I realized that CDROMs do exactly that, for very cheap. 2017-06-06 19:27:53 scadu hi 2017-06-06 19:27:57 <^7heo> scadu: depends on your definition of secure, I presume. 2017-06-06 19:28:37 kaniini: nice work with gnome 2017-06-06 19:29:17 ncopa: where and when it would be possible to share keys with you? I wonder of the other ways 2017-06-06 19:29:23 ofc. it's the best to do in person, but well 2017-06-06 19:30:37 <^7heo> scadu: we were discussing about doing an alconf in prague 2017-06-06 19:30:41 <^7heo> I'd love to do that. 2017-06-06 19:30:57 ncopa: it's coming along yes 2017-06-06 19:31:04 <^7heo> And we could exchange keys there obviously. 2017-06-06 19:31:07 ;3 2017-06-06 19:31:28 it could be an event 2017-06-06 19:32:35 i'll likely be at dockercon copenhagen 2017-06-06 19:36:27 <^7heo> yeah but not many of us will. 2017-06-06 19:36:39 <^7heo> I'd really like to do something in Prague in Sept/Oct personally 2017-06-06 19:36:45 ncopa: c'mon, we will buy you a bear 2017-06-06 19:36:48 ncopa: czech beer! 2017-06-06 19:36:57 a bear? oh that sounds dangerous :) 2017-06-06 19:36:58 <^7heo> So it's not immediately before/after the fosdem. 2017-06-06 19:37:12 kernasi: I corrected this in second sentence :P 2017-06-06 19:37:13 <^7heo> kernasi: depends, there are small cudly ones. 2017-06-06 19:37:21 :) 2017-06-06 19:38:44 ^7heo: huh, what happened to all good bear fighting? :c 2017-06-06 19:38:59 ACTION runs to -offtopic planet 2017-06-06 23:05:18 looks like nfs-utils is broken in edge. https://git.alpinelinux.org/cgit/aports/commit/main/nfs-utils?id=0539ae2c06949e1f06e94e9935ae4ad29ddcbe65 changes from /usr/sbin/rpc.statd to /sbin/rpc.statd. Or am I missing something ? 2017-06-07 06:30:38 tmh1999, looks like you are right 2017-06-07 06:32:27 nmeum, its your commit right? 2017-06-07 07:29:29 hi wb clandmeter 2017-06-07 07:29:39 hi 2017-06-07 07:29:41 good morning 2017-06-07 07:29:58 back to regular life :) 2017-06-07 07:30:01 ohayo 2017-06-07 07:31:48 i should work harder to loose all that extra weight causes be excessive pasta/pizza usage :) 2017-06-07 07:32:02 :) 2017-06-07 07:43:45 *lose 2017-06-07 07:52:09 <^7heo> moin 2017-06-07 07:53:04 <^7heo> clandmeter: working harder in IT does not cause losing weight... 2017-06-07 07:53:19 <^7heo> that's one of the main issues 2017-06-07 07:53:51 i know 2017-06-07 07:54:22 <^7heo> I bet you know, you have more ancienty than us 2017-06-07 07:54:31 i ordered a mi band 2 to remind me of that... 2017-06-07 07:55:05 clandmeter: yes, but I send it to patchwork for additional review instead of committing it directly mysefl 2017-06-07 07:55:12 anyway, will fix it right away 2017-06-07 07:55:30 nmeum, i think i fixed it. 2017-06-07 07:57:20 I would have updated the path in the OpenRC service instead but your fix works as well. thanks 2017-06-07 07:58:28 Finally, pi is up and running. 2017-06-07 07:58:30 \o/ 2017-06-07 07:59:04 nmeum, i compared it to gentoo and debian. 2017-06-07 07:59:13 they both have it in /sbin 2017-06-07 08:04:19 ok then 2017-06-07 08:06:14 i guess i is related with root on nfs? not sure though, couldn't really find much references to it so i just copied behavior from them. 2017-06-07 13:07:29 clandmeter: kaniini: ncopa: I’ve upgraded from latest 3.5.x to 3.6.1 and system does not boot, boot menu counts 3…2…1… over and over >_< using virtgrsec (virthardened)… what the heck?! 2017-06-07 13:08:17 probably due to the virtgrsec -> virthardened kernel rename? 2017-06-07 13:08:22 what booloader do you use? 2017-06-07 13:08:49 yes, still vmlinuz-virtgrsec here >_< 2017-06-07 13:09:08 I thought that kaniini tested that! 2017-06-07 13:17:37 hm, that’s weird, apk info | grep syslinux >> 1 2017-06-07 13:18:19 that’s why update-extlinux.conf was not updated 2017-06-07 13:18:34 but why is syslinux not installed here? 2017-06-07 13:20:31 not sure if it’s only my local problem or bug in some setup script 2017-06-07 13:26:17 ncopa: I deleted and cloned my aports tree again. New version of the patch sent to alpine-aports. Something went wrong somewhere, and I don't like it - but this patch should clean everything up. 2017-06-07 15:06:01 ncopa, any plans for blogs.[al] or planet.[al] ? 2017-06-07 15:06:17 similar to http://planet.debian.org/ 2017-06-07 16:41:18 jirutka: i did test the transition. not sure why your bootloader is screwed up :) 2017-06-07 17:37:18 <^7heo> does abuild use objdump -p | grep NEEDED to figure out what are the needed dependencies for a package? 2017-06-07 17:39:46 <_ikke_> ^7heo: https://git.alpinelinux.org/cgit/abuild/tree/abuild.in#n1073 2017-06-07 17:43:43 <_ikke_> it uses scanelf 2017-06-07 17:43:59 <_ikke_> https://git.alpinelinux.org/cgit/abuild/tree/abuild.in#n1218 2017-06-07 17:44:05 <^7heo> ok 2017-06-07 17:44:29 <_ikke_> https://git.alpinelinux.org/cgit/abuild/tree/abuild.in#n1259 2017-06-07 17:44:34 <_ikke_> those are the needed deps 2017-06-07 17:45:27 <^7heo> yeah cool 2017-06-07 17:45:53 <^7heo> scanelf is actually useful 2017-06-07 17:45:56 <^7heo> I didn't think about it. 2017-06-07 17:46:04 <^7heo> Thanks! 2017-06-07 17:46:29 <_ikke_> Was curious, so looked in the source 2017-06-07 17:47:14 <^7heo> yeah, I couldn't find what function added the right so's until you pointed scan_shared_objects() 2017-06-07 17:47:44 <_ikke_> I only found it after I searched for "so:" 2017-06-07 17:48:04 <_ikke_> which pointed to .needs-so 2017-06-07 17:48:08 <^7heo> yeah 2017-06-07 17:48:49 <^7heo> right 2017-06-07 17:48:55 <^7heo> I was searching in the wrong direction. 2017-06-07 17:49:08 <^7heo> after you passed the first function to me, I checked what it called 2017-06-07 17:49:13 <^7heo> not what was creating the data it used. 2017-06-07 17:50:22 <^7heo> Also scanelf --no-banner --recursive --needed is freaking cool 2017-06-07 18:05:39 ncopa: busybox-extras PR updated, it works like you suggested now: https://github.com/alpinelinux/aports/pull/1092 2017-06-07 18:06:26 <^7heo> ollieparanoid[m]: while you're here; could you please remove the GNU/ instead of Linux and ideally, add a precision explaining to people that there's both GNU and non-GNU software? 2017-06-07 18:06:32 <^7heo> (i.e in alpine) 2017-06-07 18:06:36 <^7heo> (but by default, non-GNU) 2017-06-07 18:06:46 <^7heo> s/intead/in front/ 2017-06-07 18:07:19 bah, i wouldnt bother spending time on that 2017-06-07 18:07:48 ollieparanoid[m]: do you know the size of the busybox-extras binary? 2017-06-07 18:07:50 <^7heo> right, let's ignore problems; it's gonna be better. 2017-06-07 18:08:02 <^7heo> Speaking of which, I'll let gogs like it is then. 2017-06-07 18:08:12 ncopa: it was about...70-90kb, I can look it up 2017-06-07 18:08:14 <^7heo> I don't see why I should maintain it since gitea is there. 2017-06-07 18:08:24 ollieparanoid[m]: that was smaller than expected 2017-06-07 18:09:14 ^7heo: I think we can work this out, I'll reply in detail later 2017-06-07 18:09:33 ncopa: yeah, I also thought it would be bigger :) 2017-06-07 18:09:34 <^7heo> ollieparanoid[m]: thanks. 2017-06-07 18:09:38 where is the GNU? 2017-06-07 18:09:45 in the busybox-extreas? 2017-06-07 18:09:47 <^7heo> On ollieparanoid[m]'s website. 2017-06-07 18:09:59 oh.. i thought you were commenting his patch 2017-06-07 18:10:16 i bett close my mouth on things i know nothing about 2017-06-07 18:10:56 ncopa: he's talking about that post I think: https://ollieparanoid.github.io/post/postmarketOS/ 2017-06-07 18:11:12 <^7heo> yes I am. 2017-06-07 18:11:18 is this the right place to discuss the GNU thing? or should I join #alpine-offtopic? 2017-06-07 18:11:26 <^7heo> it's better on -offtopic 2017-06-07 18:11:28 <^7heo> IMHO 2017-06-07 18:13:15 ncopa: 73.2K on armhf. and a similar size on x86_64 (though I don't have a binary here right now), so it's really small :) 2017-06-07 18:13:57 i think the "overhead" is worth it compared to the apk del issue 2017-06-07 18:14:02 even for initramfs 2017-06-07 18:18:23 -rwxr-xr-x 1 ncopa ncopa 67120 Jun 7 18:15 pkg/busybox-extras/bin/busybox-extras 2017-06-07 18:18:28 67k 2017-06-07 18:19:06 -rwxr-xr-x 1 ncopa ncopa 800928 Jun 7 18:15 pkg/busybox/bin/busybox 2017-06-07 18:19:18 -rwxr-xr-x 1 root root 825504 May 23 16:46 /bin/busybox 2017-06-07 18:19:44 so 67-25k overhead 2017-06-07 18:22:12 ollieparanoid[m]: very nice 2017-06-07 18:23:36 ncopa: I think so too, it's a great solution :) 2017-06-07 18:23:52 thanks for merging! 2017-06-07 18:24:03 i wonder if we could move more applets there 2017-06-07 18:25:04 dnsd, inted? 2017-06-07 18:25:09 inetd* 2017-06-07 18:25:20 fakeidentd? 2017-06-07 18:27:48 hdparm? 2017-06-07 18:46:17 im moving inetd, fakeidentd and dnsd 2017-06-07 18:59:49 ncopa: please do not merge commits with invalid Author as "null " (e.g. https://git.alpinelinux.org/cgit/aports/commit/?id=ecce10225bfb48726286cbfbeb1b6acb34b9264e), then we don’t know who to blame/ask 2017-06-07 19:00:33 oh 2017-06-07 19:00:37 who was that? 2017-06-07 19:01:19 good question, you’ve merged it… ;) 2017-06-07 19:01:31 https://github.com/alpinelinux/aports/pull/1510 2017-06-07 19:01:39 user was logged in to github 2017-06-07 19:01:45 bah 2017-06-07 19:02:45 even when you create file using web interface, GH adds Author; I have no clue how he messed it that it’s null 2017-06-07 19:03:09 but not 100% sure, I’m not so crazy to create files in git via web interface :) 2017-06-07 19:03:50 what do i do with the remaining 100 PRs? 2017-06-07 19:03:52 reject them all? 2017-06-07 19:04:00 and since he admitted that he did all these changes manually (that’s totally crazy), not using abuild tool, I’d be very suspicious :/ 2017-06-07 19:04:06 dunno 2017-06-07 19:04:17 maybe we can fix it for him when merging 2017-06-07 19:04:28 um yes 2017-06-07 19:04:35 yes, thats the best idea 2017-06-07 19:04:50 but i wonder what he want to use as email 2017-06-07 19:05:03 sounds like he wants to be anonymous 2017-06-07 19:06:12 even anonymous have some mail address 2017-06-07 19:07:00 some projects require commits to be always PGP signed; IMO that’s too strict and also does not work with our workflow… but requiring at least valid name and email address is not so much imo 2017-06-07 19:07:43 agree 2017-06-07 19:07:52 i suppose i could add myself as author? 2017-06-07 19:08:08 but the will not algitbot be able to autoclose them :-( 2017-06-07 19:08:11 I’d rather ask him 2017-06-07 19:08:30 hm, yes 2017-06-07 19:08:59 omg these PRs from tmpfile makes are more a headache than useful 2017-06-07 19:09:29 they are relatively nice though 2017-06-07 19:09:46 i have 5 more in my queue 2017-06-07 19:09:57 or maybe 10 2017-06-07 19:10:06 since the damage is already done, maybe i just push those 2017-06-07 19:10:30 we should probably have algitbot autoreject or similar 2017-06-07 19:10:52 yeah 2017-06-07 19:11:12 Author: tmpfile 2017-06-07 19:11:16 hm… 2017-06-07 19:11:22 what should autoreject? 2017-06-07 19:11:28 GitHub PR closer? 2017-06-07 19:11:36 no, b/c that would not solve anything 2017-06-07 19:11:36 or CI? 2017-06-07 19:11:40 yeah, CI 2017-06-07 19:11:48 that should work 2017-06-07 19:12:26 ok if i push the ones i have in queue? 2017-06-07 19:12:31 could please someone look at community/bitcoin and community/namecoin? release tarball has been changed, don’t know why 2017-06-07 19:13:07 well, it’s up to you, when Author is null, the only one to blame when something went wrong is the Committer ;) 2017-06-07 19:15:24 im taking the blame 2017-06-07 19:15:50 i am tempted to do the rest of the 58 too 2017-06-07 19:15:59 just to get the PR queue reduced 2017-06-07 19:16:47 ok im done for today 2017-06-07 19:19:23 looks like it only was those 2 commits 2017-06-07 19:19:52 anyone able to help me recover my wiki.a.o account? 2017-06-07 19:20:02 password reset doesn't seem to work 2017-06-07 19:20:10 and either does my password 2017-06-07 19:21:09 tdtrask: i'll try find someone who can help you 2017-06-07 19:21:16 ncopa: thanks 2017-06-07 19:24:02 ncopa: btw https://github.com/jirutka/luapak now supports even Windows (oh man that was painful experience) and also bundling with LuaJIT (only on Linux and macOS) :) 2017-06-07 19:26:24 very nice 2017-06-07 19:43:02 hi 2017-06-07 20:01:52 <_ikke_> hai 2017-06-08 07:45:56 morning 2017-06-08 07:46:01 ncopa, around? 2017-06-08 08:13:47 hi 2017-06-08 08:16:01 clandmeter: im here 2017-06-08 11:21:19 Hello,does anyone know how to find the libpthread_version in the musl library ? 2017-06-08 12:40:53 horrid: hi, what is libpthread_version? 2017-06-08 12:41:11 is it a file, a function call, or something else? 2017-06-08 12:47:51 I want to build PyPy3 and it does a confstr(GNU_LIBPTHREAD_VERSION) call which generates an exception.For now I fixed this by hardcoding the result of this function with "NPTL" but I don`t feel this is the most elegant solution. 2017-06-08 12:49:27 ok, its a GNU define 2017-06-08 12:49:45 horrid: where is the source? 2017-06-08 12:50:53 i'd say the best way woudlbe to: #if defined(GNU_LIBPTRHEAD_VERSION) ... /* use gnu extensions */ #else /* use only things in posix */ #endif 2017-06-08 13:01:56 The problem is that rpython sees the GNU_LIBPTRHEAD_VERSION as defined . 2017-06-08 13:07:41 hardcoding it as NPTL should be fine, the test probably only is there to check for obsolete glibc versions with linuxthreads 2017-06-08 13:08:20 which won't happen with musl, so telling the software it's ok to use real posix semantics is fine. 2017-06-08 13:14:37 Thank you for the informations! 2017-06-08 15:27:21 ncopa: i have gnome3 running on real hardware now 2017-06-08 15:34:58 kaniini: gz 2017-06-08 15:35:23 good zob! 2017-06-08 15:48:50 <^7heo> kaniini: \o/ 2017-06-08 18:53:44 kaniini: \o/ 2017-06-08 21:41:00 ncopa: sorry, telnetd does not actually work, when connecting to it in busybox-extras. I thought I tested this, but it turns out, I had tested an old initramfs. Could you please merge the PR, that fixes this? https://github.com/alpinelinux/aports/pull/1632 2017-06-08 22:13:08 jirutka: thanks! 2017-06-09 04:08:27 Tor upgrade to 0.3.0.8: https://github.com/alpinelinux/aports/pull/1634 2017-06-09 05:03:32 say, I am compiling some code with gcc, and it fails on linking step, what is the flag can I pass to gcc to make it print all the steps (compiling, linking, etc.) I got it somewhere a while ago but couldn't find again :( 2017-06-09 05:04:21 gcc -v 2017-06-09 05:05:20 but seems like no verbose output for ld :( 2017-06-09 05:07:53 is -Wl,--verbose correct ? I applied but see no change. hum 2017-06-09 05:23:55 kaniini : you got a minute :) 2017-06-09 05:25:22 not for debugging gcc :D 2017-06-09 05:31:15 kaniini : :D I couldn't find the argument for gcc to spit out all of its steps, including ld. btw, good night over there :) 2017-06-09 07:19:52 kaniini, you managed to run gnome3 without systemd then? 2017-06-09 07:28:49 fcolista: yes 2017-06-09 07:29:00 pretty cool 2017-06-09 07:29:01 fcolista: gnome3 is also available on Void 2017-06-09 07:29:10 and they do not use systemd either 2017-06-09 07:29:18 scadu, thx..yes void is not systemd 2017-06-09 07:29:37 i didn't like gnome3 gui too much tbh 2017-06-09 07:29:51 but is noticeable to have it working without systemd 2017-06-09 07:30:19 well, I came back to i3, but it's nice to have ;f 2017-06-09 07:30:34 i3 ? 2017-06-09 07:30:49 https://i3wm.org/ 2017-06-09 07:30:51 ì ? 2017-06-09 07:30:54 ^ ? 2017-06-09 07:31:04 is there a metapkg or script to setup gnome3? 2017-06-09 07:32:28 clandmeter, does not seems so 2017-06-09 07:33:42 we've this (old) doc: https://wiki.alpinelinux.org/wiki/Gnome_Setup 2017-06-09 07:33:57 kaniini, are you planning to add something like setup-gnome3? 2017-06-09 07:34:57 someone knows a carddav/caldav client usable with curses? 2017-06-09 07:35:14 a curses addresbook/cal who can be syncd 2017-06-09 07:35:19 curses only 2017-06-09 07:37:48 fcolista: yes, i3wm ;) 2017-06-09 07:38:10 scadu, i never used it 2017-06-09 07:38:13 i want to try 2017-06-09 07:39:02 fcolista: cool, let me know how do you like it (or not) :P 2017-06-09 07:39:24 scadu, so far not having a doc in the wiki :) 2017-06-09 07:39:59 i ran: setup-xorg-base 2017-06-09 07:40:21 echo "exec i3" > ~/.xinitrc 2017-06-09 07:40:26 startx 2017-06-09 07:40:30 that's all :) 2017-06-09 07:43:47 ok i need dmenu too 2017-06-09 07:52:01 I use rofi. it also has a window switcher 2017-06-09 08:33:49 firefox bar is messed up in i3 2017-06-09 08:35:01 fcolista: huh, do you have any screenshot? I didn't notice any issues with Firefox in i3 2017-06-09 08:54:40 scadu, are you using i3/ff in x86 ? 2017-06-09 08:59:05 fcolista: x86_64 2017-06-09 09:03:41 sigh 2017-06-09 09:03:49 so i try to upgrade chromium 2017-06-09 09:03:56 there is a build fix 2017-06-09 09:04:00 build error 2017-06-09 09:04:15 in third_party lib named swiftshader 2017-06-09 09:04:27 so i go down the rabbit hole 2017-06-09 09:04:46 i clone the swiftshader repo and try build 2017-06-09 09:05:05 it fails to build 2017-06-09 09:05:17 it has a subdir called "third_party" ... 2017-06-09 09:05:21 which is llvm 2017-06-09 09:06:12 /o` 2017-06-09 09:06:24 so we patch our llvm to make it work 2017-06-09 09:06:58 but we also have to patch every app that uses the already fixed package in a "third_party" /o\ 2017-06-09 09:10:18 Shiz: can you help me get our patches for llvm upstream? 2017-06-09 09:12:52 ncopa, would make sense that alpine's user goign to use docker for those kind of apps :) 2017-06-09 09:13:24 possibly 2017-06-09 09:13:40 but its kind of inconvenient to run x11 apps in docker 2017-06-09 09:13:45 even if its possible 2017-06-09 09:21:10 and llvm is mostly ok too apparently 2017-06-09 09:21:32 they just dont run the configure or cmake scripts to set config.h 2017-06-09 09:21:49 and instead assume that linux HAVE_MALLINFO and HAVE_EXECINFO 2017-06-09 09:41:20 ncopa: yes 2017-06-09 13:18:06 sqlite since 3.16 had bug that could lead to db corruption w/ auto_vacuum (thankfully w/o data lost), so it would be good to upgrade to latest 3.19.3. 2017-06-09 13:18:32 s/lost/loss/ 2017-06-09 13:28:39 oh noes, the vacuuming bs has made its way to sqlite? 2017-06-09 13:44:48 przemoc: would be nice if you could file a bug on bugs.alpinelinux.org 2017-06-09 13:44:52 so its noforgotten 2017-06-09 13:47:26 ok, I thought that upgrade tickets were not welcomed for some time, good to know it's not the case apparently. but cannot do it right now, will do tonight or tomorrow. 2017-06-09 14:37:32 clandmeter: no i am generally opposed to adding more setup- scripts 2017-06-09 15:32:13 Has anyone got any experience with the mkimage scripts? 2017-06-09 15:32:51 I'd like to bring the PXE wiki page a bit up to date with an example of a build with mkimage, but the documentation for mkimage is a tad lacking :( 2017-06-09 15:44:42 ncopa, about community/ytnef, https://en.wikipedia.org/wiki/Transport_Neutral_Encapsulation_Format says its "TNEF is a proprietary email attachment format" 2017-06-09 15:44:47 I hope this is ok ? 2017-06-09 15:46:42 was not winmail.dat or win.dat associated with virus's decade back !!? need to check back 2017-06-09 15:53:42 I have a quasi-positive feeling that this new found love of MS for Linux is not good for economy ;) 2017-06-09 18:43:25 kaniini, are you going to write something down on the wiki on how to get gnome3 setup? i have no idea how much work it is. 2017-06-09 18:43:56 clandmeter: once complete, it will just be 2017-06-09 18:44:09 clandmeter: setup-xorg-base gnome-desktop-environment@testing 2017-06-09 18:44:52 ok by meta pkg. 2017-06-09 19:31:10 random question, if i have the ghc release candidate working, would it pay at all to get that into testing or just wait for release? 2017-06-10 00:15:56 firefox-52.0.2-r1 doesn't seem to be available on the mirrors (not even on rsync.alpinelinux.org) even though the build seems to have passed. Any idea what might be causing this? 2017-06-10 00:28:28 nmeum: for edge? 2017-06-10 00:35:45 Xe: jap 2017-06-10 00:35:48 *yes 2017-06-10 03:25:18 nmeum: it was replaced by firefox 53, which is presently held 2017-06-10 03:31:57 kaniini: I don't see firefox 53 in the repos just firefox-esr-52.1.2-r0 and firefox-52.0.2-r0 2017-06-10 03:32:11 its there 2017-06-10 03:32:26 it's just not yet built 2017-06-10 03:36:46 why wasn't it build so far? 2017-06-10 03:36:58 firefox-esr-52.1.2-r0 and firefox-52.0.2-r0 depend on an old version of libvpx and can't be installed currently 2017-06-10 03:39:06 testing is stalled. 2017-06-10 03:39:11 i just fixed that 2017-06-10 03:39:13 give it about 1 hr 2017-06-10 03:40:01 ah, that's what I suspected. thanks! 2017-06-10 04:04:24 Hi, I'm trying to use abuild to create a custom nginx apk, and I'm wondering how to debug a failure in a split modules function. https://github.com/baxterworks-build/nginx-docker-build/blob/master/nginx/APKBUILD 2017-06-10 04:04:56 The error I'm getting https://www.irccloud.com/pastebin/y5Z6dmXc/ 2017-06-10 04:41:06 linux is hard, lets go shopping 2017-06-10 04:56:46 nmeum: testing/firefox 53.0.3-r0 building 2017-06-10 05:14:37 nmeum: uploaded 2017-06-10 10:41:43 hi there Alpiners, we over here at Adelie have a few questions and stuff about Alpine if you have a moment this weekend! http://lists.alpinelinux.org/alpine-devel/5686.html 2017-06-10 12:50:16 <_ikke_> awilfox: Most core devs are mainly active during the week 2017-06-10 20:37:13 Ganwell, qtop 2017-06-10 20:37:20 sorry, wrong window 2017-06-10 22:21:09 i will reply in a bit 2017-06-11 04:40:07 #7412 is a nice little welcome present 2017-06-11 06:32:53 whatever 2017-06-11 13:44:50 <^7heo> do we have another MTP support than gvfs? 2017-06-11 13:49:03 <^7heo> ncopa: ^ 2017-06-11 13:49:38 <^7heo> we don't have PTP, that's for sure. 2017-06-11 17:04:02 look for things that build depend on libmtp-dev 2017-06-11 18:14:12 good news, I just built s390-tools (with zipl) successfully based on ncopa patches. It uses musl iconv patch with utf8-ibm1047 conversion. Hopefully we can install alpine on disk on s390x, even though we can boot in KVM with a minirootfs + kernel + initramfs 2017-06-12 01:28:09 where do patches to `abuild` itself go? alpine-devel@ list? 2017-06-12 01:28:17 or still alpine-aports@? 2017-06-12 01:28:43 awilfox: IIRC github pull requests are checked more often 2017-06-12 01:29:56 Xe: yes, but if I do not want to use github, what do I do with my patch 2017-06-12 01:37:50 http://foxkit.us/linux/0001-abuild-More-readable-message-for-missing-dependencie.patch 2017-06-12 01:38:03 where do I email this file :P 2017-06-12 03:05:13 is there any way to get abuild to do something like `set -x`? i.e. see what commands it is running? getting really dumb errors that imply I'm doing something wrong, but I can't tell what it is 2017-06-12 03:09:44 looked at `procps` which is also a gitlab URL and found what I was doing wrong! never mind :) 2017-06-12 03:12:28 any canonical list of valid `license` values? not sure how to specify a package is public domain 2017-06-12 03:12:47 hmm, let me think of one, maybe it is in the tree already 2017-06-12 03:23:14 next stupid question: is there a way to specify a checkdepends? or does it go in makedepends? 2017-06-12 04:45:07 awilfox : I usually manually add set -x to either /usr/bin/abuild or APKBUILD file itself to debug 2017-06-12 04:52:54 hmm 2017-06-12 04:57:36 tmh1999: I will submit http://foxkit.us/linux/0002-abuild-Add-verbose-option-v-to-show-everything.patch separately, maybe it can help others too :) 2017-06-12 04:57:50 but if it isn't wanted, it doesn't have any relation to the error message rewording 2017-06-12 04:59:09 afaik github is temp solution so I would be happy to open a github account and submit. but ymmv :D 2017-06-12 05:00:30 I have a github account, I just don't like using it or perpetuating the use of it 2017-06-12 05:04:57 that's the price I can live with 2017-06-12 05:09:02 anyway I find github is pretty good, even though it took me some time to get used to patchwork and like it. 2017-06-12 05:31:42 tmh1999, awilfox: I just wrote about getting verbose output out of abuild - struggled with it for a couple of days. https://blog.voltagex.org/2017/06/11/failing-to-build-an-nginx-addon/ 2017-06-12 05:34:10 voltagex: well then I guess this is definitely something that people need 2017-06-12 05:34:43 Definitely. Unfortunately I still was unable to rebuild nginx. 2017-06-12 05:36:14 hm I just found patchwork but it still only seems to be for aports 2017-06-12 05:36:37 and choosing 'all projects' in the patchwork menu brings me back to the aports project 2017-06-12 07:18:13 awilfox, patchwork currently only shows alpine-aports@lists.alpinelinux.org 2017-06-12 07:53:29 ncopa, http://www.enricozini.org/blog/2017/debian/debian-jessie-live-on-uefi-part-2/ 2017-06-12 07:53:32 "For a USB key, it seems that most hardware will happily look for efi/boot even if the partition table is the old MBR kind" 2017-06-12 07:53:55 morning 2017-06-12 07:54:00 unlike most understanding that GPT is needed 2017-06-12 07:54:18 morning, an new week! 2017-06-12 07:56:01 vkrishn: thats interesting 2017-06-12 07:56:09 and good news 2017-06-12 07:56:44 it means that it is easy to add uefi support 2017-06-12 07:56:52 yes 2017-06-12 07:58:21 vkrishn: it should be easy to test 2017-06-12 07:58:29 apk add syslinux 2017-06-12 07:58:56 copy /usr/share/syslinux/efi64/* to usb stick in efi/boot/ 2017-06-12 07:59:26 rename efi/boot/syslinux.efi to efi/boot/bootx64.efi 2017-06-12 07:59:34 and maybe it just works 2017-06-12 08:00:20 but I am not sure if it has to be written within 1st few mb (how much ?) of the 1st partition 2017-06-12 08:00:43 boot usb should be a single partition 2017-06-12 08:00:48 so its the first parition 2017-06-12 08:00:56 and its fat 2017-06-12 08:01:07 uhmm! 1st part should be FAT, I think 2017-06-12 08:01:19 need to go out for an hour 2017-06-12 08:01:39 thanks 2017-06-12 08:08:48 also, I am looking for old donated harware (not more than 4-6yrs), anything that can be useful for builing AL, if someone comes across or can mediate the source would be helpful. I am located in India (I can bear some import cost if its reasonable). email: vkrishn@insteps.net 2017-06-12 08:39:16 hmm, unless GUID is needed 2017-06-12 08:46:24 clandmeter, so is that where to send abuild patches? or is github really best/only option here? if so, I can use it 2017-06-12 08:50:15 I'm sorry, I really do not try to be difficult, I just like to use more "official" method than github where possible 2017-06-12 09:13:41 awilfox: you can send patch alpine-devel@lists.alpinelinux.org or via github 2017-06-12 09:13:51 if AL were to replace Remine, Patchworks and anyother dev setup, what features and language would be most welcomed ? 2017-06-12 09:14:00 seems we have dislikes for Github, Redmine and Patchworks, Ruby.... 2017-06-12 09:14:12 Php ;) 2017-06-12 09:14:36 if patch is trivial you can even `git format-patch -1 --stdout | tpaste` and paste the url here, if you have someones attention 2017-06-12 09:15:06 i think the current "official" way is via alpine-devel@lists.alpinelinux.org 2017-06-12 09:15:27 i am also open for suggestions how to improve that 2017-06-12 09:16:05 vkrishn: we will always have someone who dislikes anything we pick 2017-06-12 09:16:46 I remember lots of wooes and curses 1.5 AL+ cycle back about Redmine, but no one came up with lists of features 2017-06-12 09:17:39 for all I know Git is only app that everyone likes 2017-06-12 09:19:34 there is liking for how Patchworks works, but dislikes for Python 2017-06-12 09:20:01 redmine is not perfect, but acceptable 2017-06-12 09:20:09 github is not perfect either 2017-06-12 09:20:33 the major benefit with github is that most people already have an account there 2017-06-12 09:20:43 so no need to create another username or password 2017-06-12 09:20:50 yes, thats what we want to clear, and make some list, I think that can serve and TODO for new developers 2017-06-12 09:21:17 patchwork solve another issue 2017-06-12 09:21:36 helps us keep track for patches sent via email 2017-06-12 09:21:52 the problem is everyone says, "I dislike, blahblah", but why? becomes a mystery 2017-06-12 09:22:43 i normally dont have problem understand why people dislike blahblah 2017-06-12 09:23:08 coz, we can know what is wanted, maybe that can spin a new development , economy around it 2017-06-12 09:23:37 i know pretty much what we want 2017-06-12 09:28:16 so something like , devs put a PR on github, and we have some kind of auto PULL in local/public git setup, that auto creates new branch based on Github-User 2017-06-12 09:28:41 gitlab like setup ? 2017-06-12 09:29:38 then AL devs would not have to deal with Github directly 2017-06-12 09:30:25 there is nice thing about gitlab, it can do "log in with github" then you also don't need account 2017-06-12 09:30:56 I was looking at taiga at https://taiga.io and that looks like very nice software for distro development too :) 2017-06-12 09:31:21 was thinking about maiing packages for its requirements and it, but haven't found time just yet. 2017-06-12 09:32:42 also ncopa I did paste link above: http://foxkit.us/linux/0001-abuild-More-readable-message-for-missing-dependencie.patch is simple one line patch, and http://foxkit.us/linux/0002-abuild-Add-verbose-option-v-to-show-everything.patch adds feature that a few of us seem to want 2017-06-12 09:35:27 so basically a strong coherent/consistent system, that avoids new learning curve for existing flow is what is needed 2017-06-12 09:36:25 there is also Phabricator, it is what KDE team uses, but sadly that is PHP... 2017-06-12 09:36:37 of course, taiga is python and gitlab is ruby on rails... 2017-06-12 09:37:40 ruby, python(to some extent), php are (-)ves 2017-06-12 09:38:09 ruby - coz pkging them in AL way is a woe 2017-06-12 09:38:27 php - kinda uhem cough! 2017-06-12 09:38:49 python is ok, as long as python2/3 gets amicably resolved 2017-06-12 09:39:04 is if its lighter not a bloat 2017-06-12 09:41:36 awilfox: for abuild -v i have used: sh -x /usr/bin/abuild 2017-06-12 09:42:23 ncopa: ah hm. maybe that should be documented, it seems three of us at least never thought to do that haha 2017-06-12 09:42:30 you can skip that patch 2017-06-12 09:42:39 i suppose it is ok though 2017-06-12 09:42:44 abuild -v kind of make sense 2017-06-12 09:42:45 but 2017-06-12 09:43:00 maybe abuild --debug would make more sense than "verbose" 2017-06-12 09:43:13 good point, I can rework it 2017-06-12 09:43:37 the other is all good 2017-06-12 09:43:41 hm, does ash have a getopt_long type thing? maybe time to brush up on my advanced shell voodoo :) 2017-06-12 09:44:38 looks like busybox ash has gettopt --longoptions 2017-06-12 09:44:57 i have seen some nice posix shell compat option parser in lxc 2017-06-12 09:45:17 ah. I cn look there for inspiration then :) 2017-06-12 09:45:22 can* 2017-06-12 09:45:53 the lxc templates 2017-06-12 09:46:39 vkrishn: re php vs python vs ruby 2017-06-12 09:46:56 lately i have been more "i dont care" 2017-06-12 09:46:57 neither 2017-06-12 09:47:29 i do want avoid php if possible though, because i think its really easy to mess up in php from security perspective 2017-06-12 09:48:00 we did have issues with ruby due to we wanted do apk packages, but i think now it doesnt matter that much 2017-06-12 09:48:23 i think python is nice, its just big and bloaty 2017-06-12 09:48:49 but i think its acceptable 2017-06-12 09:49:00 what we want are services that compliment our workflow, not make them a dependency. 2017-06-12 09:49:13 yes, exactly 2017-06-12 09:49:42 from bugtracker, the most wanted feature is to be able to create one ticket for multiple git branches 2017-06-12 09:49:51 and when its solved in all git branches the ticket gets closed 2017-06-12 09:49:55 the language its made of is not of much importance. 2017-06-12 09:49:57 is there a feature in Patchworks, that can auto Pull github PRs ? 2017-06-12 09:50:19 clandmeter: +1 2017-06-12 09:50:29 vkrishn: no that i know 2017-06-12 09:53:03 what if we had our own git clones for pkgs, will it be a lots of work ? 2017-06-12 09:53:29 then we have alpine branch as front for cgit 2017-06-12 09:54:27 patches still remain in aports 2017-06-12 09:55:02 git clones for pkgs? 2017-06-12 09:56:05 yes, debian / redhat have internal git clones of lots of pkgs 2017-06-12 09:57:04 local alpine branch simply makes its ready for AL build workflow 2017-06-12 09:58:32 you mean a repo per aport 2017-06-12 10:07:11 eg, anonscm.debian.org 2017-06-12 10:09:30 we maintain a clone of each package 2017-06-12 10:16:40 kinda, https://alioth.debian.org/ 2017-06-12 10:20:47 one benefit is , single point to show any upstream for any change/bug fix 2017-06-12 10:33:17 gitlab, seems its "not entirely opensource", http://blog.snow-crash.org/blog/upcoming-alioth-sprint/ 2017-06-12 10:35:02 gitlab is open source, but some features they only offer commercially, as modules 2017-06-12 10:35:21 something like ldap group authentication or something is a module that is commercial only 2017-06-12 10:37:45 would be a bit or initial work, but svn, cvs upstream can be converted to git too 2017-06-12 10:37:50 bit of* 2017-06-12 10:37:53 there are enough alternatives like pagure or gitea. but i dont think they offer more then github does? 2017-06-12 10:38:31 I think we wan to keep things simpler, fitting our distro philosophy 2017-06-12 10:43:40 pagure is not really ready for primetime on non-fedora 2017-06-12 10:44:16 it still has lots of things that are red hat specific in it. I have my fox paws in a lot of distros, and one other one tried to set up pagure. had lot of issue trying to make it work without using fedora/systemd. ended up with gitlab :( 2017-06-12 10:44:27 so that would need to be a project undertaken by multiple people, to get pagure 'ready' 2017-06-12 10:44:59 the effort might be worth it; it is afterall what alpine did with musl too :) 2017-06-12 10:46:26 we need some kinda of response, partial it maybe, for devs that put some time in patches/PRs 2017-06-12 10:46:51 it could be automated PULLs and email of acknowlegement 2017-06-12 10:48:49 we can even pub those PRs on our MQTT radio ;) 2017-06-12 10:50:31 awilfox: im very happy that you want build adelie with alpine 2017-06-12 10:50:32 that no devs need to leave the AL cozy seat 2017-06-12 10:51:11 awilfox: what are the major difference(s) in the way you build packages compared to alpine? 2017-06-12 10:53:27 ncopa: `ebuild` vs `abuild`, and we were/are using gcc5.4.0 instead of 6.3 2017-06-12 10:54:17 ncopa: otherwise, not too much different. we do use PIE, and we were going to switch to -as-needed with ld too, so it isn't so different 2017-06-12 10:54:53 do you have many extra patches to packages? 2017-06-12 10:55:01 we try avoid patches if possible 2017-06-12 10:55:17 it is long time since I wrote APKBUILD, so I'm still a bit rusty yet; 2017-06-12 10:55:21 https://git.alpinelinux.org/cgit/aports/commit/?id=9928d87ec39dd70d9395bee945ae7484c2d8dcdb 2017-06-12 10:55:26 that would be the last time I wrote one, haha 2017-06-12 10:56:07 nice :) 2017-06-12 10:56:32 ncopa: a lot of the packages that we carry patches for, alpine has same/similar patches. I instituted a rule long ago that we only carry patches for upstreams that refuse to accept contribution to fix build/runtime on musl, or until they push a released version. 2017-06-12 10:56:52 thats similar to what alpine does 2017-06-12 10:56:54 good 2017-06-12 10:57:17 then i wonder about configure options 2017-06-12 10:57:18 I'm actually working with KDE team to get the last three patches needed in, then all of plasma5 will build/run on musl without patch. 2017-06-12 10:57:33 very nice :) 2017-06-12 10:57:55 kicking the tyres on my work laptop actually. it seems mostly stable. more stable than my glibc computer, even... 2017-06-12 10:58:06 :) 2017-06-12 10:58:08 seen two kwin crashes on my glibc computer since I set up the musl laptop. no crashes to report 2017-06-12 10:59:51 give me a few minutes; I need to change out the certificate on our gitlab server, since it is the last of the startcom certs I have... comodo just issued new one 2017-06-12 11:13:16 beautiful, now I never have to worry about chrome users not being able to access gitlab 2017-06-12 11:14:08 ncopa: so, a few things I'd like to fox about. first, I have divided adelie's repo (so far) into three categories (I guess in alpine parlance, repositories; this is like main/ testing/ community/ in alpine) 2017-06-12 11:15:38 ncopa: they are system/ user/ and nonfree/. nonfree is for stuff like radeon drivers or wifi blobs (if alpine's non-free doesn't have it already). system is for stuff that adelie needs for base that alpine does not (so, stuff like shadow). then user is for normal apps like taiga or systemtap or plasma5. it is my hope, though it may not always be possible, for user APKs to be installable on alpine 2017-06-12 11:15:40 systems too 2017-06-12 11:16:27 makes sense 2017-06-12 11:16:35 what are the things missing in main? 2017-06-12 11:16:47 i am open for moving things to there 2017-06-12 11:17:09 so "main" repon in alpine is what we support for 2 years 2017-06-12 11:17:16 well so far I only accidentally packaged one thing that is already present in alpine. I didn't have testing/ enabled, so I didn't see it; dejagnu is needed to test psmisc 2017-06-12 11:17:18 while community is 6months 2017-06-12 11:17:45 I ended up with https://code.foxkit.us/adelie/packages/blob/master/user/dejagnu/APKBUILD which is slightly different from https://git.alpinelinux.org/cgit/aports/tree/testing/dejagnu/APKBUILD 2017-06-12 11:18:43 it would be neat if someone could explain some of the differences, again I haven't done APKBUILD for a long time so it seems I may have missed some stuff from the wiki docs... 2017-06-12 11:19:21 for instance, the alpine one defines _builddir manually, where builddir seems to work fine for me. is there a reason to do that? does it make it faster or more explicit? 2017-06-12 11:20:31 also, is the prepare() boilerplate? does it do something different to the built-in prepare()? is that just the way the newapkbuild applet used to generate them? 2017-06-12 11:21:06 the _builddir define is no longer needed 2017-06-12 11:21:12 and prepare() is no longer needed 2017-06-12 11:21:14 also how do you tell if it needs 'texinfo' in makedepends? that isn't present on my experimental box, and it seems to build fine... didn't see anything in the config logs about it either. so how do you tell? 2017-06-12 11:21:17 was needed in older abuild 2017-06-12 11:21:30 it does indeed build info pages if it is present.. 2017-06-12 11:21:38 I feel like I'm missing something obvious on how to tell :/ 2017-06-12 11:21:40 texinfo i dont know, but i suspect older dejagnu needed it 2017-06-12 11:21:50 i think your variant is better than what we have 2017-06-12 11:22:13 oh o.o 2017-06-12 11:22:31 the only thing i'd like to comment in your variant is that you dont need to: makedepends="$depends ..." 2017-06-12 11:23:05 oh okay. that is probably gentooism, since you typically have to do DEPEND="${RDEPEND} ..." 2017-06-12 11:23:08 after taking a look at both versions, I confirm that ncopa's version is the "old" way of writing APKBUILDs 2017-06-12 11:23:09 sorry 2017-06-12 11:23:24 and the ones I write nowadays are much closer to awilfox's version 2017-06-12 11:24:08 generally speaking, I think the more declarative you can get, the better 2017-06-12 11:25:57 I dunno if 'check' is okay. it uses the just-built version to test itself if it is not already installed. 2017-06-12 11:26:16 so it does work (and pass), but I'm not sure how well you can trust a just-built thing to test itself 2017-06-12 11:26:17 awilfox: ok if i push this? http://tpaste.us/zbna 2017-06-12 11:26:46 ncopa: certainly :) 2017-06-12 11:26:49 awilfox: why wouldn't you trust it? isn't that what a package's "make check" is for? 2017-06-12 11:27:34 skarnet: well.. let me put it this way.. when I cross-compiled the first-ever ppc32 chroot for musl.. bash managed to return 0 for PIPESTATUS no matter what happened on the other end of the pipe 2017-06-12 11:27:48 skarnet: so that would always pass tests (everything, always, returns 0) 2017-06-12 11:28:12 that's a bug in the software, not in the way you invoke checks 2017-06-12 11:28:14 that was actually a bug in binutils, it was crossed wrong 2017-06-12 11:28:20 exactly 2017-06-12 11:28:21 (oops) 2017-06-12 11:28:42 skarnet: but still, `make check` could have passed where it should not have because of silly like that. I want something I already know that works to test software 2017-06-12 11:28:44 it's not check()'s job to detect those 2017-06-12 11:29:22 well if you find a more reliable check, just write it in check(), obviously, but that's software-specific 2017-06-12 11:29:36 skarnet: it doesn't help when you are checking check software XD 2017-06-12 11:29:50 we must go deeper 2017-06-12 11:29:53 skarnet: helpfully, it /does/ have a single 'expect' script (which is what dejagnu is written atop) 2017-06-12 11:30:00 skarnet: so it does have a sort of bootstrap test script 2017-06-12 11:30:25 so I guess, if you test 'expect' using raw tcl scripts... and then test tcl somehow.. then you can be confident 2017-06-12 11:30:59 tcl's test suite wouldn't run on adelie gentoo-edition, because it couldn't handle some of musl's defaults. dunno if it will happen here, or if it is fixed in new version 2017-06-12 11:32:58 wow. psmisc fails its own test suite when using --enable-mount-info because the mount info line isn't parsed correctly... 2017-06-12 11:45:37 >>> ERROR: adelie-base: Missing dependencies (use -r to autoinstall or -R to build them): shimmy noxcuse nail sharutils 2017-06-12 11:45:43 nice, that is not too many :) 2017-06-12 11:55:45 https://bpaste.net/show/e01c629f3acc this maybe should be fixed sometime too ;) 2017-06-12 11:56:15 (if you wonder: my old buildbox name was 'ciall', so that is where 'ciallpine' comes from.. bad pun) 2017-06-12 14:15:58 wrt previous conversation regarding firejail and its unreliability, I don't think other such tools exist in the available packages. I could spend a bit of time making an APKBUILD for an alternative, but which one? opinions welcome 2017-06-12 14:18:17 docker? 2017-06-12 14:19:08 isn't docker a bit overkill for that? 2017-06-12 14:19:32 possibly 2017-06-12 14:20:43 there's at least nsjail, minijail, bubblewrap (ah! this one is in the repos!) and runc and probably a couple I'm not even aware of 2017-06-12 15:29:34 I am not an expert in software for development team, recently I see chromium + openstack use monorail. 2017-06-12 16:08:03 what is a valid version according to apk version --check? 2017-06-12 16:08:18 x.y.z-rc1 is not 2017-06-12 16:08:27 x.y.zrc1 is not 2017-06-12 16:08:33 x.y.z_rc1 is not 2017-06-12 16:08:53 how do I add a suffix and make apk version --check (and abuild) happy? 2017-06-12 16:12:06 x.y.z_rc1 should be valid; apk follows gentoo's version syntax 2017-06-12 16:14:01 3.0.0_alpine1 is not a valid version 2017-06-12 16:14:52 does it have to be "rc" to work? 2017-06-12 16:15:04 can't I call something _alpine1 or _stable? 2017-06-12 16:30:20 are you fucking serious 2017-06-12 16:30:24 static const char *pre_suffixes[] = { "alpha", "beta", "pre", "rc" }; 2017-06-12 16:30:34 you explicitly whitelist suffixes? 2017-06-12 16:33:34 guess I'll have to override sanitycheck() then 2017-06-12 16:34:18 would you take patches making apk version less fascist, or shouldn't I even bother? 2017-06-12 17:02:36 skarnet: 1.0_alpha0 < 1.0_beta0 < 1.0_rc0 < 1.0_pre0 2017-06-12 17:03:00 or maybe _pre < _rc 2017-06-12 17:03:19 ncopa: yes, I understood that. Still unnecessarily fascist. 2017-06-12 17:04:20 I want to be able to use 1.0_gfyifyoudontlikemysuffix 2017-06-12 17:04:56 so how should apk compare "1.0_gfyifyoudontlikemysuffix" and "1.0_alpine1" ? 2017-06-12 17:05:04 lexical order is hard 2017-06-12 17:05:28 and specify that all suffixes are pre, so 1.0 is more recent than 1.0_whatever 2017-06-12 17:06:20 i think they are not 2017-06-12 17:06:29 i think 1.0_git20170601 2017-06-12 17:06:37 is version 1.0 + git patch 2017-06-12 17:06:53 SCM release numbers are a category on their own 2017-06-12 17:07:13 isolate a few post-suffixes if you have to 2017-06-12 17:08:00 for compatibility, keep your hardcoded list of pre and post suffixes, but allow me to use custom suffixes with lexical ordering 2017-06-12 17:08:18 I'll even take custom suffix < alpha0 2017-06-12 17:10:48 of course, if I spoof sanitycheck, I guess apk will barf on my custom version number later on, right? 2017-06-12 17:37:47 http://tpaste.us/LvXm <- scm.alpinelinux.org 2017-06-12 17:38:01 initial thoughts 2017-06-12 17:39:57 <_ikke_> vkrishn: what is the goal? 2017-06-12 17:42:35 1. local reliable tar.gz fetch, event uptream fails 2017-06-12 17:42:35 2. single point for notifying upstream of bug fixes/patches 2017-06-12 17:43:11 since we would be loggin the notification, an UI interface is possible 2017-06-12 17:43:46 single UI interface were host of status/info in present 2017-06-12 17:44:20 idea is, local AL dev need not run around from AL infra 2017-06-12 17:44:29 to other interfaces 2017-06-12 17:44:54 I am not saying at this point that is is easy or doable 2017-06-12 17:45:28 <_ikke_> right, it's a lot of work to maintain 2017-06-12 17:45:40 <_ikke_> and requires also infrastructure 2017-06-12 17:46:07 lot to work to maintain OR initial lot of work 2017-06-12 17:48:02 iirc, someone wrote here or in ML about pending 1000 PRs in github 2017-06-12 17:49:55 so is working with Github and issue or too much PRs and less devs ? 2017-06-12 17:50:02 an* issue 2017-06-12 18:00:57 <_ikke_> I think the latter 2017-06-12 18:01:26 <_ikke_> PRs are merged quickly enough once approved, just a lot of work to verify 2017-06-12 18:01:38 the latter, since sending patches to the ML is much worse XD 2017-06-12 18:06:13 I think laying all inputs and TODOs in single plate to devs would make things fun to work 2017-06-12 18:06:43 for new devs, it would be like, yeah! 2017-06-12 18:08:50 <_ikke_> I'm not too sure about that :) 2017-06-12 18:09:35 <_ikke_> github with travis integration means early feedback about build status 2017-06-12 18:24:02 travis does not seems to quite fit in AL philosophy setup 2017-06-12 18:27:14 any thoughts on https://flod.us/details.html 2017-06-12 18:46:45 also we have not harnessed full potential of mqtt(mosquitto) 2017-06-12 18:49:20 vkrishn: im not sure what problem you are trying to solve 2017-06-12 18:50:43 ncopa, there !!, why no dinner or overfed (digestive talk) ;) 2017-06-12 18:51:11 I was thinking of unified interface 2017-06-12 18:51:29 unified interface for ...? 2017-06-12 18:51:31 where many of things can just be done be 'mouse clicks' 2017-06-12 18:51:39 done by* 2017-06-12 18:52:05 you're describing a web browser 2017-06-12 18:52:07 i prever cli command + enter over mouse clicks :) 2017-06-12 18:52:56 well, interface is status` also 2017-06-12 18:53:08 cli is ok 2017-06-12 18:53:19 I would prefer too 2017-06-12 18:57:34 one should not wait for someone to go to, https://pkgs.alpinelinux.org/flagged and flag it 2017-06-12 18:57:59 I think scripts can gather that info and show what latest version is available 2017-06-12 18:58:09 auto flag 2017-06-12 18:58:51 dev need to check those and add comment if it does not make to next release 2017-06-12 18:59:38 scripts can auto detect freeze time and show that status..... there are hosts of other info 2017-06-12 18:59:57 flaging is work 2017-06-12 19:00:13 lots of work, its called repetetive work 2017-06-12 19:00:48 who wants to do it over and over, ! anyone ! 2017-06-12 19:03:00 sure we would hire someone to do a bots job, let bots do human work 2017-06-12 19:04:23 the flagged is generated from a script 2017-06-12 19:04:34 but then this an interface that is very likeable, atleast I like it 2017-06-12 19:05:05 i'd like a cli command that can give me a list of the flagged packages i am maintainer of 2017-06-12 19:05:07 in build order 2017-06-12 19:05:16 yes, cli is always there 2017-06-12 19:05:50 <_ikke_> That's a matter of creating an API which a cli program can consume 2017-06-12 19:05:52 its for devs, but browser gives anyone a quick insight and attracts users/devs 2017-06-12 19:06:38 I think the other way, design for cli in such a way a UI can be build around 2017-06-12 19:08:15 UI should be a clean wrapper 2017-06-12 19:11:10 these were few things i wanted couple of years back, but then http2.0,web2.0 seemed more important 2017-06-12 19:11:37 now that, that distruptive phase is pratically done 2017-06-12 19:12:15 I have almost 85%+ pkgs for next gen web dev in AL 2017-06-12 19:14:44 thanks to devs here who have added my pkgs requests :) 2017-06-12 19:16:43 back to flagged status page, I have seen in bugs.a.o reports on "pls update pkg A to version xyz" 2017-06-12 19:17:10 I think that should avoided and interfaced with flagged page 2017-06-12 19:17:18 its overflooding bugs.a.o 2017-06-12 19:18:09 with data that is obvious task to workflow of a distro 2017-06-12 19:18:17 rather eventual task 2017-06-12 19:18:31 you can flag packages manually on pkgs.alpinelinux.org 2017-06-12 19:18:54 yes 2017-06-12 19:19:11 "please update pkg ..." is not really overflowing our bugtracker. http://bugs.alpinelinux.org/projects/alpine/issues 2017-06-12 19:20:25 hmm... so if someone does not add it, does it mean it does not get updated ? 2017-06-12 19:20:42 its an eventual distro task 2017-06-12 19:21:28 it should go in bugs report if a bug arises out of current working pkg 2017-06-12 19:22:11 what I am pointing is , somethings can be avoided 2017-06-12 19:23:17 coz, things go haywire 1months prior to release, oh! look 1000 open bugs.a.o 2017-06-12 19:28:09 for instance #7178 never got looked at to mark its "Assignee" and "Target version", even though several kernel updates happed 2017-06-12 19:29:02 I am not saying it should be done, but being acted upon sometimes more important 2017-06-12 19:30:02 its possible to have a scanner to tag(keywords) it and then categorize them 2017-06-12 19:30:11 some keywords get more attention 2017-06-12 19:30:49 so when we run short of devs, it works like an auto sorter 2017-06-12 19:31:43 priortizing the work 2017-06-12 19:37:47 these rough gooey ideas, not saying should be done 2017-06-12 19:44:09 https://pkgs.alpinelinux.org/flagged, this should be comment driven , multiple comments/reply ability 2017-06-12 19:44:52 like "stalling version z.y.z for pkg A, reason ...." 2017-06-12 19:46:36 or "this is beta release, would wait for 1 months" 2017-06-12 19:47:51 things like this auto-melds in rolling release 2017-06-12 19:50:35 I just got an email when a package I had was out of date, was pretty easy to bump the version a couple days later 2017-06-12 19:51:18 and for the other things that I care about, i'm testing out the release candidates so its more likely i'll have the new version out prior to most people noticing 2017-06-12 19:51:34 what if you could send some pre-defined keywords like "WIP, moderate delay..." 2017-06-12 19:51:49 and that gets added to comments 2017-06-12 19:52:13 so moment you get a email, you should back a mqtt, say WIP 2017-06-12 19:52:20 you shoot back* 2017-06-12 19:52:57 so now we know , that the maintainer has acted upon 2017-06-12 19:54:53 or if simple bump compiles in local, mqtt msg "BUMP it" 2017-06-12 19:55:34 well that would be a bit complicated ;) 2017-06-12 20:02:23 btw, just noticed that main/php5-phalcon got erased, without notice !? 2017-06-12 20:06:06 but thats cool, from rolling release point of view, "php7 rolled over php5" 2017-06-12 20:07:33 irrespective whether in main/ 2017-06-12 22:53:36 i really like this update flagging system 2017-06-12 22:53:47 please keep it :D 2017-06-13 01:21:44 Xe: we are working on automatic update tests 2017-06-13 01:22:05 that sounds amazing 2017-06-13 02:41:53 hmm, is there any place that you can see a list of valid license= for packages? or is it freeform? don't see anything in apk or abuild 2017-06-13 03:01:33 wow, openrc has terrible documentation :( 2017-06-13 03:03:28 gnome is almost done, just trying to figure out what is responsible for blanking the screen 2017-06-13 03:03:31 although i think 2017-06-13 03:03:35 that may legitimately be gdm 2017-06-13 03:03:37 gross :| 2017-06-13 03:17:14 http://i.imgur.com/yMPwzYg.png 2017-06-13 04:02:47 http://foxkit.us/linux/aports-licenses.txt # result of /usr/bin/grep -Ihr license= . | sort | uniq -c | sort -rh 2017-06-13 04:03:32 would there be any support if I endeavoured to clean this all up? 2017-06-13 04:03:47 my favourite might be: 2017-06-13 04:03:51 22 license="open_source" 2017-06-13 04:03:57 how specific :) 2017-06-13 04:07:11 also it may be worthwhile to see about making sure of GPL versions, some have none, and 112 have 3 but not 3+ which imo is a bit odd 2017-06-13 04:08:02 then, once we have a more rigid license= field, perhaps we can make a .txt in aports root with valid licenses, and then abuild can warn if you specify one not on the list 2017-06-13 04:48:48 here is a fuller screenshot of the manpage: http://i.imgur.com/nrOGoOt.png comments welcome! I would normally link directly but I don't think anyone wants to review groff text 2017-06-13 04:51:33 <_ikke_> Not sure if fixable, but the description of parameters with arguments is not aligned 2017-06-13 05:02:19 _ikke_: good eye, that was due to spurious newlines 2017-06-13 05:02:21 fixed 2017-06-13 05:05:26 I think it'd be really good to make an APKBUILD.5 that is basically a cleaned up version of https://wiki.alpinelinux.org/wiki/APKBUILD_Reference 2017-06-13 05:05:38 the problem is, I am not sure how it would be kept in sync with the wiki, and I don't want to cause duplication of effort :/ 2017-06-13 05:06:25 <_ikke_> It does not change *that* often 2017-06-13 05:06:29 but having the reference right there on the user's computer if they apk add abuild-doc might be useful for people who don't want to open a browser, or indeed, don't have one built yet for their arch, or just want a local reference for offline reading :) 2017-06-13 05:06:59 <_ikke_> I agree 2017-06-13 05:07:01 that is true 2017-06-13 06:40:21 awilfox: very nice! 2017-06-13 06:41:17 i think we want move the official docuemtnation from wiki to something thats is generated from markdown/asciidoc/something and tracked in git 2017-06-13 06:41:44 and whenever we get there, i'd like to autogenerate the docs from the man pages 2017-06-13 06:42:20 awilfox: i'm all for the license cleanup. i have just been lazy 2017-06-13 06:42:47 and if we require stricter license, we should have a whitelist and show a warning as you suggest 2017-06-13 06:52:02 why autogenerate the docs from the man pages and not the other way around 2017-06-13 06:52:19 do you love writing all your docs in nroff? 2017-06-13 07:36:38 or the other way around. good point 2017-06-13 07:41:46 somebody should start using docs.a.o :) 2017-06-13 07:47:03 yeah :) 2017-06-13 07:47:09 https://github.com/alpinelinux/alpine-wiki 2017-06-13 07:47:41 we should have CI to check for proper markup and auto commit. 2017-06-13 07:48:05 i think what we want to do is separate the user wiki with official alpine docs 2017-06-13 07:48:29 then make sure we have "users manual" and "install docs" and similar as the official alpine docs 2017-06-13 07:48:34 move that out from wiki 2017-06-13 07:49:06 that way we have a separation from official documentation and community wiki 2017-06-13 07:49:29 why not have 2 sections? 2017-06-13 07:49:43 do we still want to keep mediawiki? 2017-06-13 07:50:14 i don tknow if we need it 2017-06-13 07:50:37 it is still kind of nice to have something that anybody can edit 2017-06-13 07:50:41 write how to do things 2017-06-13 07:50:48 after talking to a few ppl, they all prefer a wiki in git. 2017-06-13 07:50:54 ok 2017-06-13 07:50:58 well 2017-06-13 07:51:01 you can edit from github 2017-06-13 07:51:46 while we do the move, i want make a split of official docs and community wiki 2017-06-13 07:52:01 i agree 2017-06-13 07:53:29 this means we need to figure out what belongs to the official docs and what belongs to community wiki 2017-06-13 07:53:34 maybe starting with documenting apk inside docs.a.o would be a good start. 2017-06-13 07:54:00 i was thinking install docs 2017-06-13 07:54:14 how to install alpine 2017-06-13 07:54:32 lets say you are a new user and want install alpine 2017-06-13 07:54:42 you dont even know what flavor to install 2017-06-13 07:54:45 so you look for the docs 2017-06-13 07:54:56 "how do i get started?" 2017-06-13 07:55:31 yes, install docs and developer docs are first class citizens. 2017-06-13 07:56:06 so the docs should guide the user though, getting the iso, creating boot media, boot, run installer 2017-06-13 07:56:43 then the user guide (or admin guide) should tell how to do normal admin tasks, like adding users, installing software, starting/stopping services 2017-06-13 07:58:43 are there any examples of proper documentation? 2017-06-13 07:58:54 any project that already does it the right way? 2017-06-13 07:59:44 http://www.freebsd.no/doc/en_US.ISO8859-1/books/handbook/ 2017-06-13 08:01:17 https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Installation_Guide/index.html 2017-06-13 08:03:09 redhat docs are nice. wonder if thats feasible. 2017-06-13 08:04:52 The question is, how do we start? just copy things from wiki or start new? and what about CI/content approval. 2017-06-13 08:06:52 the problem with wiki is that content grows organically, there is no architected structure with it 2017-06-13 08:07:14 so i think the way to start is to make a structure, what we want in the official docs 2017-06-13 08:07:24 make the headings for example 2017-06-13 08:07:29 the skeleton 2017-06-13 08:07:45 then take bits from the wiki into there 2017-06-13 08:07:54 and yes it is a pretty big project 2017-06-13 08:08:26 so i think we could start with an "installation guide" or similar 2017-06-13 08:09:41 i think the challenge is that we cannot remove anything from wiki until we have something to ship as official doc 2017-06-13 08:09:59 and we need something that works before we can ship it 2017-06-13 08:31:40 awilfox: cleaning licenses is obviously desirable and welcomed. I recently noticed that there are mistakes (tested small sample), but didn't have time and will to tackle it at full scale 2017-06-13 08:48:42 skarnet: man2html exists and it does lend itself to much cleaner on-screen layout than anything 2 man... 2017-06-13 08:49:05 ncopa: any desired format? GPL2 or GPL-2 or GPLv2? obviously the + if applicable 2017-06-13 08:49:32 it looks like most popular in the tree is 'GPL2' but that can be fixed with careful sed magick 2017-06-13 08:49:56 hm 2017-06-13 08:50:45 https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package#license 2017-06-13 08:50:58 whatever we do, we should adjust the docs accordingly 2017-06-13 08:51:32 https://wiki.alpinelinux.org/wiki/Package_policies 2017-06-13 08:51:44 other than that, i dont have strong opinion 2017-06-13 08:52:21 i might be slightly towards the fedora style, GPLv2, but no strong opinion 2017-06-13 08:53:08 wouldn't it be better to use some existing database for identifiers of licenses? e.g. https://spdx.org/licenses/ 2017-06-13 08:53:16 https://opensource.org/licenses/GPL-2.0 2017-06-13 08:54:49 yeah, i agree with przemoc, use some existing db for identifires 2017-06-13 08:55:02 that spdx style seems most legit. 2017-06-13 08:57:36 spdx works :) very similar to gentoo and debian actually. 2017-06-13 08:57:42 thanks przemoc! 2017-06-13 09:22:28 awilfox: I also appreciate any effort toward supporting de-GPL-ized userspace. you wrote about wanting to support non-busybox sh and I advocated such thing in the past, but being able to use nicer syntax in APKBUILD (like ${variable/search/replace}) unfortunately won. 2017-06-13 09:51:54 przemoc: I generally try to stay away from license discussions because politics are silly 2017-06-13 09:52:17 przemoc: but let me just say this: in FreeBSD, I worked on porting clang to sparc64 and making their elfutils package have a sufficient assembler to be able to remove binutils 2017-06-13 09:52:19 >_> 2017-06-13 10:01:47 awilfox: it's fine. core of the argument is actually to have a choice, obviously, like being able to use dash instead of busybox sh, etc. 2017-06-13 10:02:09 Shiz has also done some good job related to building clang-based AL recently 2017-06-13 10:03:03 wasn't following it that closely, but I hope it was a fruitful experiment 2017-06-13 10:10:48 przemoc: I was following it and it turned out pretty well as I understand :) 2017-06-13 10:53:12 hm, does busybox not have any docs? or is the doc package just missing? putting this here so I remember tomorrow to look... 2017-06-13 11:08:12 "The name of the package. All letters should be lowercase." "Huh, really? Curious fox is curious if people actually stick to that..." $ /usr/bin/egrep -Irh 'pkgname=\"?[A-Z]' . 2017-06-13 11:08:20 pkgname="A command-line client for etcd" 2017-06-13 11:08:37 that was the only result, it looks like a mistake: http://foxkit.us/linux/0001-testing-etcd-fix-origin-desc-of-ctl-subpackage.patch 2017-06-13 11:09:33 http://pkgs.alpinelinux.org/package/edge/testing/x86_64/etcd-ctl that origin though :D 2017-06-13 11:11:51 fcolista: ping, if you have a moment please see above linked patch 2017-06-13 11:12:45 awilfox, correct! 2017-06-13 11:13:29 awilfox, pushed 2017-06-13 11:15:40 great, thank you! 2017-06-13 11:15:58 also, for note: http://blog.qt.io/blog/2017/05/11/introducing-long-term-support-qt-5-9/ < so 5.9 should probably end up in main, and any .10/.11 should end up in community 2017-06-13 11:16:11 I see 5.8 is in main right now, that might be a bit painful to support for two years when upstream is moving so fast. 2017-06-13 11:16:53 we in adelie were holding on to 5.6, but since 5.9 is LTS and released two weeks ago, it might be prudent to bump the alpine builds and use them instead of doing our own thing 2017-06-13 11:19:24 5.9 also adds -Os support, which is a great addition too 2017-06-13 11:20:13 I can help with the bumping but that will need to wait for the weekend, as that is a pretty big project and I would like to put 'check' support in everything too. 2017-06-13 12:13:51 run on alpine is tmpfs, but what takes care of mounting it? 2017-06-13 12:17:53 openrc, i.e. one if its scripts 2017-06-13 12:19:18 /lib/rc/sh/init.sh 2017-06-13 12:20:06 hmm interesting 2017-06-13 12:43:03 przemoc, do you know what calls init.sh? 2017-06-13 12:58:37 Hi everyone, I've got a very simple question regarding APKBUILD files if anyone could offer some help... 2017-06-13 12:59:06 <_ikke_> sequedav: Best to just ask your question 2017-06-13 13:00:44 _ikke_ Hi! Right, I was wondering if it's possible to have "optional dependencies" in an APKBUILD. So I've got an Alpine-based Docker image which uses libressl but I'm repackaging an old package that uses openssl 2017-06-13 13:01:06 Is there any way I can specify in the APKBUILD a constraint that can be satisfied by having either libressl or openssl installed? 2017-06-13 13:08:21 clandmeter: openrc calls it when runlevel is sysinit. https://github.com/OpenRC/openrc/blob/master/src/rc/rc.c#L502 2017-06-13 13:20:42 clandmeter: to answer your possible next question, /etc/inittab is where the definition to run `/sbin/openrc sysinit` is placed and it is used by init ;) 2017-06-13 13:21:00 przemoc, thanks! 2017-06-13 13:21:03 i found my issue 2017-06-13 13:38:17 sequedav: do you mean binary or library? libs have different SONAMEs, so automatic detection will set dependency to the one that was used during build. if you mean binary, then depending on /usr/bin/openssl could work (not sure, though, don't remember whether apk requires implicit or explicit provides to be able to satisfy such dep) 2017-06-13 13:42:55 sequedav: not really, we dont support the "or" operator in deps 2017-06-13 13:43:37 well in theory we could let both libressl and openssl package have a provides="/usr/bin/openssl" 2017-06-13 13:43:54 and let one of them have priority 2017-06-13 13:44:07 so apk knows which to pick if none are currently installed 2017-06-13 13:44:16 but, no, we dotn really support it atm 2017-06-13 13:45:54 ncopa: ok, so it needs to be explicit atm. the question is whether new apk and new packages shouldn't provide binaries automatically, somewhat like it is done with libraries? 2017-06-13 13:46:38 possibly 2017-06-13 13:46:49 so you coudl do: apk add /usr/sbin/sendmail 2017-06-13 13:47:01 exactly 2017-06-13 13:47:22 im afraid of making the db too big 2017-06-13 13:47:51 but yeah, it is possible 2017-06-13 13:48:33 maybe it wouldn't need additional provide entries and apk could simply scan .apk content searching for file if pkgname starts with / 2017-06-13 14:02:16 we dont have the full file list in the apkindex 2017-06-13 14:13:27 im looking at osinfo and the osinfo-ddb 2017-06-13 14:13:31 osinfo-db 2017-06-13 14:13:47 so virt-manager can autodetect alpine linux iso images 2017-06-13 14:14:14 lookst like most other distros set the -sysid to "LINUX" 2017-06-13 14:14:17 and we dont 2017-06-13 14:17:07 przemoc, ncopa: thanks for your help, that answers my question. The package is a library actually, but it looks it was linked against openssl when it was built. Thanks guys 2017-06-13 14:30:01 awilfox: you don't choose a documentation format according to the tools you have, you choose a documentation format according to what you want to type and then, if needed, you build the tools. The tools serve you, not the other way around. 2017-06-13 14:30:41 One thing I'm pretty sure of is I'm never going to contribute a line of documentation if I have to write it in nroff. I can't be the only one. 2017-06-13 16:05:06 <^ingo^^^> i try to build an packages where the configure script only works with bash. Is it somehow possible to switch only in the APKBUILD for the build-step to bash? 2017-06-13 16:07:11 call "bash ./configure" 2017-06-13 16:07:21 and add bash to your makedepends 2017-06-13 16:15:27 <^ingo^^^> that works. Now next error :( pdns-recursor-4.0.4 works 4.0.5 gives errors. Thanks, will try to find a solution. 2017-06-13 16:24:50 <^ingo^^^> doesn't work, configure runs, but the makefiles are not correct :( if load bash and then execute the abuild -r it works. So is will switch on my build-system the default-shell to bash 2017-06-13 16:25:24 what do you mean the makefiles are not correct? 2017-06-13 16:25:50 awilfox: don't use groff, use mdoc 2017-06-13 16:25:58 try adding "export SHELL=/bin/bash" before your configure invocation 2017-06-13 16:26:41 <^ingo^^^> if the make starts i get "../../../libtool: line 1654: preserve_args+= --silent: not found" and so on. looks like some environment is missing 2017-06-13 16:27:01 try with the SHELL line 2017-06-13 16:35:37 <^ingo^^^> this works. bash in the makedepends, in the build block the export SHELL. Package build. 2017-06-13 16:35:48 grats :) 2017-06-13 17:27:03 ^ingo^^^: most configure scripts will use bash if its available, so its normally enough to add it to makedepends 2017-06-13 17:37:19 noticed lots of iot white papers/thesis this year, al seems quite ready for it 2017-06-13 17:37:31 http://i.imgur.com/rQtIKXL.png <- protocols 2017-06-13 17:38:17 if someone has tested testing/libcoap for being full coap implementation, maybe move to main/ 2017-06-13 17:38:53 I think new iot thesis writers may find AL useful 2017-06-13 18:49:50 kaniini: I've read in the logs, that you've upgraded firefox to testing/firefox 53.0.3-r0. Could you also do that for armhf? 2017-06-13 18:50:26 (because of the same dependency error here: https://bugs.alpinelinux.org/issues/7409 ) 2017-06-13 19:13:10 ollieparanoid: arm builder is presently blocked on webkit2 2017-06-13 19:13:17 we are working on it 2017-06-13 19:14:35 kaniini: okay, thanks! 2017-06-13 23:03:10 kaniini: yes, I am using mdoc. I still use groff (the executable) to preview. 2017-06-13 23:07:01 ok 2017-06-13 23:07:14 hello 2017-06-13 23:07:20 whatd i miss in the past 7 or so days 2017-06-13 23:07:41 drugs 2017-06-13 23:07:47 a lack of sex 2017-06-13 23:07:51 and linux distributions 2017-06-13 23:10:36 a lack of linux distributions is never a thing 2017-06-14 07:17:35 ollieparanoid[m]: firefox-53.0.3-r0 won't build until there is a rust package for armhf, see https://github.com/alpinelinux/aports/pull/1578#discussion_r119988654 2017-06-14 07:36:28 isn't the rust stuff optional? or not any more? 2017-06-14 07:36:50 awilfox, i think not anymore. i saw firefox started requiring rust in latest versions 2017-06-14 07:37:08 ah, that's a bummer 2017-06-14 07:42:29 it still could be disabled in 53 but will not be possible in 54 2017-06-14 07:43:10 what are they doing with rust? 2017-06-14 07:45:10 https://wiki.mozilla.org/Oxidation 2017-06-14 07:46:01 oh, does not affect ESR 2017-06-14 07:46:06 that is fine then :) 2017-06-14 07:46:13 gives me a while to care at least... 2017-06-14 08:43:19 ncopa: did you see my reply regarding the mkinitfs cryptdiscards patch? 2017-06-14 09:05:20 hello, how can i trace the abuild error? 2017-06-14 09:05:56 it just say >>> ERROR: rust: all failed 2017-06-14 09:27:01 really silly question: where does the bootstrap script live? for instance for a new architecture? want to get my paws dirty with ppc32 :) 2017-06-14 09:30:40 aports/scripts? 2017-06-14 09:33:57 i just typed "build -r" in aports/community/rust/ the error appeal 2017-06-14 09:35:14 i guess you mean abuild -r? 2017-06-14 09:35:34 yeah!!! my fault. 2017-06-14 09:36:34 abuild is a shell script, run it with -x and see what happens. 2017-06-14 09:37:13 I actually wrote small patch to add -v to abuild 2017-06-14 09:37:23 i will give it a try. thx 2017-06-14 09:37:33 for just this, since I see it so much here 2017-06-14 09:37:44 alpine: its a shell arguement not an abuild argument :) 2017-06-14 09:38:19 awilfox, yes sound good. 2017-06-14 09:41:44 how to trans the shell paramter though to let the debug work? 2017-06-14 09:42:56 sh -x /usr/bin/abuild -r 2017-06-14 09:45:47 there are some message like "Package not available for the target architecture (x86). Aborting" . it rust not run x86? 2017-06-14 09:46:22 arch="x86_64" 2017-06-14 09:46:39 and yes, that ERROR is a bug 2017-06-14 09:46:55 it should not display an Error when arch is not available 2017-06-14 09:47:35 nmeum: nope, not yet 2017-06-14 13:59:42 hi, has anyone come of any new idea of replacing ntp servers with simpler "cryptographically signed" coap based atomic clock devices ? 2017-06-14 14:00:05 eg. coap based atomic clock devices 2017-06-14 14:01:46 an simple server could possible handle lots more request and possible solve bitcoin's timestamp based issues 2017-06-14 14:04:45 rfc5905/5906 seems quite complicated 2017-06-14 14:05:06 just to tell a timestamp 2017-06-14 14:47:24 ncopa, would planet.alpinelinux.org be a good idea ? 2017-06-14 14:47:24 I think I have few articles already :) 2017-06-14 14:47:24 planet.a.o would subcribe rss from a respective site and republish them, thereby giving it wider reader base 2017-06-14 14:55:06 I think 1st would relacing NTP 2017-06-14 15:01:17 vkrishn: yes i think plant.a.o is a good idea 2017-06-14 15:02:58 nice, I am onto my articles and redesigning my site, pls post here as how to get my site included 2017-06-14 15:03:06 I watch the logs 2017-06-14 15:03:35 thanks 2017-06-14 15:28:47 That does not sound in any way simpler 2017-06-14 15:30:33 ashb, are you refering to NTP(alt) ? 2017-06-14 15:30:46 > with simpler "cryptographically signed" coap based atomic clock devices 2017-06-14 15:30:52 That doesn't sound simpler to me 2017-06-14 15:32:31 is signing a text/msg using gpg(app) with private key complicated ? 2017-06-14 15:33:35 coap based atomic clock devices is 2017-06-14 15:34:38 well atomic-clock presently may be be easy reach for masses, but plently of universities and govt orgs can afford it 2017-06-14 15:34:45 may not be* 2017-06-14 15:35:21 its a matter of bringing 2 devices together 2017-06-14 15:36:09 having them controlled by reliable orgs make it a bit better 2017-06-14 15:42:21 let me cook my article first, I think its would be quite feasible/useful 2017-06-14 15:43:34 and "atomic clock" is not something that is hard-coded, its implies a time-telling device that is less tamperable 2017-06-14 15:45:35 "It's just a matter of getting two giant orgs to co-operate with each other" Let me know how you get on with that ;) 2017-06-14 15:48:24 atomi-clock+coap is tightest factor, if and org can guarantee its time keep/telling device is close to atomic version, it would do 2017-06-14 15:48:48 so would replacing coap with MQTT, or even any UDP or TCP/IP 2017-06-14 15:49:53 TCP/IP would just make it a bit prone to congestion and likely DoS 2017-06-14 15:52:20 not to mention MITMx 2017-06-14 16:04:50 https://en.wikipedia.org/wiki/Network_Time_Protocol#Security_concerns (see Stratum 0) 2017-06-14 16:09:28 NTP has multiple problems, but MITM isn't one of them - or at least, it has nothing to do with the protocol itself. 2017-06-14 16:09:45 You want to secure a connection? slap TLS on it. No matter what it is. 2017-06-14 16:10:11 Of course, datagram protocols don't help. DTLS isn't as widespread as TLS. But it still exists. 2017-06-14 16:10:58 Or you could simply encrypt and sign every packet. That's not hard, and for time packets, it wouldn't even be CPU-consuming. 2017-06-14 16:11:54 in short: don't overengineer solutions to solved problems. 2017-06-14 16:12:13 there are enough unsolved problems that need your brain power as is. 2017-06-14 16:14:55 so replacing NTP with lighter/better solution is a no..no ? 2017-06-14 16:18:50 that's not what I'm saying. 2017-06-14 16:18:58 was reading the original bitcoin.pdf and watched, 2017-06-14 16:18:59 https://www.youtube.com/watch?v=Lx9zgZCMqXE 2017-06-14 16:18:59 that sent me looking for the "Timestamp Server" related issue 2017-06-14 16:19:53 what I'm saying is, if you're going to make an analysis of the virtues and flaws of NTP, do it right, isolating what can be solved via a TLS layer and what cannot. 2017-06-14 16:20:20 https://bitcoin.org/bitcoin.pdf 2017-06-14 16:21:04 and if you're looking for something simpler than NTP with less failure cases, look no more: https://skarnet.org/software/s6-networking/s6-taiclock.html 2017-06-14 16:22:10 ;) 2017-06-14 16:30:42 skarnet, if s6 stack is not getting in AL main/ may try at ALs Spin Adelie 2017-06-14 16:30:55 maybe try* 2017-06-14 16:31:33 I would suggest meta-pkg s6-bundle.apk 2017-06-14 16:31:34 Adélie is an independent project, not an AL spin, even if it ends up using AL as upstream 2017-06-14 16:32:21 oh, I misread new maifesto , checking again 2017-06-14 16:34:53 so better term would be "AL based" 2017-06-14 16:35:18 'As such, we are considering rebasing our distribution on Alpine Linux.' 2017-06-14 16:54:17 clandmeter, could you pls post a short note on how to do a setup like https://docs.alpinelinux.org/Home ? 2017-06-14 16:54:32 I think I may use it for my articles site 2017-06-14 16:54:49 for I know its ruby based 2017-06-14 16:54:58 or not ;) 2017-06-14 16:56:07 gollum gem 2017-06-14 17:04:25 khanku: thanks for the hint! 2017-06-14 18:04:37 I think bluray should either get replaced or prices downed (mass production) 2017-06-14 18:04:37 looks more like patents and DRM issue 2017-06-14 18:04:38 long data storage (cold) is becoming an issue 2017-06-14 18:05:10 iirc, bluray disc capicity can grow, in TBs 2017-06-14 18:07:06 oops. wrong channel 2017-06-14 19:03:22 https://github.com/kaniini/gcompat is planned to replace libc6-compat 2017-06-14 21:34:34 kaniini. nice 2017-06-14 21:35:55 so now we can really make use of nonfree? 2017-06-14 21:37:15 well it probably won't be perfect 2017-06-14 21:37:17 but it's a start 2017-06-14 21:37:28 notably some semantic changes in musl can probably not be fantastically emulated 2017-06-14 21:43:31 clandmeter: it depends on the non-free software 2017-06-14 21:43:47 i would not expect to be running oracle on alpine any time soon 2017-06-14 21:44:04 what about nvidia? 2017-06-14 21:44:11 maybe 2017-06-14 21:44:23 but you shouldn't buy nvidia anyway 2017-06-14 21:45:13 is AMD any better nowadays? 2017-06-14 21:46:04 mesa seems to have good coverage for me 2017-06-14 21:46:21 i have no idea, but i think the most requests have been coming from the nvidia camp. 2017-06-14 21:46:56 right now the scope of gcompat is "make proprietary raid management software work" 2017-06-14 21:48:27 clandmeter: welp, nouveau sucks and it's not their fault, properiarty drivers aren't better I think 2017-06-14 21:48:55 didn't use anything than intel for years though 2017-06-14 21:53:12 yep me too 2017-06-14 21:54:10 well my xps has nvidia i think but i never used it so i dont care. 2017-06-14 21:54:45 is it possible to disable nvidia graphics, so it won't suck the battery? 2017-06-14 21:55:50 and since we are here, is Alpine trying to be more desktop-friendly? I asked on -offtopic what are the current goals and target for Alpine, but well, it's offtopic 2017-06-14 21:56:20 im using windows 10 on it, So i have to specifically select/use it. 2017-06-14 21:56:25 there are no goals 2017-06-14 21:56:28 there is no target 2017-06-14 21:57:02 well 2017-06-14 21:57:07 there are guidelines to strive by 2017-06-14 21:57:09 how you can design and build anything without specified requirements and expected results? 2017-06-14 21:57:12 only making my damn raid card work 2017-06-14 21:57:19 oh, kaniini's talking about gcompat now 2017-06-14 21:57:35 which it is doing 2017-06-14 21:57:43 scadu: it's something i personally am not against, but it has to not compromise the main goals of alpine 2017-06-14 21:57:59 e.g. if making a desktop friendly setup requires packaging systemd, it's unlikely to go through 2017-06-14 21:58:01 :p 2017-06-14 21:58:15 the main goals of alpine are to provide a base system that can be very small 2017-06-14 21:58:18 that's pretty much it 2017-06-14 21:58:19 small, simple, secure should apply to desktops as well 2017-06-14 21:58:23 yes, there's -hardened 2017-06-14 21:58:29 but lets be real 2017-06-14 21:58:34 that shit is dead now that grsec is dead ;) 2017-06-14 21:58:39 i disagree 2017-06-14 21:58:46 discussion for another time, though 2017-06-14 21:59:06 when some kid ships something that isn't a script kiddie hackjob i might care 2017-06-14 21:59:10 what? grsec is dead? did i miss something? 2017-06-14 21:59:25 oh, sorry, i should clarify 2017-06-14 21:59:34 grsec, if you are not a corporation paying $$$$$$, is dead 2017-06-14 21:59:49 spender took his ball and went home 2017-06-14 21:59:57 as did the PaX team, whoever the fuck that is ;) 2017-06-14 21:59:59 i can donate 10 euro, where is alpine's paypal account? 2017-06-14 22:00:04 i'll just say two things 2017-06-14 22:00:13 1) i think strcat is more competent than made out to be 2017-06-14 22:00:24 spender doesn't seem to think so 2017-06-14 22:00:25 2) -hardened is not the entire security story of alpine, as you have stated yourself before :p 2017-06-14 22:00:31 spender thinks a lot of things 2017-06-14 22:00:35 does it matter what he thinks 2017-06-14 22:00:41 spender also throws lots of tantrums 2017-06-14 22:00:42 so who knows 2017-06-14 22:01:06 spender's mostly mad that he things strcat betrayed him by starting linux-hardened 2017-06-14 22:01:14 and working with people spender doesn't like 2017-06-14 22:01:25 seems like he kind of set himself up for all of this though 2017-06-14 22:01:49 like, what did he think was going to happen? 2017-06-14 22:02:27 personally i am just glad that i don't look at #alpine-linux anymore and half the time see a grsecurity advertisement 2017-06-14 22:02:43 if those people can remain gone, that would be quite lovely. 2017-06-14 22:03:22 scadu: in terms of actual goals for 3.7 2017-06-14 22:03:29 it's really too early to say 2017-06-14 22:03:44 because on fronts like -hardened 2017-06-14 22:03:51 we need to see how some things play out 2017-06-14 22:04:16 but realistically 3.7 is probably going to be pretty boring 2017-06-14 22:04:34 for me personally what i am working on is essentially 2017-06-14 22:05:19 gcompat, cavium octeon support, refactoring the way kernels are packaged to make it easier to provide the same modules for all kernel flavours 2017-06-14 22:05:37 and some of the components for apk3 2017-06-14 22:05:48 i guess shiz is working on -hardened 2017-06-14 22:06:22 and clang/CFI testing 2017-06-14 22:06:27 3.7 will hopefully/likely include the possibility to switch system ompilers 2017-06-14 22:06:34 even though it will still be compiled with gcc 2017-06-14 22:06:40 kaniini: it's not only about the next release, but the whole project direction. 2017-06-14 22:07:10 scadu: the direction at this point is to provide a mature, stable, base system that can be used for any purpose 2017-06-14 22:07:48 and secure 2017-06-14 22:07:50 :p 2017-06-14 22:07:51 the point is that specialized derivatives like adelie, postmarketOS, etc should really become more exciting for end users 2017-06-14 22:08:09 alpine is about plumbing 2017-06-14 22:09:06 and yes, of course, reasonably secure 2017-06-14 22:09:31 shame that many useful things are available only on edge, while not be suitable if you require something you could call stability 2017-06-14 22:09:38 more projects are starting to support musl, so i guess you will see more desktop related activity. 2017-06-14 22:09:53 but still the kernel issue remains 2017-06-14 22:09:57 scadu: that's not really true 2017-06-14 22:10:15 the only stuff only available on edge is testing repo 2017-06-14 22:10:23 and stuff isn't really supposed to just remain there 2017-06-14 22:10:43 that happen unfortunately 2017-06-14 22:10:57 i know it does, and we are trying to solve that too 2017-06-14 22:11:27 if you depend on things in testing, you should request it to move moved. 2017-06-14 22:11:44 be moved... 2017-06-14 22:11:53 exactly 2017-06-14 22:11:56 that is the point 2017-06-14 22:12:03 but that's a docs issue 2017-06-14 22:12:14 and clandmeter seems to be working on improving that :) 2017-06-14 22:12:40 but from an operational perspective 2017-06-14 22:12:42 what about the kernel? I would really use Alpine as my main system, but wiping modules for currently running kernel might be painful. in case when it fails to install modules to the new kernel it's even worse 2017-06-14 22:12:44 well, i made a small start. no i need input from others. 2017-06-14 22:12:48 we are trying to onboard more contributors 2017-06-14 22:12:55 grrr now... 2017-06-14 22:13:00 and have them become full developers 2017-06-14 22:13:06 which should help 2017-06-14 22:13:20 as for making kernel upgrades safe 2017-06-14 22:13:27 that is something we are looking at for 3.7 2017-06-14 22:13:40 kaniini: what's the plan? 2017-06-14 22:13:52 Temptor did some work, but it's gone now 2017-06-14 22:14:07 how do i say his work was very bad nicely 2017-06-14 22:15:06 didn't look into internals, since I have no enough knowledge to do a review or sth 2017-06-14 22:15:17 however, top level summary: linux-hardened-4.9 instead of linux-hardened, older packages get retained for some time and garbage collected 2017-06-14 22:15:41 so if you have a broken 4.9 kernel and you want to go back to 4.4 2017-06-14 22:15:43 you just select it in the menu 2017-06-14 22:16:21 I hope it would be possible also during 4.9.x -> 4.9.x+1 upgrade 2017-06-14 22:16:37 yes, obviously. 2017-06-14 22:17:03 I mean it's not that bad if it's your shitty notebook and you can chroot (but still painful) 2017-06-14 22:17:17 worst scenario if it's the server 2017-06-14 22:17:30 and chroot is not the option :f 2017-06-14 22:17:55 livepatching is also something i want to look into 2017-06-14 22:18:01 but that will probably be 3.8 2017-06-14 22:18:12 livepatching is something i'd disable immediately 2017-06-14 22:18:13 (we are already testing something @ dayjob) 2017-06-14 22:18:19 never trust ring3 -> ring0 codeexec 2017-06-14 22:18:38 Shiz: it would be opt-in 2017-06-14 22:18:49 how it works right now is basically 2017-06-14 22:18:54 apk add kpatch 2017-06-14 22:18:56 if we also plan do introduce a/b upgrades then it would be just fucking cool and I immediately install Alpine on my laptop ;f 2017-06-14 22:19:02 to get the patches :P 2017-06-14 22:19:40 i'm not a big fan of a/b upgrades personally 2017-06-14 22:19:50 me neither 2017-06-14 22:20:03 but apk is getting rollback 2017-06-14 22:20:06 to undo the previous transaction 2017-06-14 22:20:30 fair enough 2017-06-14 22:20:40 which may be close enough use case 2017-06-14 22:20:55 yup 2017-06-14 22:21:01 oh 2017-06-14 22:21:10 also 3.7 will officially support NVIDIA drivers 2017-06-14 22:21:12 ha ha just kidding 2017-06-14 22:21:19 lol 2017-06-14 22:21:25 I don't give a damn about this :P 2017-06-14 22:21:29 i do not even have any nvidia hardware 2017-06-14 22:21:31 to test with 2017-06-14 22:21:41 and no i dont want any 2017-06-14 22:21:45 i can send you some :p 2017-06-14 22:21:59 such a shame, SteamOS cannot use Alpine as a base! 2017-06-14 22:22:01 :C 2017-06-14 22:24:09 ironically 2017-06-14 22:24:19 steam does work with gcompat with alpine i386 2017-06-14 22:24:35 lul 2017-06-14 22:24:42 didn't know that 2017-06-14 22:24:54 no guarantees on the games themselves 2017-06-14 22:25:03 also, we are not going to drop i383 support soon, are we? 2017-06-14 22:25:16 o 2017-06-14 22:25:19 we already dropped it 2017-06-14 22:25:24 in 2014 2017-06-14 22:25:32 technically you need 486 to run alpine 2017-06-14 22:25:40 586 2017-06-14 22:25:42 actually 2017-06-14 22:25:44 :p 2017-06-14 22:25:55 oh we finally jumped to 586 2017-06-14 22:26:03 hm, I wonder when I ran Alpine on Transmeta Crusoe 2017-06-14 22:26:34 kaniini: fun fact: it may need to be bumped to 686 for clang 2017-06-14 22:26:38 or worse 2017-06-14 22:26:44 since clang assumes -march=pentium4 by default 2017-06-14 22:26:46 (don't ask me why) 2017-06-14 22:27:08 oops, Trasmeta might not work then :c 2017-06-14 22:27:22 although we can probably just patch clang to be less silly 2017-06-14 22:27:24 as we do 2017-06-14 22:27:33 this shit has some i586 support 2017-06-14 22:27:45 crusoe supports i686 2017-06-14 22:31:08 woohoo 2017-06-14 22:31:41 I'm suprised 2017-06-14 22:49:43 Shiz: i've just been chilling on x86_64 for years with 4GB address space limits 2017-06-14 22:49:44 ;) 2017-06-14 22:51:06 scadu: i mean the ultimate goal of alpine is gnome 3 on your toaster 2017-06-14 22:55:56 kaniini: I'm happy with TTY on my toaster :> 2017-06-14 22:56:39 or dvtm 2017-06-14 22:57:11 I'm afraid that gnome 3 won't run on crusoe :c 2017-06-15 07:10:21 it would be really nice if there was some way that !strip auto-enabled -dbg, or that you could globally enable -dbg, and if there were no files it would just silently go away, because right now this is not a fun night 2017-06-15 07:10:57 adelie by design needs *-dbg wherever they can be built, and I'm having to modify every APKBUILD file in aports to add -dbg where appropriate :/ 2017-06-15 07:11:56 I had found a way to make abuild just add it to everything, but then it got very unhappy on packages that have no debug information (like perl/python type) 2017-06-15 09:11:44 <^ingo^^^> once more. I try build the postfix package with lmdb-support. build works. But for the postfix-lmdb package the Tracing dependencies step doesn't include the lmdb-lib. Looks like the step scanning shared objects doesn't work here. Other subpackages are ok. Must i here set the dependency manually? 2017-06-15 09:40:53 ^ingo^^^: it is supposed to be detected automatically 2017-06-15 09:41:19 could it be that the lmdb module links to static lmdb? 2017-06-15 09:42:10 <^ingo^^^> from the size i would say no. get also an error "/usr/lib/postfix/postfix-lmdb.so: mdb_cursor_open: symbol not found" 2017-06-15 09:42:54 <^ingo^^^> even after install lmdb. so i think i must dive here deeper 2017-06-15 09:50:11 readelf -d /usr/lib/postfix/postfix-lmdb.so 2017-06-15 10:10:29 <^ingo^^^> readelf -d postfix-lmdb.so 2017-06-15 10:10:29 <^ingo^^^> Dynamic section at offset 0x3c70 contains 17 entries: 2017-06-15 10:10:29 <^ingo^^^> 0x0000000000000001 (NEEDED) Shared library: [libc.musl-x86_64.so.1] 2017-06-15 10:10:29 <^ingo^^^> Tag Type Name/Value 2017-06-15 10:10:29 <^ingo^^^> 0x000000000000001d (RUNPATH) Library runpath: [/usr/lib/postfix] 2017-06-15 10:14:13 <^ingo^^^> ok, found it. missing AUXLIBS_LMDB in make call. Now the dependency is here. 2017-06-15 10:28:25 hi people 2017-06-15 11:48:47 im trying to clean up the perl package 2017-06-15 11:48:49 sigh 2017-06-15 11:49:14 vakartel: why was Encoding moved to dev? 2017-06-15 11:49:22 i dont think it beolngs there 2017-06-15 11:49:29 and cpan is in perl-utils 2017-06-15 11:50:58 and perl-dev should have h2xs 2017-06-15 11:52:32 this is a big mess :-( 2017-06-15 11:56:26 how it got merged then? 2017-06-15 14:03:02 As I remember, this PR was reverted 2017-06-15 14:03:43 or not? 2017-06-15 14:04:20 where do qemu stand in terms or eg. http://www.osnews.com/story/29865/Intel_aggressively_reminds_everyone_it_owns_all_the_x86_patents ? 2017-06-15 14:08:12 probably in the "they don't make enough money to sue" category 2017-06-15 14:11:09 though interestingly, this isn't the first time ms had jit like x86 to another arch situation https://en.wikipedia.org/wiki/FX!32 2017-06-15 14:14:33 I read that as "emulation on CPU" not "emulation in software" 2017-06-15 14:14:37 so qemu not affected 2017-06-15 14:32:39 vakartel: was partially reverted 2017-06-15 14:33:17 hmpf, those "modernize" commits makes it more timeconsuming to backport fixes 2017-06-15 14:49:49 what would be an example of "emulation on CPU" 2017-06-15 14:49:56 and "emulation in software" 2017-06-15 14:57:24 I doubt any kinda of emulation not resulting in product intented by original patent holder is an issue 2017-06-15 15:07:51 Anyone around? I mentioned on a feature request a while ago that I was keen to see an ability to get wine-like / mingw capabilities in Alpine, and that my company might be able to sponsor its development 2017-06-15 15:08:56 The specific aim would be to satisfy this feature request: https://bugs.alpinelinux.org/issues/5011 2017-06-15 15:17:37 Shiz any idea what #7274 is about? 2017-06-15 15:42:00 Kruge: i think building a mingw cross toolchain package should be possible 2017-06-15 15:47:01 This would make my life significantly more rosy 2017-06-15 15:49:10 What would be the best way to make my dreams come true? 2017-06-15 16:54:24 is it just me or is the newest version of ttf-dejavu broken? Some characters rendered with a sans font look broken in Firefox, e.g. € 2017-06-15 17:02:50 when did gitlab change their syntax highlighting? 2017-06-15 17:05:57 s/lab/hub/ 2017-06-15 18:46:36 https://github.com/portown/alpine-mingw-w64/blob/master/Dockerfile 2017-06-15 18:46:41 Does that look like it might be of any use? 2017-06-15 18:47:40 mostly, not really to be honest :P 2017-06-15 18:47:52 Bah 2017-06-15 18:47:54 we do already know how to bootstrap gcc luckily, and even do a cross bootstrap 2017-06-15 18:48:01 it's just a matter of fitting in the mingw pieces 2017-06-15 18:49:17 and making it fit for alpine distro purposes 2017-06-15 18:50:16 A big job? 2017-06-15 18:50:28 Or is that not something you'd know until you started on it? 2017-06-15 18:50:34 sorta a big job 2017-06-15 18:50:55 i think i'd have to talk to kaniini on how to do cross-gcc when not in bootstrap.sh 2017-06-15 18:53:01 of note is that if your company is willing to sponsor it as you noted we/i can afford to spend more time on it 2017-06-15 18:53:03 :p 2017-06-15 18:53:29 It would make my YEAR to have this + fcolista's openvas-smb packages 2017-06-15 18:54:15 And, depending on whether we're talking silly levels of sponsorship or not, I think we could make it happen 2017-06-15 18:55:04 the major issue is that bootstrapping a cross compiler is a complex interplay of various packages, which we can make work in stuff like bootstrap.sh which is just a sequential script to bootstrap a new platform 2017-06-15 18:55:19 but actually making it work just using APKBUILDs, as normal packages would, is a bit harder 2017-06-15 18:55:34 to give some background on the major issue here 2017-06-15 18:56:02 hmm 2017-06-15 18:56:07 I think I understand 2017-06-15 18:56:36 it also depends on how deeply we want to intertwine the packages though 2017-06-15 18:57:10 if the other devs are fine with having a mingw-w64-binutils, and all the other mingw-w64 components generated by a single APKBUILD, that could *probably* work 2017-06-15 18:57:20 but it's a matter of how clean we want the bootstrap to be 2017-06-15 19:06:18 alternatively, your company could sponsor midipix, and then you could run a whole Alpine system under Windows :D 2017-06-15 19:08:28 I sense one of these jobs might be bigger than the other 2017-06-15 19:10:52 I'm not sure exactly where midipix is at, but I think it's not that far from completion: http://midipix.org/ 2017-06-15 19:11:50 of course it's still likely that adding a mingw target to gcc is easier, but I wouldn't swear it without further study 2017-06-15 19:12:11 midipix has been not far from completion for two years 2017-06-15 19:12:17 i'm not particularly counting on anything at this point 2017-06-15 19:12:19 : 2017-06-15 19:12:21 p 2017-06-15 19:12:34 that's exactly where a sponsorship can come in handy 2017-06-15 19:13:37 the same way as, example chosen totally at random, s6 is *almost* ready to be integrated into a distribution, and a sponsorship would definitely help it cross the last stages 2017-06-15 19:31:18 Kruge: we need multiarch before we can do mingw in any realistically useful way 2017-06-15 20:37:19 hold on to your hats. here comes perl 5.26 2017-06-15 20:37:38 <_ikke_> ACTION grabs 2017-06-15 20:50:59 had this been #gentoo I'd be worried 2017-06-15 20:51:53 it was, in fact, a perl update that finally made me ditch the damn distro 2017-06-15 21:01:09 perl-cleaner 2017-06-15 21:03:54 ugly kludge that shouldn't be, worked less than half the time, etc 2017-06-15 21:12:08 :-S 2017-06-15 21:44:27 perl 5.26 is a thing??? lol 2017-06-16 06:13:03 morning all 2017-06-16 06:13:34 good morning fellow climbers 2017-06-16 06:13:37 <_ikke_> morning 2017-06-16 06:14:24 hello there =) 2017-06-16 06:16:08 awilfox, how is your transition going? 2017-06-16 06:16:15 not sure if my question came through last night: what kind of work would I need to do to make abuild automatically figure out if -dbg was appropriate (basically, if !strip is in options and it generates debug info) and not error if it isn't? my goal is to generate -dbg packages for everything already in aports that I build.. options="!strip" exported in /etc/abuild.conf works well enough but without a 2017-06-16 06:16:17 -dbg in packages that need it, the binary size balloons :/ 2017-06-16 06:19:31 awilfox, i guess you will have to add a global abuild option to optin for always -dbg and add a option to add !dbg to disable it per pkg. 2017-06-16 06:19:45 clandmeter: fairly well. still trying to understand all the ins and outs of abuild, but it's a learning process. my main sticking point right now is the above question. we (as in Adelie) always ship -dbg packages, it has helped a lot finding hard-to-debug issues with musl 2017-06-16 06:26:31 awilfox, what we currently do is if we run into trouble we just enable dbg, debug whats wrong and leave it enabled afterwards. 2017-06-16 06:29:27 clandmeter: that makes it a lot harder :/ but I guess I can investigate that 2017-06-16 06:31:07 enabling dbg by default would increase repo size significantly 2017-06-16 06:32:50 clandmeter: yeah, I'm not asking alpine to do it; our infrastructure is already built to handle that size 2017-06-16 06:33:06 clandmeter: and yes, dbg is about 70% of the size of our repository 2017-06-16 06:34:25 there goes the small in our 3s :) 2017-06-16 06:45:28 clandmeter: we have 3 Rs, and -dbg goes to further the second: reliable. but yeah like I said I don't think alpine should do this. I just wondered if it would be possible without herculean effort for adelie to do. 2017-06-16 06:47:23 morning 2017-06-16 06:47:36 i think it should be easy to add to abuild, an optin to add dbg automagically to subpackages. 2017-06-16 06:47:41 awilfox: i like your idea of enabling -dbg globally 2017-06-16 06:48:13 and i dont think it will be that difficult to implement 2017-06-16 06:52:53 i'd like to say that there is one hurdle to that right now 2017-06-16 06:53:02 .a files not being stripped 2017-06-16 06:53:17 leading to ginormous static libs for e.g. clang 2017-06-16 06:53:34 but for -dbg we dont want things stripped, do we? 2017-06-16 06:55:09 hmm. dunno how to handle -dbg + -dev... 2017-06-16 06:55:25 ncopa: I think Shiz is saying that the .a files in -dev won't be stripped either 2017-06-16 06:55:29 ncopa: stripped OR split 2017-06-16 06:55:37 so -dev will balloon too 2017-06-16 06:56:01 we really didn't ship static libs in adelie, so that wasn't a consideration for me; that is going to be something I need to think on harder. don't necessarily think -dev-dbg would be a good idea haha 2017-06-16 06:56:33 yeah, -dev-dbg is questionable 2017-06-16 06:56:57 the .a files could be stripped and put in -dbg.. it would be unnecessary size bloat if you don't have -dev installed, but -dbg is already huge, and it would mean -dev shouldn't increase any 2017-06-16 06:57:43 or the .a files could be stripped unconditionally, but then that makes debugging harder 2017-06-16 07:14:43 i've got no major issues with -dbg containing -dev stuff 2017-06-16 07:26:53 my other concern is that often whn software is compiled with symbols enabled the build system interprets it as 'debug mode' and does other wacky stuff like -O0 or enabling debug code paths 2017-06-16 07:27:09 cmake has RelWithDbgInfo for this, but other build systems don't seem to 2017-06-16 07:28:59 RelWithDebInfo* 2017-06-16 07:34:51 thats a bigger issue 2017-06-16 07:35:13 we dont want compile in debug mode 2017-06-16 07:35:16 which build systems are you thinking of? with autoconf systems you can just specify -ggdb or -g in CFLAGS and it doesn't know 2017-06-16 07:35:19 we just want keep the symbols 2017-06-16 07:35:38 i know nginx has different debug build 2017-06-16 07:35:59 but i dont think its enabled automatically with you add -g CFLAG 2017-06-16 07:36:14 awilfox: mostly non-auto* non-cmake ones 2017-06-16 07:36:17 which still exist a fair amount 2017-06-16 07:36:19 :p 2017-06-16 07:37:05 Shiz: the only one I can think of is jam, the one boost uses. oh wait, meson? do people use that yet? I know openrc was considering it 2017-06-16 07:37:23 ffmpeg 2017-06-16 07:37:25 musl 2017-06-16 07:37:28 busybox 2017-06-16 07:37:32 all use custom build systems 2017-06-16 07:37:56 musl is just a Makefile and I don't think it has a debug build, does it? well, I mean, beyond the configure switch 2017-06-16 07:38:10 does busybox still use the kconf thing? 2017-06-16 07:38:52 (I am sorry if I am coming off wrong, I am just trying to understand the problem and gather more information to hopefully find a good solution) 2017-06-16 07:39:10 yeah busybox uses some Kconf-derived thing 2017-06-16 07:39:38 and yes that is true, but my issue is not necessarily the fact that custom build systems exist, but more that we have a significanta mount of packages with them 2017-06-16 07:39:44 and need to adapt every one of them 2017-06-16 07:39:46 :p 2017-06-16 07:41:45 Shiz: well that is why I am piloting it in an experimental tree :P 2017-06-16 07:44:24 also it seems -g -gz -fdebug-prefix-map=$srcdir=. would be nice debug flags 2017-06-16 07:44:31 regarding default dbg, any opinons regarding http://tpaste.us/QDal ? 2017-06-16 07:45:09 clandmeter: nifty, let me try it! 2017-06-16 07:46:06 clandmeter: nitpick: use subpackage_types_has "dbg" 2017-06-16 07:46:08 :p 2017-06-16 07:46:29 :) 2017-06-16 07:46:38 what about the naming of DEFAULT_DBG 2017-06-16 07:47:18 i would prefer DEFAULT_DEBUG as we also have DEBUG, i think 2017-06-16 07:48:13 but its not the same 2017-06-16 07:48:30 DEBUG doesnt generate a dbg pkg 2017-06-16 07:48:52 that why i named it differently 2017-06-16 07:49:33 and it matches the -dbg prefix 2017-06-16 07:49:49 i mean a separate dbg pkg. 2017-06-16 07:51:02 right, that's what I mean; DEFAULT_DBG matches -dbg 2017-06-16 07:51:09 although arch is a list, i guess it will never be mixed with noarch? 2017-06-16 07:51:11 not "-debug" 2017-06-16 07:52:19 it shouldn't be, no 2017-06-16 07:59:03 Shiz: http://tpaste.us/K69Y happy? ;-) 2017-06-16 07:59:25 i'm always happy 2017-06-16 07:59:26 :; 2017-06-16 08:00:38 ill remember that :p 2017-06-16 08:20:06 alternaitve naming for DEFAULT_DBG: AUTO_DBG 2017-06-16 08:22:34 wasn't sure if this would be helpful/desirable also: http://foxkit.us/linux/0001-abuild-Correctly-comment-default_dbg.patch 2017-06-16 08:32:03 i thought about auto_dbg but i liked default better, dunno why. I dont care about the naming so anything is good for me. 2017-06-16 08:32:04 yes 2017-06-16 08:48:03 Jsut saw that: "github-cli stopped working since GitHub abandonded v2 of its API." 2017-06-16 08:48:13 we have github-cli on community 2017-06-16 08:48:25 i think i need to remove this package then. 2017-06-16 08:48:50 we also have hub in testing, which is the official github cli client 2017-06-16 08:51:27 can github-cli interface with private github enterprise instances? 2017-06-16 08:51:46 not ones that are up-to-date AIUI 2017-06-16 09:01:27 Shiz, dunno actually 2017-06-16 09:01:48 I don't have a chance to test it 2017-06-16 09:01:52 but i believe not 2017-06-16 09:02:14 since gh enterprise instances i think uses newer API 2017-06-16 09:50:24 clandmeter: I owe you a drink of your choice! this patch is working fantastically. 2017-06-16 10:14:34 I always get an IO Error when upgrading perl-doc (ERROR: perl-doc-5.26.0-r0: IO ERROR) how do I debug/fix this? 2017-06-16 10:17:57 > gzip: stdin: invalid compressed data--crc error 2017-06-16 10:17:58 hm 2017-06-16 10:21:07 what mirror are yo uusing? 2017-06-16 10:23:30 ncopa: nl.alpinelinux.org 2017-06-16 10:24:00 and the x86_64 package 2017-06-16 10:26:03 # apk verify perl-doc-5.26.0-r0.apk 2017-06-16 10:26:03 perl-doc-5.26.0-r0.apk: -5 - FAILED 2017-06-16 10:26:46 lets see if we have more of those 2017-06-16 10:31:45 nmeum: try now 2017-06-16 11:00:25 ncopa: seems to work now. How did you fix it? 2017-06-16 11:03:06 removed the file and synced the mirror 2017-06-16 11:03:12 i think it may have issues with storage 2017-06-16 11:12:58 Yes that box needs to move 2017-06-16 11:13:47 On my to-do somewhere down the list... 2017-06-16 12:24:47 Shiz: ping 2017-06-16 12:24:54 bong 2017-06-16 12:26:16 I'd like to know the breakdown of your (this is a collective, but you sound representative enough) reluctance to s6, i.e. what I can fix and what I cannot 2017-06-16 12:26:46 if it's "I want a package that embeds policy and makes things turnkey as with openrc" then I can fix that 2017-06-16 12:27:18 if it's "it's djb-weird, users will never understand" then I cannot, and I also think the second part is wrong 2017-06-16 12:27:48 I want to know where I can put in work in order to make s6 more palatable for a distro 2017-06-16 12:28:20 and I *don't* want to put in work into this if you guys are just nodding heads to please me but it will really never happen 2017-06-16 12:28:59 i can elaborate on this more later, but it really comes mostly down to what we discussed at FOSDEM before in my opinion 2017-06-16 12:29:25 I want specs 2017-06-16 12:29:28 i don't want end-users to need to bother with servicedirs and whatever, they should just be able to use rc-service(8)/rc-update(8) (or equivalent) as they can now and start/stop/add services to boot 2017-06-16 12:29:49 hahaha "djb-weird", I love it ;-) 2017-06-16 12:30:15 i don't mind if things are unconventional (which i consider a lot of djb stuff) under the hood, though :P 2017-06-16 12:30:35 end-users don't have to bother with servicedirs any more than they have to bother with openrc scripts 2017-06-16 12:30:46 speaking as a user, being able to do "/etc/init.d/service start" is nice to have. 2017-06-16 12:31:29 my main/only concern is simply not making things harder on users who just want to start/stop/autostart services as suaul 2017-06-16 12:31:44 rfs613: because that's a habit you took, it's not the best way to proceed, but that's ok, compatibility can be achieved 2017-06-16 12:32:18 having some way to declaratively write service definitions like openrc would be nice too i guess, but :eh:, i honestly do't know enough about s6's current thing to say too much about it 2017-06-16 12:32:31 openrc is declarative my ass 2017-06-16 12:32:40 it's all shell and underhood magic 2017-06-16 12:32:53 It's pretty declarative 2017-06-16 12:32:55 skarnet: I settled on that because it works everywhere... well until systemd that is ;-) For a while I used the "service" command, but then it became "systemctl" with not quite same syntax, etc. 2017-06-16 12:33:08 systemd should also have service(8), no? 2017-06-16 12:33:39 anyway 2017-06-16 12:33:41 Shiz: it forwards to systemctl. 2017-06-16 12:33:51 rfs613: which is fine, as long as you can just use service(8) 2017-06-16 12:34:00 so, a compatibility shim would do? 2017-06-16 12:34:13 Shiz: yeah but it prints a nagging message each time which gets annoying (esp in scritps) 2017-06-16 12:34:37 fun 2017-06-16 12:34:52 skarnet: that would cover it, yes 2017-06-16 12:35:13 my second concern is how easy it would be for us as distro maintainers or others as contributors to write service scripts for s6-rc 2017-06-16 12:35:23 and... those are my two only concerns 2017-06-16 12:35:44 that second concern is not on me, you guys learned openrc, and some of you learned systemd unit files 2017-06-16 12:37:19 saying "we already put in some effort learning shitty formats, we don't want to put in more effort learning a smart one" is unfair 2017-06-16 12:37:33 Well 2017-06-16 12:37:42 It looks kinda complicated at first glance 2017-06-16 12:37:52 skarnet: that sounds very djb-ish BTW 2017-06-16 12:38:34 rfs613: hard to make the truth sound different tbh 2017-06-16 12:39:01 It takes 7 files to run a smtpd 2017-06-16 12:39:03 well, considering openrc format is not a shitty format at all for me, at the very least it's an opinion 2017-06-16 12:39:05 :p 2017-06-16 12:39:35 i don't care what you consider a smart format if i can't write it effectively, to be perfectly blunt 2017-06-16 12:39:38 It also takes 7 files to run a sshd 2017-06-16 12:39:48 it's not shitty from a UI perspective, but it is from the perspective of what it allows the system to do 2017-06-16 12:40:01 skarnet: shitty/better is always in the eye of the beholder. But I digress. This is really about: would the package maintaners be willing to learn a new sytax/format and converf their packages. 2017-06-16 12:40:21 im not against learning a new syntax/format at all 2017-06-16 12:40:25 but 2017-06-16 12:40:36 i would prefer it to not be a significant more pain in the ass to write than what we do currently 2017-06-16 12:40:38 :p 2017-06-16 12:40:43 Is there any reason for not putting all this one-variable-per-file in er... one file? 2017-06-16 12:40:44 rfs613: indeed, and my point is, I can't fix lazy. I can do some of the initial work (and that's planned) but I can't do all of the work on the long term. 2017-06-16 12:40:48 not saying that's the case for s6 as it is, since again i don't know enough 2017-06-16 12:41:06 but i am wary of the lots-of-files approach 2017-06-16 12:41:43 can you elaborate? 2017-06-16 12:42:03 is this because you can't see all the config on your screen at once? 2017-06-16 12:42:11 or something else? 2017-06-16 12:42:37 two components 2017-06-16 12:42:46 there's that, I prefer to have a single file that captures the service policy 2017-06-16 12:43:10 and since we usually would ship the service files ourselves, i don't want to add 5+ files to every abuild we add :p 2017-06-16 12:43:25 skarnet: lazy might not be the right word. When you want to switch something that causes work for others, there has to be a compelling reason (not just for you, but visible to the others). Communicating that reason (withou saying "your old way is stupid") is the key. 2017-06-16 12:43:40 the current thing with .initd/.confd is easy since abuild(1) knows it and places it automatically 2017-06-16 12:43:45 rfs613: teach me more senpai 2017-06-16 12:43:58 that's not what I was talking about 2017-06-16 12:44:24 skarnet: hehe.. i'm just tryign to save you from getting memed like Lennart ;-) 2017-06-16 12:44:54 in case you hadn't see it https://blog.parrotsec.org/debian-and-devuan/ 2017-06-16 12:45:38 skarnet: another thing that sorta worries me from a very casual look is user-configurability in s6 service scripts 2017-06-16 12:45:45 and yet people ate Lennart's crap and are asking for a seond course 2017-06-16 12:45:46 (but i hope to just be seeing it wrong :p) 2017-06-16 12:45:47 second* 2017-06-16 12:46:06 e.g. with openrc a user can trivially set, say, command_user in /etc/conf.d/ 2017-06-16 12:46:23 to launch the daemon as a different user 2017-06-16 12:47:09 that's just a s6-setuidgid command in the run script 2017-06-16 12:47:11 skarnet: i think it was more a case that lennert works for redhat and got his, ahem, "stuff", pushed out that way. 2017-06-16 12:47:26 well yes, but then the user would have to edit the run script 2017-06-16 12:47:32 ACTION had a few years without audio working thanks to pulseaudio fiasco. 2017-06-16 12:47:33 instead of being able to configure it more... declaratively 2017-06-16 12:47:35 i guess. 2017-06-16 12:47:50 ok, so what you want is a servicedir generator 2017-06-16 12:48:05 > ok, so what you want is a servicedir generator 2017-06-16 12:48:14 wow 2017-06-16 12:48:30 You took the joke too far 2017-06-16 12:48:50 We've been there 2017-06-16 12:48:52 skarnet: that sounds about right, I guess 2017-06-16 12:49:04 With config file generator for sendmail 2017-06-16 12:49:25 isn't sendmail config just perl 2017-06-16 12:49:39 Nah 2017-06-16 12:49:41 It's m4 2017-06-16 12:49:45 oh god, even worse 2017-06-16 12:49:57 No 2017-06-16 12:50:01 I mean generator is m4 2017-06-16 12:50:08 consus: I'm trying to have a productive discussion here 2017-06-16 12:50:18 Because own cf file format is too goddamn complicated 2017-06-16 12:50:55 Shiz: if all your concerns are about UI, can we talk about your ideal UI? 2017-06-16 12:50:57 So even m4 is better 2017-06-16 12:51:02 That cf 2017-06-16 12:51:16 Well, when I look at s6 it's kinda rings a bell 2017-06-16 12:51:19 skarnet: yeah, my concerns are about UI, not necessarily about s6 internals - I'm fine and convinced that your approach is correct there 2017-06-16 12:51:20 :P 2017-06-16 12:51:21 isn't the solution to use qmail instead of sendmail? 2017-06-16 12:51:24 something purely declarative, in one file 2017-06-16 12:51:25 ACTION runs away fast 2017-06-16 12:51:30 skarnet: do you mind if we talk about UI specifics later, though? 2017-06-16 12:51:34 rfs613: of course it is 2017-06-16 12:51:42 as I said at the start, I'm sort of busy right now 2017-06-16 12:51:53 Shiz: np, it will be ongoing work anyway 2017-06-16 12:51:54 gotta get some work done 2017-06-16 12:52:04 just wanted to make sure that one-file and declarative is what you want 2017-06-16 12:52:25 out of curiosity, is the goal to add s6 as an option, or to replace openrc? 2017-06-16 12:52:46 the goal has always been to make it a choice 2017-06-16 12:52:47 i can't speak for all of alpine on the latter, but i'm not particularly interested in maintaining two rc systems 2017-06-16 12:52:53 but yeah, opinions 2017-06-16 12:53:03 others differ :) 2017-06-16 12:53:27 Where can one read about why alpine wants to move from openrc? 2017-06-16 12:53:33 I obviously won't mind if Alpine people eventually ditch openrc, but that's not a decision for me to make :P 2017-06-16 12:53:41 ok so still in the air, gotcha. Well I recently learned openrc (after initially ignoreing it since it worked fine). Guess I should look at s6-init more carefully. 2017-06-16 12:54:03 it's still very much a thing that is being concepted, yes 2017-06-16 12:54:07 I kinda like the way it's easy to configure alpine right now 2017-06-16 12:54:20 consus: the long and short of it is that openrc doesn't/can't properly manage services 2017-06-16 12:54:26 Hm 2017-06-16 12:54:29 Really? 2017-06-16 12:54:32 I and a lot of alpine devs very much dig its UI from a service writer/user standpoint, buuut 2017-06-16 12:54:34 Kinda works for me 2017-06-16 12:54:39 when it comes down to it 2017-06-16 12:54:42 its a hack around start-stop-daemon 2017-06-16 12:54:52 which means it doesn't exactly care when a process dies 2017-06-16 12:54:57 or does anything to restart it on its own 2017-06-16 12:54:59 (properly) 2017-06-16 12:55:05 Well 2017-06-16 12:55:07 also, parallel start is broken 2017-06-16 12:55:11 It always was a good thing for me 2017-06-16 12:55:17 That it does nothing with a process 2017-06-16 12:56:21 Can't speak for others of course 2017-06-16 12:56:35 fortunately 2017-06-16 12:56:57 skarnet: Why are you so aggressive? 2017-06-16 12:57:24 because you've brought nothing but empty criticism and intellectual laziness, and that's not what I'm looking for 2017-06-16 12:57:33 calm down folks 2017-06-16 12:57:37 I'm calm 2017-06-16 12:57:46 aint a competition to measure your mental penises 2017-06-16 12:57:53 Hey, I'm calm 2017-06-16 12:58:14 so am I, and I'm also done for now, thanks for clarifying your position Shiz 2017-06-16 12:58:22 hit me up later for details 2017-06-16 12:58:23 now I know what I need to work on. 2017-06-16 12:58:31 i don't think i'll be around tonight specifically, but i will be tomorrow 2017-06-16 12:58:41 it's fine, no rush 2017-06-16 12:58:53 I have all summer to work on that 2017-06-16 12:59:44 consus: could you clarify why you'd want it to not touch processes? 2017-06-16 12:59:58 in my and i guess most people's expectations, if a service process crashes i'd like to know about it at the very least 2017-06-16 13:00:05 and preferably restart it 2017-06-16 13:00:07 Well 2017-06-16 13:00:15 that's why it's a service process and not something i just run in the bg 2017-06-16 13:00:31 Because when a processes crashes my monitoring systems tells me that 2017-06-16 13:00:38 I have a nice log 2017-06-16 13:00:39 that's one of those things where people have differing opinions; on whether to have an init system restart a crashed process or not 2017-06-16 13:00:40 A crashdamp 2017-06-16 13:00:53 A stacktrace if we are talking about java 2017-06-16 13:01:09 sure, but wouldn't an argument be that you only have that monitoring system because of an insufficiently competent service manager? 2017-06-16 13:01:10 :P 2017-06-16 13:01:17 Nah 2017-06-16 13:01:24 Monitoring checks more than that 2017-06-16 13:01:28 Disk space 2017-06-16 13:01:38 RAID health 2017-06-16 13:01:38 depends whether you are a developer or a user too. User might appreciat restart, a developer might not (so they can go debug it). 2017-06-16 13:01:45 That kind of stuff 2017-06-16 13:02:11 Also the process may be up, but stuck in a while(1) loop 2017-06-16 13:02:37 And of course, it's up, but it's also useless 2017-06-16 13:03:43 Also depends why it failed... if you restart and it immediate crashes again, that's no good either. Presumably there's some kind of limit on that. 2017-06-16 13:03:48 Yes 2017-06-16 13:03:57 That's too 2017-06-16 13:04:08 a process supervisor and a monitoring system have different goals and are not competing with each other 2017-06-16 13:04:09 Endless loop of die-restart will not make things better 2017-06-16 13:04:36 restarting a process does not absolve you from sending an alert, the admin should investigate anyway. 2017-06-16 13:04:45 Well 2017-06-16 13:04:51 I have monitoring for alerts 2017-06-16 13:04:55 It does the job 2017-06-16 13:05:32 TBB said it well, people will have differing opinions on this sort of thing. I would think that therefore a tool which offers restart as an option (or equivalently, has a way to disable restart) would be good. 2017-06-16 13:05:52 rfs613: surprise, s6 does exactly that ;) 2017-06-16 13:06:04 excellent! 2017-06-16 13:06:10 Also 2017-06-16 13:06:26 How hard would it be to patch openrc so it would restart a service? 2017-06-16 13:06:49 How hard would it be to make a duck bark? 2017-06-16 13:07:09 Err 2017-06-16 13:07:15 How it's related to the topic? 2017-06-16 13:07:25 openrc keeps track of started services 2017-06-16 13:07:28 In /run dir 2017-06-16 13:07:49 it doesn't know when a process dies. 2017-06-16 13:07:59 For now -- no, it does not 2017-06-16 13:08:08 So again -- how hard would it be to patch it? :) 2017-06-16 13:08:13 If you're patching it so it does, you're basically implementing a supervisor. 2017-06-16 13:08:22 Yep 2017-06-16 13:08:59 So my question is -- if the lack of proper supervision in openrc is the only trouble, how hard would it be to implement one? 2017-06-16 13:09:18 Harder than it sounds. The world is full of half-assed supervision solutions. 2017-06-16 13:09:40 If you want to implement supervision right, you need to design for it from the start, not add it as an afterthought. 2017-06-16 13:10:13 So what these half-assed supervisors lack? 2017-06-16 13:10:33 Reliability, i.e. the exact thing they're supposed to provide. 2017-06-16 13:10:34 <_ikke_> Having a good way to track the processes involved 2017-06-16 13:10:49 Why they lack it? 2017-06-16 13:10:59 Well, I want some concrete design flaw 2017-06-16 13:11:54 ok, here we go... 2017-06-16 13:12:01 <_ikke_> consus: You start a process, track it's pid. Next, the process double forks to daemonize. What pid should you track now? 2017-06-16 13:12:16 a process' parent is the only one that can reliably send signals to it. 2017-06-16 13:12:26 Any other case involves race conditions. 2017-06-16 13:12:26 AHa 2017-06-16 13:12:30 Of course 2017-06-16 13:12:45 A supervisor has to run as the process' parent. 2017-06-16 13:12:49 Yes 2017-06-16 13:13:16 If it doesn't, it can't perform its service id -> process id translation reliably. 2017-06-16 13:13:21 Yes 2017-06-16 13:13:26 You risk sending a signal to the wrong process. Always. 2017-06-16 13:13:31 Of course 2017-06-16 13:13:35 So what's your point? 2017-06-16 13:13:56 You asked for a concrete design flaw. I gave you one. 2017-06-16 13:14:04 Okay 2017-06-16 13:14:41 It would be pretty easy to make start-stop-daemon call openrc via e.g. unix socket to perform the actual task 2017-06-16 13:18:02 And then it can wait for SIGCHLD and restart the process in question if it's what the user want 2017-06-16 13:18:58 You're on your way to designing a supervisor. Please do what you think is best and show us your work when it's done. Then we can judge. 2017-06-16 13:20:39 skarnet: senpai talking here again. Please try to say it in a more condescending way. You are being far to polite ;-) 2017-06-16 13:21:17 skarnet, still around? 2017-06-16 13:21:30 I've been reading the backlog 2017-06-16 13:21:51 saw your FOSDEM video about s6 2017-06-16 13:22:06 fcolista: sure 2017-06-16 13:22:53 which made me think that a software who does what actually has been designed seems rare now 2017-06-16 13:23:04 anyway 2017-06-16 13:23:28 are there other distro who have already implemented s6 succesfully? 2017-06-16 13:23:42 Or alpine it's a test-base? 2017-06-16 13:23:57 the only distro i know with a sorta djb-ish service manager as its default is void 2017-06-16 13:24:00 I only saw this: https://wiki.gentoo.org/wiki/S6 2017-06-16 13:24:02 using runit 2017-06-16 13:25:10 fcolista: not yet and no. I don't consider Alpine a "test-base". 2017-06-16 13:25:41 there's a lot of work to do precisely because it hasn't been done before. The thing is, s6 provides only mechanism, and distros are all about policy, so that's where the work remains to be done. 2017-06-16 13:26:05 :) 2017-06-16 13:26:08 there is another new-turbo-cool init: https://davmac.wordpress.com/2017/06/14/escape-from-system-d/ 2017-06-16 13:26:38 I've come to realize that initiatives such as openrc and systemd are successful *because* they embed policy, which is heartbreaking to me 2017-06-16 13:27:03 but basically "we are doing all the work for the distro, so it's easy to integrate" 2017-06-16 13:27:17 who's working on s6, beside you? 2017-06-16 13:27:41 it's mostly me, but I have a team of minions for testing and bug-reports :) 2017-06-16 13:27:55 eheh 2017-06-16 13:28:40 so we have on a plate: a well-designed init system, with the main developer in-house 2017-06-16 13:29:01 no distribution so far have already implemented it 2017-06-16 13:29:22 so no much experience and user-interaction so far 2017-06-16 13:29:31 for me part of the fun in alpine is daring to do things other distros don't 2017-06-16 13:29:32 please stop me if I say something worng 2017-06-16 13:29:33 skarnet: that's humanity for you in a nutshell: never about just technical brilliance and edge :/ 2017-06-16 13:29:35 like switching to libressl 2017-06-16 13:29:37 :p 2017-06-16 13:29:47 Who said Gentoo 2017-06-16 13:29:57 Shiz, +1 2017-06-16 13:30:05 i'm not making any proposal 2017-06-16 13:30:11 fcolista: from the technical side that's not an issue, there are a lot of people using s6 as an init system - mostly in Docker containers 2017-06-16 13:30:18 just adding some points to understand 2017-06-16 13:30:28 from the UX side you're right, not much experience in a user-facing distro 2017-06-16 13:30:36 and that's why I'm asking here what it would take 2017-06-16 13:30:42 and Shiz gave me some good answers 2017-06-16 13:30:56 A declarative config is a must have, really 2017-06-16 13:31:02 ofc, if a thng never start, never experience will be done 2017-06-16 13:31:03 Shiz: don't forget switching to musl ;-) 2017-06-16 13:31:15 i could list numerous things ;p 2017-06-16 13:31:30 the "keeping things small and wanting to do things well" aspect is what draws me to Alpine tbh 2017-06-16 13:31:35 including the hopefully-in-3.8 LLVM switch 2017-06-16 13:31:42 skarnet: likewise 2017-06-16 13:31:46 about the learning curve, i agree with you 2017-06-16 13:32:04 mental lazyness about learning a new stuff is not clever 2017-06-16 13:32:26 i think if we come up with a reasonable format it shouldn't need that much of a learning curve 2017-06-16 13:32:29 the downside is that will not attract users 2017-06-16 13:32:34 at least at the beginning 2017-06-16 13:32:52 if it's what it takes I'll work on a UI 2017-06-16 13:33:00 :) 2017-06-16 13:33:06 for what it's worth, i'm happy to work with you on this 2017-06-16 13:33:07 so, having a tool like config-generator would be good 2017-06-16 13:33:11 both in ideas and code 2017-06-16 13:33:17 Err 2017-06-16 13:33:25 config-generator? 2017-06-16 13:33:39 consus, you understood what i mean 2017-06-16 13:33:49 Well 2017-06-16 13:33:56 consus: s6's native format is execline 2017-06-16 13:34:08 as I understand it, the current idea is to generate those execline scripts 2017-06-16 13:34:11 nope, that's a misconception 2017-06-16 13:34:14 Err 2017-06-16 13:34:16 skarnet: well 2017-06-16 13:34:16 Well 2017-06-16 13:34:18 that is true 2017-06-16 13:34:19 My 5 cents 2017-06-16 13:34:20 but 2017-06-16 13:34:24 run scripts can be written in any language 2017-06-16 13:34:27 right. 2017-06-16 13:34:30 :P 2017-06-16 13:34:31 redhat now has a unit-file generator 2017-06-16 13:34:35 i've used djb style with dnscache, tinydns and whaterve with /svc, and i liked it 2017-06-16 13:34:38 init -> systemd 2017-06-16 13:34:45 And sometimes it generates crap 2017-06-16 13:34:48 i presume by 'init' you mean sysvrc 2017-06-16 13:34:51 Yep 2017-06-16 13:34:53 well 2017-06-16 13:34:55 execline is used internally because it's easy to autogenerate, but it's not essential 2017-06-16 13:34:57 crap in, crap out 2017-06-16 13:35:02 And you don't know why 2017-06-16 13:35:03 and sysvrc is very much crap in 2017-06-16 13:35:08 That's not the reason 2017-06-16 13:35:25 You basically have two configurations now 2017-06-16 13:35:25 skarnet: you're right, i didn't mean it like that 2017-06-16 13:35:29 The human-readable 2017-06-16 13:35:33 but execline is also easy to generate as i understand it 2017-06-16 13:35:34 And the machine-readable 2017-06-16 13:35:38 And that's not very good 2017-06-16 13:35:38 fcolista: so do you agree with Shiz's points, or do you have additional ones? 2017-06-16 13:35:57 consus: do you have an example of such a bad unit file on hand? 2017-06-16 13:36:00 i'm just curious 2017-06-16 13:36:07 Hm 2017-06-16 13:36:11 Perhaps 2017-06-16 13:36:13 skarnet, which part of Shiz 's comment are you referring? 2017-06-16 13:36:24 It's some kind of mellanox ofed 2017-06-16 13:36:28 I don't remember which one 2017-06-16 13:36:31 Let me check 2017-06-16 13:36:52 fcolista: when he listed what was lacking in s6 for adoption, namely a user-relatable UI 2017-06-16 13:37:02 if you have additional points I'll be glad to hear them 2017-06-16 13:37:11 but right now I need to afk for a bit 2017-06-16 13:37:42 ok 2017-06-16 13:37:45 let's say this: 2017-06-16 13:37:56 (my personal opinion ofc): 2017-06-16 13:38:18 alpine is becoming famous mostly about containers 2017-06-16 13:38:30 Well, is there a way to list a current deps tree? 2017-06-16 13:38:37 For a service 2017-06-16 13:38:44 ppl who uses container are not necessarily high-skilled ppl 2017-06-16 13:39:02 but ppl who wants the things that works "out-of-the-box" 2017-06-16 13:39:12 I'm referring to docker mainly 2017-06-16 13:39:49 otoh, who uses alpine by-choice as main distro, well, it's like ppl who wants to use gentoo 2017-06-16 13:39:59 that likes to get the hands dirty 2017-06-16 13:40:06 Err 2017-06-16 13:40:08 Not exactly 2017-06-16 13:40:18 Alpine is great because I do not have to get the hands dirty 2017-06-16 13:40:30 consus, that's your opiniong 2017-06-16 13:40:33 *opinion 2017-06-16 13:40:44 Yes 2017-06-16 13:41:26 ppl who doesn't want to bother with security/small/etc uses debian and derivative 2017-06-16 13:41:41 anyway my point is another 2017-06-16 13:41:46 > s6-sudo connects to a Unix domain socket and passes its standard file descriptors, command-line arguments and environment to a program running on the server side, potentially with different privileges. 2017-06-16 13:41:50 Err 2017-06-16 13:41:56 fcolista: alpine as main distro is better than gentoo 2017-06-16 13:42:09 pickfire, i use alpine as main distro 2017-06-16 13:42:10 At least cam be compared to Arch. 2017-06-16 13:42:27 pickfire: Not for everything 2017-06-16 13:42:47 fcolista: I used to do that but rarely do that nowdays, still keep to old Arch since I need like chinese input, latex and stuff that can't be found in alpine. 2017-06-16 13:42:48 let's put in another way: ppl who use arch/gentoo is not the same who uses ubuntu 2017-06-16 13:42:54 True 2017-06-16 13:43:06 hey :) 2017-06-16 13:43:13 So hard for me to even contribute in alpine nowdays. 2017-06-16 13:43:33 but who wants to use docker/alpine can be buntu people as "user" 2017-06-16 13:43:35 so 2017-06-16 13:43:39 Well, why the hell init systemd has s6-sudo? 2017-06-16 13:43:50 *init system 2017-06-16 13:43:54 :D 2017-06-16 13:43:57 Haven't heard of that. 2017-06-16 13:44:07 with this assumptions, i *think* that s6 with a UI interaction would be good to have 2017-06-16 13:52:32 http://www.gnu.org.ua/software/pies/ 2017-06-16 13:52:36 TIL gnu has its own rc 2017-06-16 13:58:35 Shiz: I wonder why clang instead of gcc? 2017-06-16 13:58:45 I thought gcc compiles slightly better? 2017-06-16 13:58:58 But to me, both of them seems fat. 2017-06-16 13:59:04 they are mostly on equivalent terms these days as i understand it 2017-06-16 13:59:10 sometimes gcc is better, sometimes clang 2017-06-16 13:59:22 http://suckless.org/sucks/ 2017-06-16 13:59:33 i don't care much about suckless' opinions 2017-06-16 13:59:34 clang is there accompanying gcc as well 2017-06-16 13:59:49 Shiz: How is clang better than gcc? 2017-06-16 14:00:47 Like your opinion and how so. 2017-06-16 14:00:55 somewhat nicer for corsscompile 2017-06-16 14:01:01 crosscompile 2017-06-16 14:01:08 it has some nice CFI features too 2017-06-16 14:01:29 few reasons 2017-06-16 14:01:35 cross-compilation is nice 2017-06-16 14:01:35 and apparently it is in llvm that much of the development happens nowdays 2017-06-16 14:01:52 despite being C++ and enterprise at that, it's still a better codebase than gcc imo 2017-06-16 14:02:02 gcc is c++ too 2017-06-16 14:02:03 and development effort seems to be moving towards clang 2017-06-16 14:02:04 btw 2017-06-16 14:02:08 especially in hardening 2017-06-16 14:02:16 because of google and apple investing manpower into ti 2017-06-16 14:02:56 Ah 2017-06-16 14:02:56 it's the only really viable alternative to gcc, tbh 2017-06-16 14:03:04 That's what I heard. 2017-06-16 14:03:09 Both are now in C++ 2017-06-16 14:03:13 i'd like to use something like cparser if it was mature but 2017-06-16 14:03:21 i don't think even 20% of our packages will compile with cparser 2017-06-16 14:03:22 I look forward to rust but it haven't mature yet. 2017-06-16 14:03:29 and i don't intend to fix the 80% that doesn't 2017-06-16 14:03:33 or the bugs in cparser that make that happen 2017-06-16 14:03:35 :p 2017-06-16 14:03:36 Hmm 2017-06-16 14:03:42 I want s cscope/ctags based on clang 2017-06-16 14:03:48 Anything in stock? 2017-06-16 14:03:49 there's already an llvm ctags i think 2017-06-16 14:03:54 Where? 2017-06-16 14:03:57 https://github.com/drothlis/clang-ctags 2017-06-16 14:03:57 Nice, gotta check 2017-06-16 14:04:12 Cause cscope sometimes SUCKCS COCKS IN HELL 2017-06-16 14:04:13 How's llvm ctags different from normal ctags? 2017-06-16 14:04:18 https://github.com/Andersbakken/rtags 2017-06-16 14:04:25 it uses clang's parsing engine, probably 2017-06-16 14:04:28 Because normal ctags does not implement a complete functional parser 2017-06-16 14:04:43 Like cscope 2017-06-16 14:04:44 Ah, I tried csope in vim and can't even figure out why it needs so many key for just a simple thing. 2017-06-16 14:04:51 Nah 2017-06-16 14:04:53 It does 2017-06-16 14:05:00 Where? 2017-06-16 14:05:05 The problem is -- it does not always gets the syntax right 2017-06-16 14:05:10 Like :cg 2017-06-16 14:05:24 consus: How do you make use of cscope? 2017-06-16 14:05:30 Well 2017-06-16 14:05:38 pickfire: i use cscope+vim with only two keys... one for going to definition, the other for finding all references to definition. I never need much beyond that. 2017-06-16 14:05:44 I'm trying to navigate code with it 2017-06-16 14:05:47 :D 2017-06-16 14:06:02 rfs613: Can't ctags do that? 2017-06-16 14:06:23 pickfire: AFAIK it can only do the first one. 2017-06-16 14:06:27 ctags can't search for invocations 2017-06-16 14:06:29 For example 2017-06-16 14:06:30 Definition with [d, find all definition with [D IIRC 2017-06-16 14:06:51 and can even complete defininion with ^x^d 2017-06-16 14:07:17 consus, rfs613: Are you all sure about that? 2017-06-16 14:07:34 pickfire: i haven't used ctags in years, so maybe it learned new tricks since then. 2017-06-16 14:07:44 Ah, probably. 2017-06-16 14:07:59 pickfire: Well it cannot do that in vim at least 2017-06-16 14:08:46 Can 2017-06-16 14:08:51 How? 2017-06-16 14:09:05 :h [D 2017-06-16 14:09:11 :h [I 2017-06-16 14:10:02 Err 2017-06-16 14:10:10 [D finds nothing 2017-06-16 14:10:15 Or even [^i and ]I 2017-06-16 14:10:24 [I finds both definitions and calls 2017-06-16 14:10:45 I run it as ctags -R 2017-06-16 14:10:56 consus: D for definition and I for keyword 2017-06-16 14:11:02 Well 2017-06-16 14:11:07 It cannot find a definition 2017-06-16 14:11:48 E388: could not find definition 2017-06-16 14:12:25 C+] jumps to definition just fine 2017-06-16 14:13:48 consus: Try I instead of D 2017-06-16 14:13:53 Yes 2017-06-16 14:13:54 definition is for macro 2017-06-16 14:14:00 [I shows everything 2017-06-16 14:14:10 consus: I mean [ + ^I 2017-06-16 14:14:19 Oh 2017-06-16 14:14:20 Okay 2017-06-16 14:14:22 Works 2017-06-16 14:14:39 consus: And then ] + I 2017-06-16 14:14:45 To display everything below it. 2017-06-16 14:14:55 ACTION personally don't see how cscope is useful then 2017-06-16 14:15:16 Lucky I took my time and read the help page, if not that feature will extinct by itseft. 2017-06-16 14:15:28 Well 2017-06-16 14:15:35 For me it's the other way around 2017-06-16 14:15:46 I'm fine with cscope, why the hell do I need ctags? 2017-06-16 14:16:14 Btw 2017-06-16 14:16:23 Is there a way to generate quickfix menu for ctags? 2017-06-16 14:16:32 Ah, and as well I miss ledger in Arch 2017-06-16 14:16:49 consus: What do you mean by that? 2017-06-16 14:16:51 One of the features I like in cscope plugin is quickfix window I can navigate 2017-06-16 14:16:55 Hm 2017-06-16 14:16:56 A menu 2017-06-16 14:16:57 I rarely use quickfix menu. 2017-06-16 14:17:00 j+k 2017-06-16 14:17:04 Not sure how to use it. 2017-06-16 14:17:16 You can navigate it using j/k keys 2017-06-16 14:17:18 consus: Can you explain more about it? 2017-06-16 14:17:22 And the you can jump to the definition 2017-06-16 14:17:24 How to open that? 2017-06-16 14:17:31 Hmm 2017-06-16 14:17:41 I thought quickfix window is for compilation errors? 2017-06-16 14:17:44 Like :copen 2017-06-16 14:17:47 Yeah 2017-06-16 14:17:59 ACTION see nothing there 2017-06-16 14:18:07 But since there is no normal menu support in vim other plugins use it for their own output 2017-06-16 14:18:24 CScope plugin uses it for displaying the shit it found 2017-06-16 14:18:33 consus: Example use case? 2017-06-16 14:18:37 Well 2017-06-16 14:18:41 A HELL LOT OF THEM 2017-06-16 14:18:44 Like in Linux kernel 2017-06-16 14:19:03 Where? I never looked into linux kernel with cscope in vim. 2017-06-16 14:19:14 Well 2017-06-16 14:19:16 Everywhere 2017-06-16 14:19:17 :D 2017-06-16 14:19:20 this seems maybe better fit for the main channel 2017-06-16 14:19:24 Sorry 2017-06-16 14:20:26 Ah 2017-06-16 14:20:28 Sorry 2017-06-16 14:22:54 consus: Can you please go to #alpine-linux and talk? 2017-06-16 14:31:34 just wondering why uptream removed the ca-certificates_20161130.tar.xz and replaced with ca-certificates_20161130+nmu1.tar.xz 2017-06-16 14:36:10 https://launchpad.net/debian/+source/ca-certificates/+changelog 2017-06-16 14:36:16 * Add StartCom and WoSign certificates to mozilla/blacklist.txt as they are now untrusted by the major browser vendors. Closes: #858539 2017-06-16 14:36:25 probably so that anyone using debian ca-certificates would be forced to update 2017-06-16 14:39:19 <^7heo> ? 2017-06-16 14:39:27 <^7heo> How are those CAs related to debian? 2017-06-16 14:39:45 ca-certificates is debian's 2017-06-16 14:39:51 it's their collection 2017-06-16 14:40:15 <^7heo> ah ok 2017-06-16 14:40:28 how did v3.6 builder failed to detect ? 2017-06-16 14:40:50 it wasn't rebuild probably after they changes 2017-06-16 14:40:53 rebuilt* 2017-06-16 14:40:56 changed it 2017-06-16 14:41:08 ok, its dated 2017-05-19 2017-06-16 14:41:25 got confused with 20161130 2017-06-16 14:44:27 thanks 2017-06-16 14:46:12 you mean we should be aggregating ourselves from C-Authorities ? 2017-06-16 14:47:02 i don't mean anything 2017-06-16 14:47:04 :p 2017-06-16 14:47:37 :) 2017-06-16 15:04:23 there is another al based, http://www.eisfair.org/en/eisfair/eisfair-ng/ 2017-06-16 15:05:12 neat 2017-06-16 15:28:49 wtf 500+ in backlog... did i miss anything useful? 2017-06-16 15:29:21 clandmeter: blame it on me, I'm used to it 2017-06-16 15:38:01 nah, im having weekend so im all happy just like Shiz :) 2017-06-16 22:17:09 Shiz: fcolista: skarnet: fwiw, we in Adélie would be very happy and excited to offer experimental s6 support as a 'test' distro. we're already pioneering KDE on musl, Java on musl, Steam on musl... it might not all be rock solid just yet, but our goal is to put emerging technologies together with user friendly interfaces to incubate a usable, secure, stable environment 2017-06-16 22:17:42 that was a big factor in our switch to alpine for upstream: gentoo is still trying to get relro working, and they're about ten years late on that effort.. not to mention stuff like apparmor 2017-06-16 22:17:58 lol 2017-06-16 22:18:13 awilfox: I'll take you up on that offer, let's talk about it this summer ;) 2017-06-16 22:18:23 brb 2017-06-16 22:18:58 yep :D 2017-06-16 23:07:27 skarnet: well, i'm here 2017-06-16 23:07:29 :p 2017-06-16 23:54:46 Shiz: but I'm not. I may be here occasionally this week-end. :) 2017-06-18 05:49:25 the cmd "abuild-apk add kbd-bkeymaps" says "1 errors; 1815 MiB in 474 packages". but can not found where is the error occured. how can i debug it? 2017-06-18 05:50:21 ALSO TO ALL " apk add xxxx " , 1 errors . 2017-06-18 05:51:04 if i should add the root to abuild group? 2017-06-18 05:53:27 i am a normal user had joined the abuild group. the user root is not. 2017-06-18 05:59:58 sudo apk add also says 1 errors; 2017-06-18 06:01:18 but "apk info" fine 2017-06-18 06:18:17 ls 2017-06-18 08:13:42 make nothing 2017-06-18 08:18:53 ls 2017-06-18 08:18:55 pwd 2017-06-18 08:19:37 Hello, is there any private mailing list for security issues in alpine? 2017-06-18 08:20:03 Or should security issues be sent straight to alpine-devel? 2017-06-18 09:18:23 baliste we don't have a private list yet 2017-06-18 09:18:58 http://lists.alpinelinux.org is what we currently have 2017-06-18 09:53:09 clandmeter, mmm so should I publish a security advisory in a public list? 2017-06-18 14:30:41 baliste, we are working on a solution. For now it's the only way. Or else email one of us directly. 2017-06-18 18:24:25 hmm, so is bootstrap.sh the best way to do a cross compile of packages? trying to work on getting ghc ported to some other arches but binutils doesn't seem to be building via that for any other arch I try 2017-06-18 18:57:21 Debian 9(stretch) has implemented, 2017-06-18 18:57:22 1. New method for naming network interfaces, ens0 or enp1s1 (ethernet) or wlp3s0 (wlan) 2017-06-18 18:57:22 2. A new archive for debug symbols (dbgsym) 2017-06-18 18:57:22 Just to point as similar discussions happened here in past 2017-06-18 18:58:41 1. which means future docs/articles/manuals would start using the dev names 2017-06-18 18:58:57 that's a systemd thing. You can ignore. 2017-06-18 18:58:59 1 is a simple consequence of adopting systemd 2017-06-18 18:59:01 2. nice point, as we want to keep directory light 2017-06-18 18:59:52 iirc, freebsd also uses similar format for devices 2017-06-18 19:00:40 its generated by firmware/BIOS 2017-06-18 19:01:53 not entirely, depending on the driver you can get devices like ral/em/etc... at least i have nothing with a dev name of en on my freebsd 10 system 2017-06-18 19:01:54 rather driver-specific names IIRC 2017-06-18 19:07:45 adelie devs has pointed out their need for -dbg being build for all pgks, having separate dir makes sense 2017-06-18 19:16:12 The other thing stretch has is 90% reproducible builds which is awesome 2017-06-18 19:17:04 As in 90% of the packages, not 90% of the time 2017-06-18 19:17:44 we should learn and pick sweet cherry implementations like apple does, eg, https://en.wikipedia.org/wiki/Apple_File_System 2017-06-18 19:20:12 iirc, 10yrs of developemnt and finally, bingo its done 2017-06-18 19:24:40 rather than flamming and re-flamming over systemd, push its developer more to shi* out more, maybe something nice somes out 2017-06-18 19:25:39 sea/ocean is actually full of shi* but life rose from it 2017-06-18 19:26:14 uhm, okay 2017-06-18 19:26:37 gtg, that was result of "weekend idealing over nothing" ;) 2017-06-18 19:29:02 lel 2017-06-18 19:32:10 that's a theory... give a million Lennarts a keyboard and given enough time one of them will write the complete works of Ken Thompson 2017-06-18 19:35:49 <_ikke_> what is the prepare / patch PWD? 2017-06-18 19:44:12 if I understand you correctly, the APKBUILD directory 2017-06-18 19:46:06 <_ikke_> somehow patch keeps failing to find the target file 2017-06-18 19:47:02 _ikke_: incorrect -pnum? 2017-06-18 19:49:23 <_ikke_> scadu: No, it appears that make is unpacking a tar, so the target file does not exist yet 2017-06-18 19:50:31 <_ikke_> Not sure how I should handle that 2017-06-18 19:50:47 <_ikke_> (it's a packaged dep) 2017-06-18 19:55:27 <_ikke_> I try to patch something so it works with libressl, but the files does not exist yet at prepare time :/ 2017-06-18 20:03:04 unpack it yourself 2017-06-18 20:03:27 <_ikke_> right 2017-06-18 20:03:33 <_ikke_> was thinking about that 2017-06-18 21:20:10 jirutka: Shiz ncopa https://about.pullapprove.com/ what do you think about this service? it would help with managing pull requests 2017-06-19 07:23:52 scadu, what would you fix by using this service? 2017-06-19 07:29:45 clandmeter: jirutka had the idea of sending notifications like: "yo, your package is broken/outdated. do you still maintain it?" 2017-06-19 07:30:18 but this probably could be done by extending bot functionality 2017-06-19 07:30:36 probably 2017-06-19 07:31:02 i dont think you can do anything like that with pr approval. 2017-06-19 07:32:17 maintainer would receive email notification about pr to package (s)he maintain 2017-06-19 07:33:50 it can do magic based on pr contents? like parse the maintainer field? 2017-06-19 07:34:29 i mean, would it work even if the maintainer is not a github user? 2017-06-19 07:37:41 ideally we should create our own implementation for such functionality. ie add functions to pkgs.a.o or similar and use our own metadata. 2017-06-19 07:37:56 clandmeter: not sure, didn't test it yet. however, we could use the format of pullapprove.yml 2017-06-19 07:37:58 I agree 2017-06-19 07:39:10 for instance, notify maintainer if x commits have been from another developer. 2017-06-19 08:00:23 clandmeter: I don't see such conditions available in pull aprove unfortunately. but as you said, it would be better to create something that meets our requirements using format similar to .pullaprove.yml 2017-06-19 08:01:21 looking forward for your implementation ;-) 2017-06-19 08:13:27 clandmeter: heh, it might take a while ;f 2017-06-19 08:23:43 :) 2017-06-19 13:49:15 hi, any guide as what main/hvtools does ? 2017-06-19 13:50:08 noticed that is build from v4.4.15 pkg rather than v4.9.31 in AL v3.6 2017-06-19 14:03:05 found some more tools that upstream recommends, https://www.kernel.org/doc/html/latest/dev-tools/index.html 2017-06-19 14:18:53 ncopa, you around? 2017-06-19 14:19:22 http://sprunge.us/VOMe 2017-06-19 14:20:04 I want to add python bindings to vte 2017-06-19 14:20:11 you're the maintainer 2017-06-19 14:23:44 fcolista, he is not around for a few days 2017-06-19 14:23:54 ok 2017-06-19 14:23:59 clandmeter, what do you think? 2017-06-19 14:24:04 http://sprunge.us/VOMe 2017-06-19 14:27:21 did you check http://pkgs.fedoraproject.org/cgit/rpms/vte.git/tree/vte.spec ? 2017-06-19 14:30:34 clandmeter, checked 2017-06-19 14:32:01 /usr/share/pygtk/2.0/defs/vte.defs should go in -dev 2017-06-19 14:32:07 its has a patch and cleans up some static stuff. 2017-06-19 14:33:36 but you use disable static so could be its not present. 2017-06-19 14:33:52 then just push it. 2017-06-19 14:34:11 statics are disabled 2017-06-19 14:34:16 ok 2017-06-19 16:11:28 what's wrong with cmocka on aarch64? 2017-06-19 16:11:49 clandmeter, how can i access my aarch64 lxc? seems the jump box is no longer available 2017-06-19 16:27:10 skarnet: hi 2017-06-19 17:09:48 Shiz: hi, how are you, such a beautiful day today 2017-06-19 17:21:58 both debian and fedora/redhat have ftp sites scrubbed, we may few in aports, need to fix to https 2017-06-19 17:22:11 we have few* 2017-06-19 17:41:58 fcolista: i removed it on purpose, they only work on python2 2017-06-19 17:43:24 umh 2017-06-19 17:43:34 yes you commented that in the APKBUILD 2017-06-19 17:43:43 i didn't saw that before 2017-06-19 17:44:49 and on the topic of python, i don't really see the point in pypy3 either 2017-06-19 17:44:58 python 3.7 has JIT hooks, what more do you need 2017-06-19 18:09:12 Is there some kind of weird magic happening in apk post-install scripts? 2017-06-19 18:09:36 I have a hierarchy I want to chown -R to a given user (that has been added by a pre-install script) 2017-06-19 18:10:10 I need to do that in a post-install script because I don't know the uid before installation - it's dynamic uid 2017-06-19 18:10:29 so I do chown -R myuid:mygid /my/hierarchy 2017-06-19 18:10:51 and... all the files in /my/hierarchy are correctly chowned, but *none* of the subdirectories are 2017-06-19 18:11:03 /my/hierarchy/subdirectory remains root:root 2017-06-19 18:11:15 for all values of subdirectory 2017-06-19 18:11:31 a manual chown -R works as expected 2017-06-19 18:11:53 so... what gives? what voodoo in apk would explain that behaviour, and how can I get chown -R to work properly? 2017-06-19 18:15:29 fabled, yes it changed. Dunno if your key is on it. We mostly use VPN to access the network. 2017-06-19 18:22:23 fabled, kaniini: any insight on the problem I'm experiencing above? I can probably debug this, but if someone already knows something about it it could save me a lot of time 2017-06-19 18:28:03 skarnet: does the hierarchy get created after post-install maybe? 2017-06-19 18:28:06 when the program is first ran? 2017-06-19 18:28:28 no, the whole hierarchy is in the apk's data 2017-06-19 18:29:29 /my/hierarchy/file is chowned, /my/hierarchy/dir isn't, but both are in the apk's data 2017-06-19 18:31:50 that seems odd 2017-06-19 18:32:02 that it does 2017-06-19 18:32:22 that's why I'm suspecting something foul in apk itself 2017-06-19 18:42:51 skarnet, are you using $pkgusers? 2017-06-19 18:43:03 $pkgwhat? 2017-06-19 18:43:13 https://wiki.alpinelinux.org/wiki/APKBUILD_Reference#pkgusers 2017-06-19 18:44:29 aha, interesting. So pkgusers is a variable I should add my users to, and it's expected that apk won't work if I don't? 2017-06-19 18:44:57 uh, wait 2017-06-19 18:45:07 this is only during build-time 2017-06-19 18:45:41 how can this possibly work with dynamic uids? 2017-06-19 20:15:34 I'm going slightly mad 2017-06-19 20:15:40 I straced the post-install script 2017-06-19 20:15:56 the chown -R does perform lchown(blah, uid, gid) for every blah 2017-06-19 20:16:00 and lchown returns 0 2017-06-19 20:16:19 but the owner/group is STILL unchanged on directories 2017-06-19 20:16:23 what. the. fuck. 2017-06-19 20:17:32 wouldn't post-install be executed under fakeroot by any chance? 2017-06-19 20:58:28 nope 2017-06-19 20:58:33 alpine doesnt have fakeroot installed 2017-06-19 20:58:39 i mean 2017-06-19 20:58:41 not by default 2017-06-19 21:02:53 I'm making other experiments 2017-06-19 21:03:10 this is very weird, files in subdirectories are chowned, but directories themselves are not 2017-06-19 21:03:22 despite lchown() being run and returning 0 2017-06-19 22:14:05 skarnet: do you check immediately after? 2017-06-19 22:17:04 I don't have a background script running that manually chowns the directories to root:root, if that's your question 2017-06-19 22:29:29 Are you using chown from install scripts? 2017-06-19 22:30:42 skarnet: was more thinking that maybe somehow apk changes something after running postinstall 2017-06-19 22:31:03 If so, that's not supported. 2017-06-19 22:31:12 oh? 2017-06-19 22:31:32 so is apk going behind my back to change the owners again? 2017-06-19 22:31:46 and what's the right way to do that with dynamic uids ? 2017-06-19 22:31:48 You need to do it from apkbuikd 2017-06-19 22:31:51 i dont know 2017-06-19 22:31:56 im just guessing this 2017-06-19 22:32:11 Going to bed. Gnite 2017-06-19 22:32:17 clandmeter: I would, but I don't have a globally assigned uid and gid 2017-06-19 22:32:22 wait 2017-06-19 22:32:33 don't bait me and leave my dry 2017-06-19 22:32:39 me* 2017-06-19 22:32:46 im not sure clandmeter is intimately familiar with apk anyway either 2017-06-19 22:32:53 kaniini or fabled may know better 2017-06-19 22:33:08 I highlighted them when I first asked my question 2017-06-19 22:33:37 I have a hunch it's going to end with me snatching a random static uid and gid 2017-06-19 22:33:38 it seems like a bug 2017-06-19 22:34:04 i agree with shiz's analysis 2017-06-19 22:34:10 well is apk going behind my back to chown back stuff after post-install scripts, yes or no? 2017-06-19 22:34:22 it shouldn't be 2017-06-19 22:34:33 and am I supposed to be able to chown in post-install scripts, yes or no? clandmeter says no 2017-06-19 22:35:32 no, you shouldn't chown in post-install scripts, BUT it shouldn't matter 2017-06-19 22:36:38 apk_db_install_archive_entry() is the only thing that does chown inside APK. 2017-06-19 22:36:55 what you do is 2017-06-19 22:37:00 you chown it in package() 2017-06-19 22:37:07 users/groups= 2017-06-19 22:37:47 of note 2017-06-19 22:37:57 post-install/post-upgrade are separate scripts 2017-06-19 22:38:05 and if you need to chown every time 2017-06-19 22:38:13 you need to install post-install AND post-upgrade script 2017-06-19 22:38:28 but most likely you should just use users/groups= in abuild which handles it 2017-06-19 22:38:44 along with a pre-install to generate the UID/GID before extraction 2017-06-19 22:39:07 then apk_resolve_uid()/apk_resolve_gid() will work correctly and the files will be installed with the system assigned UID/GID 2017-06-19 22:39:55 BUT realistically you shouldn't have to chown from the post-install/post-upgrade hooks 2017-06-19 22:40:05 however, it SHOULD work 2017-06-19 22:40:19 skarnet: ^ 2017-06-19 22:42:30 kaniini: and pkgusers/pkggroups will work with dynamic uids/gids? 2017-06-19 22:43:28 i.e. if I put stuff under user foobar at build time, at install time it will also put stuff under user foobar even if the pre-install just created user foobar with a different uid ? 2017-06-19 22:53:56 skarnet: yes 2017-06-19 22:54:14 ok, cool. I'll do that then, thanks. 2017-06-20 15:36:17 hi all; I'm looking at the APKINDEX file - and it looks like a package from Community can have a dependency that is only satisfiable by a package in Main. i.e. 'mesa-demos' depends on libEGL.so.1. Does this sound correct? 2017-06-20 15:37:40 yes, community package can depends on package from main or from community too 2017-06-20 15:38:02 <_ikke_> otherwise community would need to include a lot from main too 2017-06-20 15:40:43 Thanks rdutra, _ikke_ : it does sound reasonable, but I wasn't expecting it. Thanks for the quick confirmation! 2017-06-20 17:44:04 skarnet: ack, sorry for my lack of response last time 2017-06-20 17:44:10 you still here? :) 2017-06-20 17:45:15 I'm here, but not focused - gf is here and we'll have dinner soonish - so I can talk but will probably be slow 2017-06-20 17:45:51 no worries then 2017-06-20 17:45:56 feel free to ping me at a more convenient time 2017-06-20 17:45:58 :p 2017-06-20 17:46:10 you pinged me, I was just answering 2017-06-20 17:46:26 XD 2017-06-20 17:46:32 you know what i mean 2017-06-20 17:47:36 get a ticket and stand in line! XD 2017-06-20 17:47:52 Thursday afternoon should be good :P 2017-06-20 17:48:28 Thursday 29.06 2017-06-20 17:49:21 that should be fine 2017-06-20 17:50:13 (for clarity I meant 2017-06-22 :P) 2017-06-20 17:50:36 I figured 2017-06-20 22:30:29 oh fun, I didn't even notice there was a vuln in PaX announced on Monday 2017-06-20 23:57:14 was there? 2017-06-20 23:58:57 CVE-2017-1000377 2017-06-20 23:59:25 https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt 2017-06-21 00:00:55 though I'm not clear what it has to do with PaX specifically 2017-06-21 00:02:31 oh, that CVE is one of many, all sharing same root cause. 2017-06-21 03:56:35 hi it's awilfox, my bouncer is being really, really, really idiotic right now. so the auto-dbg patch for abuild, it works great, but has broken bootstrap.sh because musl-dev is built directly for headers, and it tries to make musl-dev-dbg 2017-06-21 03:57:01 can/should the musl-dev be set norach, independently of musl? 2017-06-21 04:12:27 hm, and now gcc-stage2 failed, no *-gdb.py files in pkg/gcc-stage2-x86_64/usr/triplet/lib/ 2017-06-21 04:16:14 xentec: hi there. it seems you are the one who changed the gcc package to do that, the message being "fix cross-compile paths for gdb helper". it doesn't look like this helper is built in stage2, but maybe my system is configured improperly: can you verify if this was tested with a ./bootstrap.sh run? 2017-06-21 04:16:53 it wouldn't surprise me if I got it wrong the first time :) but equally, I just want to make sure this code should not be guarded by something like CHOST != CTARGET 2017-06-21 06:11:07 hm, actually, the -dbg thing also broke linux-headers because it is arch=all instead of noarch but it is still a headers-only package :/ 2017-06-21 06:11:27 musl-dev being noarch makes sense, but linux-headers I understand why it isn't... hmm 2017-06-21 06:11:45 oh! options="!dbg" 2017-06-21 07:16:37 foxkit :) 2017-06-21 07:48:38 foxkit, let me know its ok and ill merge it. 2017-06-21 08:05:08 >>> gcc-ppc-dbg*: Running split function dbg... 2017-06-21 08:05:10 objcopy: Unable to recognise the format of the input file `libgnarl-6.so' 2017-06-21 08:05:12 >>> ERROR: gcc-ppc-dbg*: dbg failed 2017-06-21 08:05:14 >>> ERROR: gcc-ppc*: prepare_subpackages failed 2017-06-21 08:05:16 hmmmm 2017-06-21 10:23:45 the 'fix underlinking' thing in readline prevents it from being cross-compiled :/ 2017-06-21 10:27:33 oh, I think I see the issues, ncurses-dev isn't installed by the bootstrap.sh 2017-06-21 10:34:00 I think default-dbg is definitely not okay to merge right now 2017-06-21 10:34:07 -dbg still enormously bloats .a archives since they don't get stripped 2017-06-21 10:34:13 1.7gb for clang/llvm 2017-06-21 10:41:54 who would have thought a toolchain could define so many symbols 2017-06-21 11:26:17 Shiz, what does it matter if its optin? 2017-06-21 11:26:34 clandmeter: ? 2017-06-21 11:26:40 it means clang-dev becomes 1.7gb 2017-06-21 11:26:53 only if you enable it 2017-06-21 11:27:02 no 2017-06-21 11:27:25 are you talking about my patch? 2017-06-21 11:27:31 i'm talking about the default-dbg patch 2017-06-21 11:27:41 before default-dbg: clang-dev is ~100MB or so 2017-06-21 11:27:44 after default-dbg: it's 1.7GB 2017-06-21 11:28:00 my patch does nothing per default 2017-06-21 11:29:40 the patch still requires you to do DEFAULT_DBG in abuild.conf 2017-06-21 11:30:27 yes, and then you can still optout per pkg by setting options="!dbg" 2017-06-21 11:31:49 Shiz, im not attempting to enable default dbg for alpine, i just try to provide the option to do so (as foxkit wanted it). 2017-06-21 11:34:19 right 2017-06-21 11:35:44 could be there are some corner cases, so i was waiting for foxkit to tell me about them :) 2017-06-21 12:40:52 could someone pls see if mqtt-sn, coap protocols make to v3.7, eg paho.mqtt-sn.embedded-c 2017-06-21 12:40:53 idea is to have v3.7 "iot ready (practically)" 2017-06-21 15:15:48 Hello all, I found an issue in a package and I'd like to help get it fixed, where do I start? 2017-06-21 15:27:02 clone aports, submit pr or send patch. 2017-06-21 15:27:58 or send a mail to the ML if you're not sure how to start :) 2017-06-21 15:28:08 but yes, aports and PR is the standard approach 2017-06-21 15:40:27 Ok, thanks. I'm comfortale with git, so hopefully I can pull this off. 2017-06-21 15:44:20 Ok, so I see I can either use the github mirror and do the github pull request dance, or I can email a diff to the mailling list? 2017-06-21 15:44:28 Is there a preferred method? 2017-06-21 15:46:25 NM, I found the contributing.md file...sorry for the noise... 2017-06-21 16:24:29 it's all good 2017-06-21 17:03:29 Should I be working against master or 3.6-stable branch? 2017-06-21 17:58:45 Hi guys, I have created a PR for abuild to add an alternative description to the APKINDEX (instead of "$repo $(git describe)") with a new "-D" parameter: https://github.com/alpinelinux/abuild/pull/21 2017-06-21 18:13:17 ollieparanoid: i got armhf builder unblocked, it is catching up 2017-06-21 20:16:45 kaniini: thanks for the merge and for the info :) great news! 2017-06-21 20:18:02 it is caught up by now 2017-06-21 20:53:22 nice, thanks for letting me know! 2017-06-22 06:19:39 heads up: i'm doing new apk-tools releases today/tomorrow with a CVE fix. 2017-06-22 06:21:28 i'd say it's moderate issue - it's basically DoS (crash) for malformed index/package files. so to trigger it one needs MitM or compromised mirror. it's crash on normal circumstances. (it's remote code execution if ASLR is turned off, but no one should've turned ASLR off anyways) 2017-06-22 07:20:23 I keep getting worried that packages are failing to build because they finish so quickly 2017-06-22 07:21:54 not entirely sure what rice alpine has for ppc32, especially since alpine is not even supposed to support ppc32, but it is miles above debian, gentoo, and even adelie-based-on-gentoo 2017-06-22 07:22:18 perhaps it is because abuild does not fork the python interpreter thrice per package phase, unlike portage 2017-06-22 07:25:40 with how fast this is flying on my power4 machine I'm /almost/ tempted to trying building natively on the 7450 I have, lmao 2017-06-22 09:51:11 openssh doesn't seem to build any more 2017-06-22 09:51:16 it does ./configure ./configure 2017-06-22 09:59:19 was going to send a patch, but now LDFLAGS is screwing it up... 2017-06-22 09:59:25 I don't think I have the shell-fu to fix this 2017-06-22 09:59:43 it needs nested escaped quotes 2017-06-22 10:13:25 and I fixed that but now it is complaining that PAM headers are missing, I think linux-pam-dev needs to be in makedepends_host not just _build 2017-06-22 10:19:01 and linux-pam-dev deps on gettext-dev even though linux-pam doesn't dep on gettext so gettext-dev doesn't exist in the repository... 2017-06-22 10:28:21 https://bpaste.net/show/91bf827462be 2017-06-22 10:28:39 I wonder if that depends_dev is no longer necessary? not sure how else to tell beyond that 2017-06-22 10:32:24 <_ikke_> foxkit: remove it and try to build it? 2017-06-22 10:32:59 _ikke_: well I am not sure how you 'tell' when a dev package deps on another dev package when it is not already a dep, so I figure it must be there for a reason 2017-06-22 10:33:20 but git blame says the dep was there since it was a new aport, so I don't know the original reason it was added 2017-06-22 12:28:34 hello. why we do not see the alpine-edge-ppc64le builder at http://build.alpinelinux.org/ ? 2017-06-22 12:29:50 leitao: tests from arpack package hanged with abuild and make the edge-ppc64le crash 2017-06-22 12:30:18 rdutra, ok 2017-06-22 12:30:20 let me restart it. 2017-06-22 12:30:30 leitao: great, thanks 2017-06-22 13:05:33 ppc64le edge builder is back to live 2017-06-22 13:06:21 thanks! 2017-06-22 13:19:20 <_maniac_> Hi. A quick question: is apkbuild-pypi alive? 2017-06-22 13:20:19 <_maniac_> I mean I see it excluded from abuild's APKBUILD, but is it horribly broken or just a bit broken? 2017-06-22 13:53:52 <_maniac_> well, it works almost fine, only forgot to set description on package and spewed couple of perl warnings. 2017-06-22 15:07:06 Shiz: I still need to reboot my router at some point, and afterwards I'll be available, if you want to talk 2017-06-22 15:07:28 cool 2017-06-22 15:07:32 i'll be home from work in about an hour 2017-06-22 15:07:48 currently compiling a kernel on it, and it's sloooooow because the CPU, which isn't exactly fast in the first place, is throttling itself 2017-06-22 15:08:00 that's what happens when it's 37C outside -_- 2017-06-22 15:08:36 oh dear 2017-06-22 15:10:33 I have a fan. I'm staying in front of it at all times. I'm fine. I love my fan. 2017-06-22 15:10:41 But fanless machines aren't as happy as I am. 2017-06-22 15:38:46 kaniini: how do we mitigate against stackclash right now? 2017-06-22 15:38:53 if not at all, we probably should 2017-06-22 16:32:43 Shiz: i think PaX is not vulnerable, and i think our current kernels already have the fix 2017-06-22 16:34:22 3.5 and 3.6 likely need security backports 2017-06-22 16:34:25 as does 3.4 2017-06-22 16:34:35 the other releases are EOL so yolo 2017-06-22 16:34:36 :p 2017-06-22 16:56:20 <^7heo> I'd be interested to know how PaX fixes/mitigates it. 2017-06-22 16:57:07 they randomize the stack gap, afaik 2017-06-22 16:58:39 <^7heo> ah 2017-06-22 16:58:52 <^7heo> that's an interesting idea. 2017-06-22 20:45:38 kaniini: nonhardened needs a special patch, so i dont think our current kernels have it 2017-06-22 20:46:30 oh, was it a 0day release? 2017-06-22 20:46:31 bah 2017-06-22 20:47:14 wasn't that Qualys disclosure also about PaX? 2017-06-22 20:47:49 i did not see anything about PaX in it 2017-06-22 20:48:46 it has nothing to do with pax 2017-06-22 20:49:00 kaniini: well 2017-06-22 20:49:02 not 0day 2017-06-22 20:49:05 it was embargo'd on distros@ for 4 weeks 2017-06-22 20:49:07 and then 0day'd 2017-06-22 20:49:07 in theory PaX would likely be vulnerable too 2017-06-22 20:49:09 :P 2017-06-22 20:49:17 but 2017-06-22 20:49:18 i don't think grsec is vulnerable because they have random stack gaps 2017-06-22 20:49:31 yeah 2017-06-22 20:49:49 Shiz: just make a PR and i'll review it 2017-06-22 20:51:37 http://www.securityfocus.com/bid/99129 - this one's from Tuesday 2017-06-22 20:53:07 the random stack guard is a grsec feature, not PaX actually. 2017-06-22 22:35:21 regarding stack clash whatever shits 2017-06-22 22:35:34 edge packages are being built right now 2017-06-22 22:35:35 then i will do the backport 2017-06-23 00:37:46 this is probably a question for -user not -devel, but perhaps you can give me a quick pointer. Running 3.6.2 here with edge repos enabled. 2017-06-23 00:38:10 whenever I try "apk add sudo" it fails with "ERROR: Failed to set file permissions on usr/bin/sudo.apk-new: Permission denied" 2017-06-23 00:38:34 hmm 2017-06-23 00:38:45 sounds like an odd fs permissions issue 2017-06-23 00:38:48 is it mounted as nosuid? 2017-06-23 00:39:10 yep, bingo. 2017-06-23 00:40:26 what's a bit strange is that other apk's work fine. 2017-06-23 00:40:36 (except for abuild, which has similar error) 2017-06-23 00:48:56 we have little suid packages as per policy 2017-06-23 00:49:03 as it's a security risk 2017-06-23 00:55:45 so this is failing for me only inside a chroot. Works fine outside. 2017-06-23 01:04:46 may be a grsecurity restriction 2017-06-23 01:23:11 Shiz: yup that was it. Rebooted into linux-vanilla and problem no longer there. 2017-06-23 01:23:22 i think it's a sysctl you can change 2017-06-23 01:24:54 for my current purpose, running vanilla is fine. 2017-06-23 01:29:14 openssh won't build with jobs > 1 for some reason 2017-06-23 01:30:30 https://bpaste.net/raw/25f0a9337260 2017-06-23 01:44:50 i'm not sure running vanilla is ever preferable :P 2017-06-23 01:44:54 except for platforms without hardened 2017-06-23 01:45:32 foxkit: hmm 2017-06-23 01:45:33 I'm not sure running hardened is ever preferable :P 2017-06-23 01:45:38 btw re: your ML post 2017-06-23 01:45:47 I lined out an idea for alternatives in apk a while back 2017-06-23 01:46:14 Shiz: it would be very cool to just say 'this depends on /bin/sh being a thing, I don't care what that thing actually is' 2017-06-23 01:46:31 this can already be done afaik 2017-06-23 01:47:12 or maybe it was something that was upcoming... 2017-06-23 01:48:26 Shiz: additionally, I want /etc/shells to be dynamically updated based on the installed packages 2017-06-23 01:48:39 sounds like you just want a trigger 2017-06-23 01:48:41 :) 2017-06-23 01:49:10 Shiz: yeah, was thinking that each shell could put a file in /etc/shells.d/$shellname, then a trigger could run when /etc/shells.d is modified to regenerate /etc/shells 2017-06-23 01:49:48 although imo a better option would be to ditch /etc/shells entirely 2017-06-23 01:49:51 :p 2017-06-23 01:50:33 I agree that /etc/shells is useless 2017-06-23 01:51:07 also skarnet: no stackclash in hardened, for one 2017-06-23 01:51:09 ;p 2017-06-23 01:51:51 well, ssh still uses it, and it is annoying to manually edit it when I play with new shells 2017-06-23 01:52:25 with hardened, attackers can't segfault your programs. Programs naturally segfault on their own before any attackers can even come into the picture! 2017-06-23 01:52:38 then your program is buggy 2017-06-23 01:52:39 :P 2017-06-23 01:52:44 gentoo's solution is to put every possible shell you can install in /etc/shells but I think that is a terrible idea, not the least of which because it includes things in /usr/bin that you may never install, but if you use remote/container/whatever /usr, you may not be able to trust it 2017-06-23 01:52:47 foxkit: so we patch sshd 2017-06-23 01:54:06 that seems kind of silly, and I thought the idea was /not/ to patch software until it doesn't even resemble the software any more ala debian :P 2017-06-23 01:54:22 otherwise I have a list of changes to make to pretty much everything in base 2017-06-23 01:54:24 :p 2017-06-23 01:54:30 who said anything about that 2017-06-23 01:55:10 ncopa said it is preferred to have packages that resemble upstream as much as possible, and try to work with upstream to see what would be a way to get desired features/functionality in the upstream package 2017-06-23 01:55:15 otherwise it becomes a maintenance problem 2017-06-23 01:55:29 so we PR a UseShells option upstream 2017-06-23 01:55:31 :P 2017-06-23 01:55:55 so if UseShells is 'no', then it will let you run any application as your login shell? 2017-06-23 01:56:04 yes 2017-06-23 01:56:06 sure 2017-06-23 01:57:14 Shiz: if sshd is built with pam, then pam_shells.so takes care of it, so you just don't put that in an 'auth' line for /etc/pam.d/sshd 2017-06-23 01:57:22 right 2017-06-23 01:57:25 but our sshd isn't 2017-06-23 01:57:29 :P 2017-06-23 01:57:51 Alpine does not use PAM because PAM is fucking stupid 2017-06-23 01:57:55 Shiz: it would be, if this was not broken: https://git.alpinelinux.org/cgit/aports/tree/main/openssh/APKBUILD#n17 2017-06-23 01:58:26 but it does things like calling ./configure ./configure which it says "invalid machine type" 2017-06-23 01:58:34 and then LDFLAGS is not properly quoted 2017-06-23 01:58:36 pam is everything you don't want in security 2017-06-23 01:59:04 foxkit: even then, it wouldn'tbe 2017-06-23 01:59:12 openssh-server-pam would be, though 2017-06-23 01:59:14 :P 2017-06-23 01:59:15 Shiz: it would be an option 2017-06-23 01:59:27 death to PAM 2017-06-23 01:59:43 Shiz: what I am saying is this is already an option and I don't know if OpenSSH would really care enough to add an option to sshd_config. but you can always ask them 2017-06-23 01:59:51 and we should quit using linux-pam for cases where compatibility is wanted 2017-06-23 01:59:54 openssh doesn't like pam either 2017-06-23 02:00:02 they're bsd guys 2017-06-23 02:00:05 OpenPAM has a much better security record 2017-06-23 02:00:07 of course they don't like pam 2017-06-23 02:00:09 :P 2017-06-23 02:00:27 kaniini: different implementation, same broken architecture 2017-06-23 02:00:38 well i don't like PAM because it's stupid 2017-06-23 02:00:51 OpenBSD doesn't have PAM, but FreeBSD and NetBSD do, so it's more correct to say "they're openbsd guys" :P 2017-06-23 02:01:13 it literally is dlopening BS into the app 2017-06-23 02:01:23 foxkit: freebsd and netbsd don't like pam either 2017-06-23 02:01:24 fucking crazy shit right there 2017-06-23 02:01:25 generally 2017-06-23 02:01:27 :P 2017-06-23 02:01:40 freebsd use PAM as part of the core system 2017-06-23 02:01:44 what are you talking about 2017-06-23 02:01:57 ^ yeah, calling BS on this one lol 2017-06-23 02:02:08 worse than i thought then 2017-06-23 02:02:10 FreeBSD isn't the smartest one in the pack either 2017-06-23 02:02:33 what worries me more is why openpam simply doesn't use a proxy process for the .so loading 2017-06-23 02:02:35 a more sensible design 2017-06-23 02:02:50 openbsd's alternative is interesting and even has some support in i.e. apache/nginx, but meh 2017-06-23 02:02:59 because PAM is junk 2017-06-23 02:03:13 well 2017-06-23 02:03:15 it's sun 2017-06-23 02:03:17 of course it's junk 2017-06-23 02:03:27 i'm having toruble finding a single good contribution solaris made to unix 2017-06-23 02:03:34 /sunos 2017-06-23 02:03:47 SMF wasn't bad 2017-06-23 02:04:33 pfexec was one of the first RBAC things that actually worked 2017-06-23 02:04:54 which I still argue is a better idea than unix groups :/ 2017-06-23 02:07:53 anyway, my point was not really to start a discussion on the merits of pam or openssh, my point was simply that it would be nice to have a way to swap what /bin/sh is 2017-06-23 02:08:52 whether that is dash or bash or busybox ash or zsh or pdksh or heirloom or fish or whatever the cool kids are using today, it is the user's system to use and/or abuse, and there are plenty of packages that assume /bin/sh is just bash on a linux system unfortunately 2017-06-23 02:10:06 IIRC /etc/shells is just "what adduser will accept to put in the shell field of /etc/passwd" 2017-06-23 02:10:28 so that's not even relevant to what /bin/sh points to 2017-06-23 02:11:45 that was a semi-related nugget of work I am also working on, that's all 2017-06-23 02:12:02 mmm... nuggets 2017-06-23 02:13:07 foxkit: which ties bak to my prpoposal about alternatives 2017-06-23 02:13:09 :) 2017-06-23 02:16:11 https://txt.shiz.me/ZDNkNTY3MD 2017-06-23 02:16:13 found it 2017-06-23 02:27:08 Shiz: this is nice but I would suggest one more thing: apk select -L or something, to list all available providers of 2017-06-23 02:27:15 Shiz: otherwise I support this +1 2017-06-23 02:46:03 https://bpaste.net/raw/6b0b3c015767 2017-06-23 03:07:14 gcc also fails bootstrap.sh (at least for ppc) when JOBS is > 1... 2017-06-23 03:07:24 that is weird, because gcc /should/, in theory, support parallel make 2017-06-23 03:07:45 it is breaking in the Ada stuff, so I'm just going to assume that there hasn't been sufficient testing by the GCC team with that part of the codebase 2017-06-23 03:11:00 /bin/bash: gnatmake: command not found 2017-06-23 03:11:03 /bin/bash: ./xsinfo: No such file or directory 2017-06-23 03:11:05 make[2]: *** [/home/awilcox/aports/main/gcc/src/gcc-6.3.0/gcc/ada/Make-generated.in:45: ada/sinfo.h] Error 127 2017-06-23 03:11:07 never mind, it is breaking with JOBS=1 too 2017-06-23 03:11:10 it just takes a lot longer to fail 2017-06-23 03:13:19 it looks like the error is that gcc-gnat in addition to gcc-gnat-$ARCH is required to build Ada stuff 2017-06-23 03:13:22 but let me check that 2017-06-23 03:21:29 yes that was the problem 2017-06-23 03:44:45 balls 2017-06-23 03:44:59 i still need to do 3.3 backports 2017-06-23 03:45:54 Shiz: what is your opinion on having a formal security group to serve as contact so we can get on the distro list 2017-06-23 06:26:02 Shiz, Jirutka, is it possible to compile something with our current rust targeted at arm32? 2017-06-23 06:52:48 kaniini, apk commit: version: consider pkg-rX and pkg to be the same version 2017-06-23 06:52:52 breaks test suite 2017-06-23 06:53:30 well, it does not fail, but it gives now failure prints 2017-06-23 06:53:58 i'm not sure if i like the new progress bar either :/ 2017-06-23 06:57:49 the old progress bar with the change made for serial consoles didn't look very good on non-serial consoles anymore (it was always off by one) 2017-06-23 07:01:31 i revert pkg-rX and pkg same version thing 2017-06-23 07:08:22 ok, we may need to have a syntax to do that, but i thought ~ was intended for that 2017-06-23 07:08:44 yes, it is obsoleted by ~ 2017-06-23 07:08:48 that's why i reverted it 2017-06-23 07:10:07 ok. thanks. 2017-06-23 07:10:15 i did stable branches, and pushed couple of fixes 2017-06-23 07:10:21 tagging new releases and pushing them out 2017-06-23 07:10:33 apk-tools was vulnerable stack clash ? 2017-06-23 07:10:35 geez 2017-06-23 07:11:10 no 2017-06-23 07:11:13 heap overwrite 2017-06-23 07:12:45 ah yes i see 2017-06-23 07:16:32 kaniini, with aslr, it's DoS at most; if someone turned it ever off, it's remote code execution if the attacker knows enough about the system :/ 2017-06-23 07:16:53 and one needs MitM or compromised apk repository 2017-06-23 07:17:07 so it's not easily exploitable in realworld... but kinda nasty though 2017-06-23 07:17:18 another reason why i want to get rid of tar format... 2017-06-23 07:17:28 tar is not the simplest to parse safely 2017-06-23 07:18:13 indeed 2017-06-23 07:18:39 ok, all supported branches should be updated 2017-06-23 07:18:54 hope i did not introduce any regressions ;) 2017-06-23 07:18:59 i did do some testing though 2017-06-23 07:19:04 and reviewed the patches several times 2017-06-23 07:19:40 i looked at the patches as well, and they seem okay 2017-06-23 07:20:18 moving the i/o vtable off heap was good thinking 2017-06-23 07:21:54 yeah, the guy said that's the pointer he managed to overwrite 2017-06-23 07:22:07 so now RELRO keeps it safe too 2017-06-23 07:22:39 he did a "tmux demo" on remote code execution when ASLR is turned off... 2017-06-23 07:23:00 inside docker with mitm for alpine repo 2017-06-23 07:23:17 sweet 2017-06-23 07:23:36 since root inside docker = root outside docker, root entire box ;) 2017-06-23 07:24:12 in the new index format this will not be possible, as the plan is to download+unpack only on "update"; and then as first thing do signature verification without parsing any data 2017-06-23 07:24:31 isolating signature verification as first step solves many things 2017-06-23 07:24:42 with tar+headers it's not possible so simply 2017-06-23 07:24:51 (we should probably document best practices for running docker with alpine, both as container and host, since there are ways to make root inside docker != root outside docker) 2017-06-23 07:26:32 but i am happy that some security eyes have started looking at apk, and fuzzing it too 2017-06-23 07:26:50 and getting basically only one issue (the both CVEs share same common root issue) is kinda good :) 2017-06-23 07:27:00 if you want, i can throw afl at it on my big machine over weekend :) 2017-06-23 07:30:53 s 2017-06-23 09:10:35 hey so, ca-certificates doesn't build because the URL is a 404 now, probably needs a bump... was it not being bumped because of the startcom thing? 2017-06-23 09:11:05 also I worked with upstream to bring python3 support so it doesn't need to have python2 specifically in makedepends... is there a way to say 'any python' or should it just be changed to python3? 2017-06-23 09:13:19 hmm.. it looks like it is a debian patchlevel thing... 20161130+nmu1 2017-06-23 11:12:44 foxkit: yes ca-certs needs an update 2017-06-23 11:12:52 because they deleted the old release :/ 2017-06-23 11:13:02 no way to say any python, but we prefer pthon3 if possible anyway 2017-06-23 11:13:13 kaniini: in favor 2017-06-23 11:13:15 re:security 2017-06-23 11:13:22 this is why i created that gpg-remailer thing 2017-06-23 11:13:28 ncopa & clandmeter know more 2017-06-23 11:13:44 clandmeter: in theory, yes 2017-06-23 11:13:51 someone would just need to do the initial cross-compile 2017-06-23 17:37:39 Shiz, Lets pick that ASAP 2017-06-23 17:38:03 Re seclist 2017-06-23 17:59:56 The travis builds for aports are failing due to a 404 during the alpine install (for pull requests), not sure why 2017-06-23 18:05:49 clandmeter: ball's in your court :P 2017-06-23 18:10:40 I know, but I'm enjoying the weather atm :p 2017-06-23 21:34:11 travis needs an apk update - it's trying to grab apk-tools-static-2.6.8-r2.apk (& not 2.6.9) 2017-06-23 23:39:18 BitL0G1c: I’ve fixed it, and finally once for forever :) 2017-06-23 23:42:51 ;-)ok great 2017-06-23 23:43:42 foxkit: I disagree with allowing to set /bin/sh to bash; it’s just wrong and would most likely make a lot of harm to portability; I also remember that some guy from VoidLinux (or Arch?) warned me exactly against this 2017-06-23 23:46:43 jirutka: I am not saying it should be a distro thing, but user should be allowed to pick what they want for /bin/sh. it is not the distro's job to dictate what the user should be using for shell scripts imo. anyway, that's an Adélie thing, it does not need to be merged to Alpine 2017-06-23 23:47:04 just nope 2017-06-23 23:55:36 I mean, you can swap out fs layout, dunno why you can't swap out /bin/sh 2017-06-23 23:57:16 you can even swap out the kernel :D 2017-06-24 00:04:36 i'm okay with /bin/sh being configurable 2017-06-24 00:05:11 im okay with alternatives existing which would allow to do this cleanly 2017-06-24 00:05:13 :P 2017-06-24 00:05:21 (the laternatives mechanism) 2017-06-24 00:05:33 yes 2017-06-24 00:05:38 precisely 2017-06-24 00:08:55 foxkit: out of curiosity, in what ways are busybox sh deficient 2017-06-24 00:09:18 it's an almquist family shell, and posix literally defines the almquist shell as a spec basically 2017-06-24 00:14:24 I fully support “alternatives” feature, we really need it, but don’t really wanna solve obscure problems when ppl change default shell to some crap like bash 2017-06-24 00:14:36 also ask VoidLinux what they think about it… 2017-06-24 00:14:59 but I don’t remember details of their case, what problems it caused 2017-06-24 00:16:50 gn 2017-06-24 00:38:40 kaniini: I have not run the test suite against busybox sh, but I never said it was deficient. it is probably fine as a POSIX sh, for all I know. but there are many scripts that rely on 'bashisms' that use incorrect #!/bin/sh. so if $random_user has a lot of these scripts, they should be able to swap it out. it is purely for user benefit 2017-06-24 00:38:56 as Shiz says 2017-06-24 00:39:01 it should be an 'alternatives' type thing 2017-06-24 00:40:22 sure. however i think busybox sh should be the default as it is a fast, robust almquist shell and vda does care about posix compliance 2017-06-24 00:41:00 the ummm 2017-06-24 00:41:25 other busybox components aren't the greatest but the busybox sh is quite decent in my experience 2017-06-24 00:42:24 makes total sense to me 2017-06-24 00:43:02 and in general, the busybox devs will pretty much implement whatever we want if we show up with patches 2017-06-24 01:02:43 am trying to "abuild" a package but getting 404 error fetching the source. Is there a way to print the URL it's trying to fetch? 2017-06-24 01:24:52 ok finally got it... by sniffing the network, ugh. 2017-06-24 05:44:53 is there any way to ask apk what repo an installed package came from? can't seem to find it in `apk info` 2017-06-24 05:57:41 apk policy 2017-06-24 06:01:20 ah perfect, thank you! 2017-06-24 10:04:30 Hi, I have a short question. libc selection is not a priority task but ultimately important for the system I work on. According to musl themselves, at least on the libc comparison chart and the wiki, there is no aarch64/armv8 support. How did you manage to get aarch64 support for your build infrastructure? Is the information I have outdated and musl does fully support aarch64 now? 2017-06-24 10:51:48 ng0: there is aarch64 support 2017-06-24 10:51:53 that chart may be outdated then 2017-06-24 10:53:25 Oh, that's good. Thanks! 2017-06-24 10:54:39 current musl git supports arm, aarch64, x86, microblaze, mips, mips64, mipsn32, or1k, powerpc, powerpc64, s390x, sh, x32 and x86_64 2017-06-24 10:54:47 and i think someone was working on riscv 2017-06-24 10:56:53 My ideal scenario would be multiple libc support, but before we get there focusing on one alternative libc is the way to go. May I ask what made you switch from uclibc-ng to musl? Smaller binary size? 2017-06-24 10:57:23 we never used uclibc-ng 2017-06-24 10:57:37 oh, so it was just uclibc then? 2017-06-24 10:57:38 we used the original uclibc, which was dead and patched in alpine to the point that it was effectively a fork 2017-06-24 10:57:57 okay, then I can understand the burden of maintenance 2017-06-24 10:58:24 personally I'd still pick musl over uclibc-ng, though :P 2017-06-24 10:58:30 ^ 2017-06-24 10:58:31 since I think it fits our goals better 2017-06-24 10:58:36 small, simple, secure, (and correct) 2017-06-24 10:58:40 moreso than uclibc-ng 2017-06-24 10:59:17 I don't know the uclibc-ng people, but I know the musl people and their dedication to correctness and life of the project is impressive, and what I would like to see in basically every open source project 2017-06-24 11:00:15 my experience with musl is limited to the years where I used Gentoo and the impression I have is that musl builds require more patches to be carried around than uclibc-ng. Of course one consideration in my design is size and security aswell. 2017-06-24 11:00:51 it's likely, if uclibc-ng was designed to be bug-compatible with uclibc or glibc 2017-06-24 11:00:55 i think uclibc(-ng) tries to implement more fundamentally broken stuff than musl does for compatibility reasons 2017-06-24 11:01:10 but it has to be said that in my experience gentoo-musl isn't the greatest indicator 2017-06-24 11:01:17 since last i tried that it was broken on all sides :P 2017-06-24 11:01:20 which was admittedly 1+ year ago 2017-06-24 11:01:34 ng0: upside of distros like alpine is that you can lift patches from us :P 2017-06-24 11:01:40 and we try to upstream our compat patches in general 2017-06-24 11:02:29 ncopa held a FOSDEM presentation on it that may be relevant 2017-06-24 11:02:39 I was just looking for that 2017-06-24 11:02:47 https://fosdem.cu.be/2017/K.4.601/building_a_distro_with_musl_libc.mp4 2017-06-24 11:03:03 https://fosdem.org/2017/schedule/event/building_a_distro_with_musl_libc/ for the slides too 2017-06-24 11:05:06 alternative libc comes in at somewhere before what in numbers could be considered 1.0, so it's a bit down the road. At the moment it's just a very small team with most of the work done by myself and upstream almost 100% to the parent system, so the cost in time to move relevant packages from glibc to musl and effectively go from 'fork in some logical and technical choices' go to completely fork it and 2017-06-24 11:05:08 maintain all the differences. 2017-06-24 11:05:21 incomplete sentence 2017-06-24 11:05:28 the time factor is important 2017-06-24 11:05:53 I'll watch the videos soon, thanks 2017-06-24 11:08:08 *video 2017-06-24 16:28:48 https://www.phoronix.com/scan.php?page=news_item&px=Intel-CET-GCC-Patches 2017-06-24 17:08:40 Shiz: apparently gentoo-hardened new plan is to "fork pax" and try to "pool talent with Alpine" 2017-06-24 17:08:44 can't WAIT 2017-06-24 17:47:31 I follow thread on oss-security, Linus vs. Spengler… I have strong urge to replace hardened kernel with vanilla instantly 2017-06-24 17:48:52 Spengler looks like definition of dickhead itself… search it in dictionary and there will surely be his picture 2017-06-24 17:50:29 jirutka: can you share the link? 2017-06-24 17:53:19 it starts here http://www.openwall.com/lists/oss-security/2017/06/24/1 2017-06-24 17:53:28 the next msg in thread is Linus’ respond 2017-06-24 17:53:35 *response 2017-06-24 18:04:22 I wanted to watch some movie this evening, but this seems to be much more entertaining ;f 2017-06-24 18:09:45 XD 2017-06-24 20:59:33 kaniini: i still see no direct issues with linux-hardened 2017-06-24 21:10:56 jirutka: the people who stroke spender ego too 2017-06-24 21:11:05 jirutka: are the fucking worst 2017-06-24 21:11:33 grsec 'advocates' tend to be abusive jerks 2017-06-24 21:11:47 see also them demanding solutions from us when spender pulled the plug 2017-06-25 00:05:51 Shiz: as for the downside of strcat linux-hardened 2017-06-25 00:06:02 Shiz: if we endorse it, alpine is officially taking a side in this thing 2017-06-25 00:06:14 Shiz: which means we're going to take a lot of flames from spender 2017-06-25 00:06:28 spender already hates us 2017-06-25 00:06:35 for having our own grsec forward port 2017-06-25 00:06:41 i literally do not give a fuck about what he things of this 2017-06-25 00:06:44 oh has he said so? 2017-06-25 00:06:50 i heard so from strcat, at least 2017-06-25 00:06:58 it's not that i care about what he thinks, it's about the harrassment 2017-06-25 00:07:15 1sec 2017-06-25 00:07:30 on the other hand, i'm presently living in the US, and if he harrasses us i can probably have criminal actions brought against him 2017-06-25 00:07:47 but that requires effort 2017-06-25 00:08:29 at the very least i would advise that alpine-infra team block spender from being able to post to our lists (actually i think we already did this but i forget) 2017-06-25 00:10:16 as an aside, spender is definitely on a self-destructive path with this crap, i know quite a few people who have already cancelled their grsecurity subscriptions over the harrassment 2017-06-25 00:11:18 kaniini: I need to introduce you to a friend of mine at some point 2017-06-25 00:13:44 Shiz: i mean, i don't know that spender hates us because as of yet, we haven't been harrassed by him. on the other hand, he probably has some doppelganger in this channel 2017-06-25 00:13:54 the guy is seriously mental 2017-06-25 00:14:10 kaniini: 2017-06-25 00:14:11 2017-06-03 21:02:02 Shiz we're 1) too small 2) have already been forward-porting grsec stuff for years 2017-06-25 00:14:18 like i suggest seeking help 2017-06-25 00:14:19 2017-06-03 21:02:09 @strcat Shiz: he was pissed about 2) 2017-06-25 00:14:20 ;) 2017-06-25 00:14:27 2017-06-03 21:02:21 @strcat he said it in #grsecurity 2017-06-25 00:14:35 good i am glad he is pissed that we have kept grsecurity stable branch alive 2017-06-25 00:14:36 LOL 2017-06-25 00:14:58 well, testing branch 2017-06-25 00:15:00 ;p 2017-06-25 00:15:06 we did it with stable branch for a while 2017-06-25 00:15:19 and in general what we're actually shipping is pretty stable 2017-06-25 00:16:02 so i can see how we might be bad for business 2017-06-25 00:16:57 Shiz: i am not really understanding why he is pissed about that 2017-06-25 00:17:01 because 2017-06-25 00:17:02 ¯\_(ツ)_/¯ 2017-06-25 00:17:07 grsecurity branding, or whatever 2017-06-25 00:17:09 probably 2017-06-25 00:17:57 but we dropped the grsecurity branding, and if he had reached out i would have done it much sooner 2017-06-25 00:18:23 yes, but thesel ogs are from 3+ weeks ago, and since it mentions #grsecurity it was several weeks before THAT 2017-06-25 00:18:27 so likely before we changed to -hardened 2017-06-25 00:18:38 since #grsecurity is closed now 2017-06-25 00:19:01 also: 2017-06-25 00:19:03 2017-06-03 21:02:42 @strcat although as I found out he didn't consider that public 2017-06-25 00:19:05 so :idk: 2017-06-25 00:19:23 consider the alpine forward ports public? 2017-06-25 00:19:27 because they're not 2017-06-25 00:19:28 oh wait, that was a statement about #grsecurity 2017-06-25 00:19:36 not about the forward ports 2017-06-25 00:19:55 i mean you can go dig and find out how to get the patches if you really want 2017-06-25 00:20:09 but the repo used for generating them right now is not public 2017-06-25 00:20:23 which we explicitly did because we did not want the drama 2017-06-25 00:20:52 (which in its own turn is not very hard either) 2017-06-25 00:21:00 ncopa tried to explain the process to me and it was identical to what i already was doing 2017-06-25 00:21:02 :P 2017-06-25 00:21:04 basic git 2017-06-25 00:21:35 yes 2017-06-25 00:21:40 it's not exciting 2017-06-25 00:21:46 regardless 2017-06-25 00:21:55 however, there's a few reasons why we're not open with that machinery 2017-06-25 00:21:59 i would not be opposed to working with gentoo-hardened and linux-hardened folks on something 2017-06-25 00:22:03 1) we don't want to really interact with spender 2017-06-25 00:22:07 as i think it's the only viable option as of right now 2017-06-25 00:22:25 2) we don't want to interact with grsecurity advocate trolls 2017-06-25 00:22:35 (if you missed it, they are not the most pleasant people on the planet) 2017-06-25 00:24:37 Shiz: i agree, but i don't really want to deal with harrassment from spender, and he is doing targeted harrassment against that entire group 2017-06-25 00:25:01 maybe i will be more interested when spender is involuntarily committed to a psych ward 2017-06-25 00:25:58 sean: who? 2017-06-25 00:30:54 Shiz: also, i mean, i don't know that i believe in security work done by somebody whose nickname is one of the most insecure functions in the standard C library 2017-06-25 00:30:57 (: 2017-06-25 01:28:43 kaniini: work with me! 2017-06-25 01:29:30 no, you're only around because POSIX still hasn't gotten rid of you yet 2017-06-25 01:29:34 :) 2017-06-25 02:34:25 lol on some forum i saw this: 2017-06-25 02:34:33 "Man, think of the effects that this could have in the Linux sphere. Subgraph? Dead. Alpine? Dead." re: grsec closure 2017-06-25 02:34:40 WE STILL SEEM TO BE HERE JUST SAYIN 2017-06-25 03:16:26 lol 2017-06-25 06:49:05 http://www.openwall.com/lists/oss-security/2017/06/25/1 aw yis 2017-06-25 07:37:47 python3 seems to have few problems, first one is: configure: WARNING: unrecognized options: --disable-rpath, --enable-optimize, --enable-lto 2017-06-25 07:38:25 second one is currently I am building packages in a chroot. the host system is 64-bit Debian, the chroot is 32-bit Alpine, but it says: checking host system type... powerpc64-unknown-linux-gnu 2017-06-25 07:39:49 this is definitely not desireable. it should be using --build --host like any other 2017-06-25 07:39:56 scadu, is there a reason python3 does not? 2017-06-25 07:46:11 foxkit: it seems that --build and --host were never here. 2017-06-25 07:58:22 foxkit: I think we could add those. let me check and I will send a pr, but someone has to do a review and eventually push 2017-06-25 12:50:31 foxkit: I'll get rid of --disable-rpath and correct names for the others. --build and --host will be included in configure, too. 2017-06-25 13:15:29 not sure if we should keep --with-lto and --enable-optimizations. it gives some performance boost, but build time is much longer 2017-06-25 13:17:24 well, "keep" -- it seems they weren't even active 2017-06-25 13:19:35 I see that Fedora and Arch builds python3 with those options 2017-06-25 13:34:48 re: http://www.openwall.com/lists/oss-security/2017/06/25/2 -- doing https on the repo mirrors may be useful after all 2017-06-25 14:14:21 naw 2017-06-25 14:14:42 not using tar for apkindex is the fix there 2017-06-25 14:22:11 scadu: he whines too much 2017-06-25 14:31:05 kaniini: yeah, maybe. 2017-06-25 14:31:52 hm, what do you think about splitting py3-pip? it's currently provided by python3 package, while it's splitted in case of python2 2017-06-25 14:43:00 mkay, it's useless due to ensurepip provided with python3 2017-06-25 14:55:35 the broader idea is that parsing bugs pr-everification may happen anyway 2017-06-25 15:11:22 Do you all have seccomp working? 2017-06-25 15:15:04 seccomp is difficult to make work reliably across distributions. If an app tailors it for glibc, it needs to be retailored for musl. See an explanation here: https://github.com/kristapsdz/acme-client-portable/blob/master/Linux-seccomp.md 2017-06-25 15:15:38 as such, it's not an easy to use security mechanism. 2017-06-25 15:24:59 i personally feel seccomp is the wrong layer of abstraction to make 2017-06-25 15:25:22 something like BSD's pledge makes more sense, where you leave it up to the library that uses the syscalls to determine what syscalls to whitelist 2017-06-25 15:25:40 because otherwise, you're just very vulnerable to changes in your libc w.r.t. which syscalls it makes 2017-06-25 15:25:44 be it switching out libcs or upgrading them 2017-06-25 15:27:02 it's something that can be built on top of, though 2017-06-25 15:27:19 Anarchy: by 'working' do you mean 'functioning in alpine' or 'applied to packages as policy'? 2017-06-25 15:27:30 because while I suspect the former may be true, the latter is definitely not right now 2017-06-25 15:50:49 pledge definitely makes a lot more sense 2017-06-25 15:51:14 BSD people often have good ideas, the problem is making them care for the rest of the world :P 2017-06-25 15:57:42 okay bye 2017-06-25 19:07:05 heh, seems the other post on oss-security today besides the apk one is Spender burning the rest of the bridges 2017-06-25 19:08:55 not that there was much left to burn ... 2017-06-25 19:48:14 I watched the fossdem talk you pointed me to, thanks. I think this is doable for my system and worth the added effort (and added fork). It might add a tiny little slightly increased time to my original estimation of when the system is ready, but it's worth the months. 2017-06-25 22:08:19 "also consider HPKP" lol, because libfetch totally cares/remembers pinned public keys 2017-06-25 22:11:26 scadu: I think it is worth it for lto. I added it to custom build for myself once and saw a 30% speed boost in some parts of the stdlib. very nice. 2017-06-25 22:12:17 scadu: meanwhile, if something should be split, it should be tkinter like python2's. right now python3 deps on tk, which deps on python2, so you get the silly result of requiring python2 to build python3 2017-06-25 22:12:46 and, assuming tk is upgraded to use python3 some day, then that would be a build cycle (python3->tk->python3) 2017-06-25 22:14:59 foxkit: https://github.com/scadu/aports/commits/python3 the last two commits 2017-06-25 22:15:35 hm, actually I could send a pr if it's okay 2017-06-25 22:16:13 scadu: great, thank you. I will apply locally until an Alpine dev puts it in Alpine itself 2017-06-25 22:16:36 I'll try to take a look at tk this week, but I don't promise anything. I'm in the middle of moving, so… 2017-06-25 22:18:14 I understand, no worries :) 2017-06-25 22:35:32 foxkit: pr sent. 2017-06-25 22:35:32 and now I'm going to bed 2017-06-25 22:35:35 'night 2017-06-25 22:35:42 sleep well 2017-06-25 22:45:35 this is a fun one 2017-06-25 22:46:05 somehow, apk is 'missing' a few directories in this .apk file (perl 5.26.0 compiled for ppc32) 2017-06-25 22:46:28 it extracts the files as .apk-new, but never renames them or even checks to see if it needs to, it doesn't list them in owned files, and it doesn't remove them on `apk del` 2017-06-26 00:08:51 foxkit: what does apk manifest (use apk-tools git) say about the file 2017-06-26 00:31:28 kaniini: https://bpaste.net/raw/d7c2a1a87236 it has all the correct files/dirs listed 2017-06-26 00:39:58 WEIRD 2017-06-26 00:51:05 applying https://bpaste.net/raw/b603b23230ec to apk yields https://bpaste.net/raw/95e04742b46d 2017-06-26 01:09:57 add strerror tbh 2017-06-26 01:11:43 ENOENT 2017-06-26 01:12:52 strace it 2017-06-26 01:12:54 lol 2017-06-26 01:13:11 I did 2017-06-26 01:13:35 usr/share/perl5/core_perl/Net/A.pm 2017-06-26 01:13:37 is really 2017-06-26 01:13:40 usr/share/perl5/core_perl/Net/FTP/A.pm 2017-06-26 01:13:56 Queue.pm is really Thread/Queue.pm, ExtUtils/MM.pm is really ExtUtils/Command/MM.pm 2017-06-26 01:14:16 somehow it is attaching these couple dozen files to their parent directory instead of the correct one 2017-06-26 01:14:26 it installs them in the correct place as .apk-new 2017-06-26 01:14:39 i.e. I have ExtUtils/Command/MM.pm.apk-new in my sysroot 2017-06-26 01:19:45 https://bpaste.net/raw/152078048790 2017-06-26 01:23:05 file->diri->dir != dir, somehow 2017-06-26 01:30:15 <^7heo> wasn't it *dir->diri->dir != *dir? 2017-06-26 01:48:36 no, dir itself is consistent 2017-06-26 01:48:43 but somehow file is attached to two dirs at once 2017-06-26 01:48:53 and since it is already processed once, it is never processed in the right dir 2017-06-26 01:49:00 but I don't know how it's possible that even happened 2017-06-26 01:54:50 <^7heo> anyway 2017-06-26 01:54:52 <^7heo> it's 4AM 2017-06-26 01:54:54 <^7heo> I need sleep 2017-06-26 01:54:55 <^7heo> o/ 2017-06-26 01:55:42 night! 2017-06-26 01:57:17 it was interesting to read that docker uses apline as its production image I was not aware 2017-06-26 01:59:16 <^7heo> arch3y: what is the main reason why alpine has so much popularity 2017-06-26 02:00:58 probably due to its lightweight and secure by design nature 2017-06-26 02:01:20 Im not 100% sure honestly I have been playing around with it, but I dont use it all the time 2017-06-26 03:16:27 well, I found the bug 2017-06-26 03:32:06 and? 2017-06-26 03:43:01 on ppc32, tar does not order files and directories 2017-06-26 03:43:06 so it goes like 2017-06-26 03:43:13 usr/share/perl5/core_perl/Thread (dir) 2017-06-26 03:43:18 usr/share/perl5/core_perl/CPAN (dir) 2017-06-26 03:43:24 usr/share/perl5/core_perl/autodie.pl (file) 2017-06-26 03:43:34 usr/share/perl5/core_perl/Thread/Semaphore.pm (file) 2017-06-26 03:43:53 apk is saving each dir that it hits, and putting all files inside that dir until it hits another dir 2017-06-26 03:44:00 I don't know if that's portable and tar is the one messing up 2017-06-26 03:44:15 or if that isn't portable, and apk just happened to work all these years because it never tried to work on ppc32 2017-06-26 03:44:55 note that it is putting them in the correct place on the FS because it uses the raw string from tar as the place to put it 2017-06-26 03:45:03 but the internal index has files owned in very wrong places 2017-06-26 03:45:44 the perl interpreter lives at usr/lib/perl5/core_perl/Encode/MIME/perl, for instance 2017-06-26 03:45:51 not usr/bin/perl 2017-06-26 03:47:00 it looks like tar may actually be trying to save space and/or time on ppc32 by grouping a bunch of small direntries at the beginning of the archive, before all the files come out 2017-06-26 03:47:51 note that apk_db_install_archive_entry is doing the right thing by pulling diri out itself based on the directory string, but it is doing the wrong thing by not updating ctx->file_diri_node 2017-06-26 03:52:41 I do not know if this is proper or correct or if there's a better way or what, but https://code.foxkit.us/adelie/apk-tools/commit/8fb87ba38e48195c3d5ca4fc7612dbada235acf1 has fixed it locally 2017-06-26 03:55:32 yes the better way is "don't use tar" or whatever, idk lol, making a custom nih format seems like it will just have the same kind of bugs but without the benefit of already being a very well known format that is easy to hexdump and inspect 2017-06-26 03:55:54 it is a shame that libarchive is so huge and bloaty, because really, it'd be better to use something like it 2017-06-26 04:14:13 are you using busybox tar or gnu tar 2017-06-26 04:14:27 it may be a gnu tar problem (: 2017-06-26 04:19:04 abuild isn't compatible with busybox tar 2017-06-26 04:19:10 it requires GNU tar 2017-06-26 04:19:13 I ported it to BSD tar 2017-06-26 04:19:17 which never orders, on any platform 2017-06-26 04:19:24 so I stopped using it when I got weird errors 2017-06-26 04:19:28 but now GNU tar is doing it on ppc32 2017-06-26 04:19:35 so I'm just going to use that oneliner and use BSD tar 2017-06-26 04:19:45 since it is more portable and frankly I trust it more 2017-06-26 04:20:25 kaniini: busybox tar does not support --xattrs, nor does it generate pax format archives so the checksum is mangled by it 2017-06-26 04:21:17 I looked in to adding pax format + xattr support to busybox tar, but found it much easier to just libarchive/bsdtar, but like I said, it never orders either, so it gave me errors, so I just gave up and went back to gnu tar, but now gnu tar is doing it, so yeah 2017-06-26 04:21:20 bsdtar it is 2017-06-26 04:22:21 aha 2017-06-26 04:22:43 actually this may be a security bug 2017-06-26 04:23:02 consider a tar with: 2017-06-26 04:23:05 dirent: /etc 2017-06-26 04:23:16 file: /usr/share/examples/shadowutils-1/passwd 2017-06-26 04:23:24 apk writes /etc/passwd 2017-06-26 04:23:27 it still installs to the correct place, it just isn't owned properly 2017-06-26 04:23:32 ohh 2017-06-26 04:23:34 the package would 'own' /etc/passwd but it would not write to it 2017-06-26 04:23:39 which is messed up, but 2017-06-26 04:23:43 well that is less bad 2017-06-26 04:24:06 now if you managed to write a file called /etc/passwd.apk-new, THEN you could overwrite /etc/passwd when it tries to do the renameat 2017-06-26 04:24:15 but if you already have +w to /etc, you have bigger problems 2017-06-26 04:53:20 hey 2017-06-26 04:53:27 using apk-tools git, I have the new utf-8 progress bar 2017-06-26 04:53:30 looking good 2017-06-26 05:04:50 what is the armv5 port going to target? just general devices? 2017-06-26 05:05:08 the only thing I can think of with ARMv5 is the nintendo handhelds (GBA/DSi) 2017-06-26 05:35:41 its a secret 2017-06-26 05:37:35 https://www.twistlock.com/2017/06/25/alpine-linux-vulnerability-discovery-code-execution-pt-1-2/ kek, we are so famous 2017-06-26 06:41:29 scadu, sigh. his "critical" is exaggeration. it's not exploitable in normal conditions. but yes, it's still an issue. i guess they need to 'ramp up' the story always... 2017-06-26 06:46:50 fabled: I expect some trolls around soon :p 2017-06-26 06:46:55 yeah 2017-06-26 06:48:17 scadu, it basically requires for remote code execution: administrator turned ASLR off; AND attacker to know exact versions of packages the user is running; AND man-in-the-middle or compromised server 2017-06-26 06:48:38 otherwise it's just denial of service, which the attacker as if he can be mitm/control repository server 2017-06-26 06:48:56 but yeah, i'd categorize it a moderate issue 2017-06-26 06:50:46 imho, it was also only one bug; exploitable from two code paths. but the underlying bug was same in both cases. 2017-06-26 06:51:54 it wouldn't be so hard to know the package version assuming that the victim uses the latest stable or old(?) stable release. 2017-06-26 06:52:03 but ASLR off, well 2017-06-26 06:52:15 that's true. but ASLR should never be off 2017-06-26 06:53:19 but i'm happy that security people are looking at apk 2017-06-26 06:55:09 and Alpine in overall 2017-06-26 06:57:24 yes 2017-06-26 06:58:26 but the "security oriented" comes from hardening the toolchain defaults 2017-06-26 06:58:52 i think biggest difference is defaulting PIE everywhere. though some other distros have started doing that on selected cpu architectures. 2017-06-26 07:00:27 ugh 2017-06-26 07:00:28 hm, Void has PIE as default. they apply nopie flag only for some weird cases if there's no any sane solution atm 2017-06-26 07:00:42 now ruby is having weird dirent issues 2017-06-26 07:00:52 can tar stop being a pile of crap on ppc32, thanks :/ 2017-06-26 07:04:02 https://bpaste.net/raw/33dbf7f93e67 2017-06-26 07:05:47 scadu, yes, IIRC Ubuntu turned on PIE for e.g. x86_64; but not for x86 2017-06-26 07:06:23 gentoo is going to do PIE on all arches later this year 2017-06-26 07:06:34 but they're having lots of issues 2017-06-26 07:06:46 because their package tree is not in great shape 2017-06-26 07:09:38 but it's interesting that others follow now what we've been doing for 5+ years :) 2017-06-26 07:10:03 indeed 2017-06-26 07:10:25 but yes, the gap is getting smaller now 2017-06-26 07:10:36 and grsec going private, it's going to be even smaller 2017-06-26 07:10:51 biggest differences being musl and busybox being default 2017-06-26 07:10:54 and apk 2017-06-26 07:11:07 and no systemd 2017-06-26 07:11:40 fabled: you missed stuff prior to joining, would like your comment if you have free time: https://bpaste.net/raw/0678228a5532 2017-06-26 07:13:40 ew 2017-06-26 07:13:42 ok 2017-06-26 07:14:02 yes, i really want to _not_ do tar anymore :) 2017-06-26 07:15:25 I have three implementations of pax to test with if that is the way forward :D 2017-06-26 07:18:17 hum. i wonder is the commit from adelie really needed. it find_diri() should be updating the tail pointer 2017-06-26 07:21:43 foxkit, is file_diri_node out of sync? because if the directory changes, find_diri() updates the tail pointer 2017-06-26 07:22:13 fabled: https://bpaste.net/show/084af8d6d1de 2017-06-26 07:22:45 fabled: find_diri was not updating it in ctx 2017-06-26 07:23:15 diri = find_diri(ipkg, bdir, diri, &ctx->file_diri_node); 2017-06-26 07:23:18 fabled: that one-liner patch (the one from adelie git) fixes the ppc32 perl apk. do you want the apk file? you can play with it 2017-06-26 07:23:48 fabled: you might be able to understand/find the issue better than me. I have never touched database.c before today 2017-06-26 07:23:49 find_diri get's it as argument 2017-06-26 07:24:20 smells compiler bug to me 2017-06-26 07:24:41 it is alpine 6.3.0. I don't touch gcc package, too scary :P 2017-06-26 07:26:14 fabled: here is apk, it is for ppc, so you probably need to use --arch ppc. if you need musl package for ppc so that apk does not complain about missing dep I can provide that too https://distfiles.adelielinux.org/perl-5.26.0-r0.apk 2017-06-26 07:26:58 hum 2017-06-26 07:27:26 I can replicate the issue using x86_64 apk so it is not apk being non-portable. 2017-06-26 07:27:58 fabled: you can also apply https://code.foxkit.us/adelie/apk-tools/commit/5644012df62e0d09f12717a365f74795f030135b to see more errors 2017-06-26 07:28:26 that looks good 2017-06-26 07:28:46 though, that should not fail unless fs is broken, or user mounts it read only or similar 2017-06-26 07:28:59 or tar is broken, as in this perl package (at least on my systems) 2017-06-26 07:29:02 :P 2017-06-26 07:31:43 foxkit, applying with minor changes 2017-06-26 07:32:21 fabled: great, glad to harden apk against errors, even if it is minor corner case. 2017-06-26 07:37:42 foxkit, thanks, i am able to reproduce it, i'll look into it 2017-06-26 07:37:56 fabled: okay. thank you very much! 2017-06-26 07:38:15 oh 2017-06-26 07:38:31 ah, i know the problem now :/ 2017-06-26 07:38:54 no 2017-06-26 07:38:57 :-o 2017-06-26 07:55:30 foxkit, this should be the proper fix: http://sprunge.us/giSE 2017-06-26 07:57:03 but yeah, i am seriously thinking dropping tar, and doing internal format only. 2017-06-26 07:57:17 this is definitely needed for index; but i'd hope to reuse same format for the packages 2017-06-26 07:57:31 there's few subtle use-cases that more or less depend on it 2017-06-26 07:58:04 mostly related how i want the package/index signing to work, and that non-http indexes can be generated without signatures 2017-06-26 07:58:28 fabled: I can confirm this does appear to ffffffix it, thank yyyyou! 2017-06-26 07:58:40 sorry, ugh, x11 lag. this is my last glibc computer 2017-06-26 07:58:43 can't wait to replace it :P 2017-06-26 07:59:57 fabled: I find it very valuable to be able to use normal tools to inspect/view apk files, and since pax/tar is simple to understand I can even look in hex editor. maybe it is a silly thing to say, but I appreciate how 'open' and 'hackable' apk is right now. I would hate to lose that by making it some binary format. but I understand if it improves code quality I suppose. 2017-06-26 08:00:41 yes, that was the original motivation on using tar in first place 2017-06-26 08:01:00 but i'm having hard time figure out how to do few use cases with tar format 2017-06-26 08:01:28 I highly recommend looking at pax format (unrelated to PaX security thing), it allows custom 'tags' for files 2017-06-26 08:01:34 we use it already 2017-06-26 08:01:51 for xattrs and checksums 2017-06-26 08:02:12 what is the use case that you can't figure out? I can try to help if you like 2017-06-26 08:02:19 well, it's two fold thing 2017-06-26 08:02:40 1. speed. current index loading (index and installed db) is limited by parsing speed. it's "slow" on rpi. 2017-06-26 08:02:44 (it did look to me like apk was already using pax format, and in fact, gnu tar says that is the default format in the future, so apk is already future proof) 2017-06-26 08:03:04 2. updating the way signing works 2017-06-26 08:03:13 for #1 the index needs to be binary 2017-06-26 08:03:21 so it's mmappable 2017-06-26 08:03:33 in theory we could convert the file on fly 2017-06-26 08:03:35 binary index would make sense, that is not really replacing tar but replacing a text file 2017-06-26 08:03:44 since index is just a single file inside the tar + signature 2017-06-26 08:04:04 but i'd rather keep signature calculated of actual data on file. otherwise you have bigger problems 2017-06-26 08:04:07 now 2017-06-26 08:04:23 for #2, i want index to be generatable directly from packages, without additional signing 2017-06-26 08:04:25 for boot media 2017-06-26 08:04:44 this means it's basically collection of signed meta-data blobs 2017-06-26 08:05:02 so the package files would need to have these signed binary meta data blobs 2017-06-26 08:05:06 directly 2017-06-26 08:05:13 basically the equivalent of current .PKGINFO 2017-06-26 08:05:40 of course we could just change to have binary meta data instead of .pkginfo 2017-06-26 08:06:02 that is one way, another would be to append after end-of-archive record (so archive is signed) 2017-06-26 08:06:45 one way is to just duplicate the info in tar headers 2017-06-26 08:06:48 so you have just data.tgz then at the end of the file you put signed metadata with archive signature 2017-06-26 08:07:06 data.tgz being the same format as now 2017-06-26 08:07:07 but i'd rather not have people start using tar to extract files in their install scripts, because that skips signature verification 2017-06-26 08:07:35 also i'd need a way to enforce validity of the tar headers 2017-06-26 08:07:37 apk has --allow-untrusted anyway 2017-06-26 08:07:48 so users can already shoot themselves in the foot with that 2017-06-26 08:07:50 yes 2017-06-26 08:07:54 but its flag 2017-06-26 08:08:07 i want people not to create "make-bootable-media" using tar instead of apk 2017-06-26 08:08:42 another reason for signature changes is 2017-06-26 08:08:50 i can copy the signed meta data blobs to installed-db 2017-06-26 08:09:05 this allows doing 'apk audit' against signed data instead of the current text file 2017-06-26 08:09:28 so the motivation for having binary data is three fold 2017-06-26 08:09:42 speed, index requirements, installed-db requirements 2017-06-26 08:10:18 now if the .pkginfo goes away, imho it removes the benefit of tar format 2017-06-26 08:10:34 i would be happy to ship "apk2tar" applet so you can pipe it to tar if needed 2017-06-26 08:12:07 fabled: that would probably be more acceptable if apk instead had an applet to do basic tar things with an apk. like... "tapk -t /path/to/apk" for list files. that is probably the most useful thing 2017-06-26 08:12:36 ok 2017-06-26 08:12:40 i add it to my todo notes 2017-06-26 08:13:38 cool :) 2017-06-26 08:14:01 i started the code already, it got into hold for a little while, but i'm finally back on hacking it 2017-06-26 08:14:13 hope to get something publishable done in next few months 2017-06-26 08:14:15 neat :D 2017-06-26 08:14:33 let's see how it goes, and if new force majour arises before that 2017-06-26 08:28:29 ERROR: ruby-libs-2.4.1-r4: lib/ruby/2.4.0/rubygems/resolver/molinillo/lib/molinillo/dependency_graph/add_edge_no_circular.rb: no dirent in archive 2017-06-26 08:28:33 :/ 2017-06-26 08:28:41 not having very good luck with this tar stuff tonight 2017-06-26 08:28:42 haha 2017-06-26 09:40:00 foxkit, it happens if any of the preceding directories does not have directory entry 2017-06-26 10:17:44 fabled: it is missing 'usr/' but 'usr/' is definitely there in the apk 2017-06-26 10:17:49 as in, the string 2017-06-26 10:17:53 it starts with lib/ and should not 2017-06-26 10:17:55 I don't understand 2017-06-26 10:18:01 how does this happen .-. 2017-06-26 10:18:57 does it have 'L' entry ? 2017-06-26 10:19:26 fabled: if/whem you rewrite the apk archive format, I have only one request: embed a permissions file that would list chown/chmod entries for individual files in the archive, so you don't need to be root/fakeroot in order to create an archive with several owners 2017-06-26 10:19:44 that would allow abuild to get rid of fakeroot and to work on fully static machines 2017-06-26 10:20:08 skarnet, yes, though it would mean major re-working of aports tree too 2017-06-26 10:20:35 why, is there an explicit dependency on fakeroot in aports? 2017-06-26 10:20:58 abuild assumes that "make install" setups things in the DESTDIR 2017-06-26 10:21:27 ah, yes 2017-06-26 10:21:42 so it assumes a several-owner hierarchy already 2017-06-26 10:22:35 indeed that would require packages to be aware of different modes 2017-06-26 10:25:57 foxkit, is the .apk file somewhere? 2017-06-26 10:41:17 fabled: https://distfiles.adelielinux.org/ruby-libs-2.4.1-r4.apk 2017-06-26 10:41:27 I really should get some sort of temp dir on that server 2017-06-26 10:41:29 so I don't pollute / 2017-06-26 10:41:41 (well, /srv/www/distfiles, but / on the web root) 2017-06-26 10:46:04 foxkit, it's not GNU tar ? 2017-06-26 10:50:19 seems so, it does not have the GNU longname extension 'L' header, but only the regular tar header with the prefix field populated 2017-06-26 10:50:36 i guess we should support that 2017-06-26 10:50:46 another reason why i want to get rid of tar :) 2017-06-26 10:51:00 there's 3-4 ways to encode long names, and additional data 2017-06-26 10:51:38 regular tar header, pax header, gnu extension headers, and the extension place is regular header 2017-06-26 10:53:33 fabled: ah I am using adelie master abuild, --format pax was set to unify between gnu/bsd/busybox 2017-06-26 10:53:47 fabled: so it is gnu, but with --format pax, which they said will be default in next version. 2017-06-26 10:54:15 it might be also subtle bug in handling of long names 2017-06-26 10:54:32 in gnu mode, the gnu extension should be used if filename does not fit the 100 byte place 2017-06-26 10:54:58 perhaps it now uses the gnu extension only if it exceeds the 100+155 limit 2017-06-26 11:16:16 foxkit, try http://sprunge.us/QiTc 2017-06-26 11:17:32 or more like http://sprunge.us/fKVN 2017-06-26 11:28:28 (1/1) Reinstalling ruby-libs (2.4.1-r4) 2017-06-26 11:28:30 OK: 533 MiB in 94 packages 2017-06-26 11:28:33 fabled: you're amazing! <3 2017-06-26 11:31:04 foxkit, ok, pushed it out too 2017-06-26 11:31:13 thanks! 2017-06-26 11:39:16 Hi guys, I`ve updated my pull request regarding the PyPy3 build .If you want to take a look that will be great ! https://github.com/alpinelinux/aports/pull/1635 2017-06-26 15:17:14 yo guys, I am using awall on my server but on each reboot I have to call awall activate because the rules aren't applied. Any suggestions ? 2017-06-26 17:21:19 Add iptables tot initd 2017-06-26 18:44:27 can the elasticsearch PR be pulled please ? 2017-06-26 18:46:10 https://github.com/alpinelinux/aports/pull/1380 2017-06-27 01:58:49 is the preferred PR format one-pacccccckage-per-PR, or caaan I batch them with one-package-per-commit? 2017-06-27 01:58:58 I ask because I have a lot of incremental fixes for crosssssssssss-compilation 2017-06-27 01:59:22 ugh, apologies for the duplicated letters, my computer does not like me typing while building stuff :/ 2017-06-27 02:15:44 yoooo haaaave slooow speeeeech paaaatterns? 2017-06-27 16:30:44 hmm, /usr/src/linux-headers-* is not included in the linux-headers package, I take it those are in linux-*-dev instead, I just want to build a simple hello world kernel module, I take it in that case I only need the former package though? 2017-06-27 16:57:09 for kernel mods, you need the linux-*-dev package 2017-06-27 16:57:20 linux-headers are the userspace headers in for 2017-06-27 17:42:58 Yeah, I already sorted it realizing modules/$uname/build would need to point to a kernel tree, I assumed linux-headers would include a very barebones one, but that was a mistake on my part 2017-06-28 19:56:26 Yo guys, ifup does not work. It complains about "interface xxx already configured". Do I need to install something ? 2017-06-28 19:58:19 ah I see I used the busybox version njaaaaaaaaaa 2017-06-28 20:07:26 okay ifupdown does not help and make it worse 2017-06-28 23:09:19 most of the perl packages run their test suites during building, so I'm not sure it's fair to say "!check" because they *are* being tested, but the tests are baked in; do we have a way to handle that? 2017-06-28 23:13:44 Result: PASS All tests successful. Files=10, Tests=96, 3 wallclock secs 2017-06-28 23:13:53 >>> perl-try-tiny: Entering fakeroot... 2017-06-28 23:14:02 >>> WARNING: perl-try-tiny*: APKBUILD does not run any tests! 2017-06-28 23:24:02 foxkit: you can add: check() { return 0; # tested during build } 2017-06-28 23:27:09 ah 2017-06-28 23:37:44 does adding test suites warrant a pkgrel bump? theoretically there should be no change in binaries or user-facing files, only the build system is different. 2017-06-29 00:48:00 foxkit: no 2017-06-29 00:55:22 Shiz: okay, thank you 2017-06-29 00:55:51 also re:above 2017-06-29 00:56:01 thhat seems fair 2017-06-29 00:56:09 although i'd just do it with options="!check" 2017-06-29 00:56:19 options="!check" # tests run during build 2017-06-29 01:07:52 Shiz: I am hoping to some day make a list of packages that set that, and complain upstream 2017-06-29 01:07:59 Shiz: like "hey, people, write test suits" 2017-06-29 01:08:02 suites* 2017-06-29 01:10:59 how hard is it to port apps over to alpine? 2017-06-29 01:14:37 how hard is it to climb a mountain? 2017-06-29 01:14:43 answer: it depends on the mountain. ;) 2017-06-29 01:15:39 I see. 2017-06-29 01:16:48 I think I should start with some small hills first. 2017-06-29 01:17:19 software following good practices, not using glibcisms, etc. will be easy to port. 2017-06-29 01:17:46 things written for-GNU or for-another-distribution will be tougher nuts to crack. 2017-06-29 01:24:08 Ok, I am new to this aspect of computers. I mainly fix hardware problems and such. 2017-06-29 01:25:22 welcome to software, where there are a lot more bugs, but they're somewhat easier to fix than silicon 2017-06-29 01:26:35 Shiz: actually, while you are here, can you answer my question from a few nights ago: if I have a large swath of "implement check()", is it okay to put in one PR (but one commit per package of course)? or do I need to do one PR per package? 2017-06-29 01:26:58 i'd prefer the former 2017-06-29 01:27:03 Why thank you foxkit. I hope to use alpine as a base for my 'lernin' and try to bring some packages to the repos as well. 2017-06-29 01:27:38 Shiz: okay, noted :) I will still do package-specific fixes in separate PRs (like there are some that should be noarch but are all) 2017-06-29 01:28:11 m4chm4n: you've come at a great time, as my weekend project is documenting all about making packages and building stuff :) 2017-06-29 01:28:41 I am going to try my hand at programming as well. Any suggestions for my first language, that will also play extremely well with alpine. 2017-06-29 01:28:56 python is always good 2017-06-29 01:29:15 for starters but others will say start learning c to learn from the ground up as well 2017-06-29 01:29:39 Yea, I noticed a lot of python related packages in the repo. 2017-06-29 01:29:58 python is a good portable language, simple to pick up but has lots of things to learn and useful for lots of tasks. 2017-06-29 01:30:11 it depends on what you're looking for, really. Python is good to learn first if you want to do applicative stuff fast, if you want to learn programming in general. 2017-06-29 01:30:18 its a good starter language Id recommend looking at the codecademy course as well it helped me pick it up a bit easier 2017-06-29 01:30:21 C is good to learn first if you want to know how a machine works inside. 2017-06-29 01:30:21 And C was one of the few I was looking at. 2017-06-29 01:30:34 lua is a lightweight scripting language, very popular in alpine too, but it has some things that are unique to it (indexes start at 1 instead of 0, unlike almost every language.. and tables) 2017-06-29 01:30:35 yeah it all depends on what you want to do 2017-06-29 01:30:51 foxkit: thats a bit strange but I guess to be different 2017-06-29 01:30:59 so it is good to learn later if you like but not necessarily a good 'first' language 2017-06-29 01:31:11 as it will teach you things that don't apply to other languages 2017-06-29 01:31:53 I think starting out in python to get a primer then you can branch off to a ducked typed language 2017-06-29 01:32:02 C is one of those languages that is extremely useful to learn, but it can be very hard to learn depending on your background 2017-06-29 01:32:11 so youd have a dynamically typed lang a static typed lang 2017-06-29 01:32:22 arch3y: Python is duck-typed XD 2017-06-29 01:32:34 ah gotcha my bad Im not a programmer at all 2017-06-29 01:32:40 I was just trying to sound like one lol 2017-06-29 01:32:53 I guess I got them mixed up 2017-06-29 01:33:05 lol 2017-06-29 01:33:27 well thank you two for the information. 2017-06-29 01:33:51 yep have fun and write lots of code to learn 2017-06-29 01:35:13 The job I have will allow me to read and write a bunch of code. So thats a plus. 2017-06-29 07:50:51 can it be that mp3 are not supported with the gst plugin packages no more? 2017-06-29 07:52:05 morning 2017-06-29 07:57:41 gstreamer gives me a error "Couldn't g_module_open libpython. Reason: Error loading shared library /usr/lib/libpython2.7.so: No such file or directory" python 2.7 is installed 2017-06-29 07:58:48 xsteadfastx, what happens when you install python2-dev? 2017-06-29 07:59:47 will try 2017-06-29 08:03:02 the error is gone but it looks like it had nothing to do with that gstreamer doesnt find the mp3 decoder no more 2017-06-29 08:03:24 there is a other error "Failed to load plugin '/usr/lib/gstreamer-1.0/libgstdtls.so': Error relocating /usr/lib/gstreamer-1.0/libgstdtls.so: BIO_set_data: symbol not found" 2017-06-29 08:06:40 as a temp workaround for the prev error you could create the /usr/lib/libpython2.7.so symlink yourself after you remove python2-dev 2017-06-29 08:06:48 i installed gst plugins good bad and ugly and a edge upgrade brought me here ;-) 2017-06-29 08:08:09 how can i reproduce your second error? 2017-06-29 08:08:51 wait i will check... not thats a other problem... 2017-06-29 08:11:15 the second error comes with running gst-play-1.0 too... i had it in mopidy but it looks like its not a mopidy error 2017-06-29 08:14:45 and running gst-play-1.0 with a mp3 file gives this error "WARNING No decoder available for type 'audio/mpeg" 2017-06-29 08:15:22 but this used to work with edge a few weeks ago. i use it in my mopidy docker image and i had to rebuild the dockerfile 2017-06-29 08:15:29 *docker image 2017-06-29 08:17:10 i guess its important to first fix all errors, could be something is preventing loading of whatever that supports mpeg. 2017-06-29 08:17:42 yes because it says its from the loader 2017-06-29 08:17:46 plugin loader 2017-06-29 08:18:14 if i can reproduce the error i can try to rebuild things and see if it solves anything 2017-06-29 08:18:43 ok 2017-06-29 08:30:29 xsteadfastx: do you know exactly which plugin it is? 2017-06-29 08:30:42 ah, no decoder 2017-06-29 08:31:01 or do i need to install something like mad? 2017-06-29 08:31:31 which gst-plugins do you have installed? 2017-06-29 08:31:43 apk info | grep gst-plugins 2017-06-29 08:31:50 might be the plugin moved to other package 2017-06-29 08:33:12 i have gst-plugins-base1 gst-plugins-bad1 gst-plugins-good1 and gst-plugins-ugly1 installed 2017-06-29 08:33:39 looks correct 2017-06-29 08:34:16 do you have gst-libav installed? 2017-06-29 08:34:19 can you play mp3s with gst-play-1.0 with the edge packages? 2017-06-29 08:35:01 looka like i can 2017-06-29 08:35:43 make sure you apk upgrade --available 2017-06-29 08:36:00 ok gst-av1... that was missing 2017-06-29 08:36:03 is this something new? 2017-06-29 08:36:10 dunno 2017-06-29 08:36:24 might be the other gst-pluglins is supposed to load mp3 2017-06-29 08:36:37 might be that something is broken 2017-06-29 08:37:07 that python stuff is made of glass 2017-06-29 08:37:10 the second error remains but at least it plays mp3s again 2017-06-29 08:38:00 looks like gst-plugins-ugly is supposed to have both mad and lame support 2017-06-29 08:39:43 yes thats what i thought... 2017-06-29 08:40:52 maybe gst-libav1 was a dependency for gstreamer somehow? maybe that changed... it doesnt seem new to me 2017-06-29 08:41:17 i think gst-libav1 is just another plugin that happens to support mp3 2017-06-29 08:41:22 its a ffmpeg binding 2017-06-29 08:41:27 which also can do mp3 2017-06-29 08:41:45 ah ok... so something could be wrong with the mad support 2017-06-29 08:41:53 yes 2017-06-29 08:44:44 do you have this file: /usr/lib/gstreamer-1.0/libgstlame.so 2017-06-29 08:45:37 which arch is it? 2017-06-29 08:46:26 ok, i think i can reproduce it 2017-06-29 08:46:56 it is correctly linked to libmp3lame, but it cannot play mp3 2017-06-29 08:48:12 wait i have to restart the container ;-) 2017-06-29 08:48:30 arch ist X86_64 2017-06-29 08:49:00 i have the file 2017-06-29 08:54:33 aha, looks like lame is only the mp3 encoder 2017-06-29 09:02:58 so its not a problem? 2017-06-29 09:03:06 no 2017-06-29 09:03:18 i suspect that libmad support was moved to other package 2017-06-29 09:09:43 ok, found it 2017-06-29 09:09:46 Plugin removals 2017-06-29 09:09:46 The mad mp1/mp2/mp3 decoder plugin was removed from gst-plugins-ugly, as libmad is GPL licensed, has been unmaintained for a very long time, and there are better alternatives available. Use the mpg123audiodec element from the mpg123 plugin in gst-plugins-ugly instead, or avdec_mp3 from the gst-libav module which wraps the ffmpeg library. We expect 2017-06-29 09:09:46 that we will be able to move mp3 decoding to gst-plugins-good in the next cycle 2017-06-29 09:12:42 while at it 2017-06-29 09:12:57 i think we should rename the gst*1 to gst* 2017-06-29 09:13:06 eg remove the "1" suffix 2017-06-29 09:15:09 aaaahhhh ok... good :) 2017-06-29 09:15:27 thanks for finding out 2017-06-29 09:24:50 thanks for reporting it 2017-06-29 15:51:39 ncopa: where did you run off to anyway 2017-06-29 15:51:40 lol 2017-06-29 18:39:17 Hey is it possible that this project could be built for alpine or is it impossible? https://github.com/systemd/mkosi 2017-06-29 18:39:32 I know you guys don't use systemd, but it should compile, right? 2017-06-29 18:39:51 nvm 2017-06-29 18:40:02 "The current version requires systemd 233 (or actually, systemd-nspawn of it)." :( 2017-06-29 18:40:48 why would we package that anyway 2017-06-29 18:40:57 it's for building systemd images 2017-06-29 18:41:55 Are you sure? It looks like the projects aim is to build OS images as a gpt disk, I think systemd is just a dependency of the project itself not the final images 2017-06-29 18:42:26 because sometimes work done on a distro does not target that distro, that would be a good reason. that said, systemd. 2017-06-29 18:42:35 huh TIL opensuse uses systemd too, I thought that was on init scripts 2017-06-29 18:43:12 mhmm politics aside it looks like a good tool, but unfortunately can't be packaged anyway :( 2017-06-29 18:44:12 Still trying to find a nice way to build images for alpine pxe booting 2017-06-29 18:44:22 something that runs nicely in a CI 2017-06-29 18:46:27 any suggestions welcome! 2017-06-29 18:58:40 IAMB3NW: stay tuned 2017-06-29 18:59:04 first i need to redesign the MOTD system to display ads though 2017-06-29 18:59:10 HA HA JUST KIDDING 2017-06-29 19:08:33 IAMB3NW: what about the normal ISO creation scripts for alpine? 2017-06-29 19:09:18 kaniini: come on, we all love seeing ads on MOTD. 2017-06-29 19:10:22 ya i am sure IBM could make great use of the functionality 2017-06-29 19:10:23 :P 2017-06-29 19:10:42 * We see you're using a Dell. Try Power servers instead!!!! http://whatever 2017-06-29 19:10:53 kaniini: good idea! 2017-06-29 19:12:03 (clearly all these people upset at canonical for putting ads in MOTD have never used ubuntu desktop have they) 2017-06-29 19:13:16 kaniini: you mean the one that forwards a copy of all of your searches to amazon in case you want to buy a terminal instead of open one? 2017-06-29 19:13:23 yes 2017-06-29 19:13:31 🙏 2017-06-29 19:40:37 <_ikke_> what, ads in motd?!? 2017-06-29 19:40:56 _ikke_: and telemetry in the user agent 2017-06-29 19:40:58 https://twitter.com/astarrb/status/880170781841514496 2017-06-29 19:41:03 https://gist.github.com/anonymous/fdc1cab8cb193ca19aa4c663c1ebd1f5#file-gistfile1-txt-L245 2017-06-29 19:42:14 _ikke_: it is a bug https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1701068 2017-06-29 19:43:09 i like how they argue that people can opt out like that excuses the fact that it's implicitly enabled 2017-06-29 21:23:04 kaniini oo exciting, any clues? ;) 2017-06-29 21:23:50 Xe They don't allow for enabling services etc or splitting up the output to multiple files 2017-06-29 21:24:13 for example PXE requires a kernel to be supplied and a filesystem 2017-06-29 21:27:43 IAMB3NW: i thought PXE could handle ISO files? 2017-06-29 21:28:51 Xe, I'm trying to boot quickly, boot initially with drivers, then mount everything else as read-only using squashfs 2017-06-29 21:49:43 Is KDE Plasma 5 available for Alpine? I just installed it on a netbook to test it out, and searching with apk doesn't turn up any results. Maybe I'm using the wrong search terms? Or is it not available? 2017-06-29 21:50:41 <_ikke_> Don't think there is 2017-06-29 21:50:59 PaddyMac: I'm afraid that plasma 5 is not available in Alpine. 2017-06-29 21:51:17 PaddyMac: there is gnome-shell in testing if you are interested in "modern" DE 2017-06-29 21:51:39 also, you can look for required packages on pkgs.alpinelinux.orf 2017-06-29 21:51:44 I hate Gnome 3. If I can't have KDE, I guess I can use Mate. 2017-06-29 21:51:48 s/orf/org/ 2017-06-29 21:51:59 PaddyMac: just saying ;) 2017-06-29 21:52:19 I'd go back to Windows before using Gnome 3. 2017-06-29 21:52:33 better not :P 2017-06-29 21:53:19 I do my best to avoid it. 2017-06-29 21:56:43 there was KDE in the aports at least some time back, but I think it was in the unmaintained section 2017-06-29 21:56:57 so it's probably not getting much love 2017-06-29 21:58:50 Well, I get the impression Alpine isn't aimed at the desktop. 2017-06-29 21:59:06 <_ikke_> It's not the main focus, no 2017-06-29 21:59:13 I was mainly interested in Alpine because it uses musl. 2017-06-29 21:59:38 And I was hoping that would make it more viable for a memory-constrained netbook. 2017-06-29 22:01:25 Acer should be embarrassed for Putting Win 7 on there because it crawled like a snail. 2017-06-29 22:05:50 the xfce in alpine works okay; I still have problems with is gtk theme support but besides everything is smooth 2017-06-29 22:11:06 *its (heavy packetloss going on) 2017-06-29 22:12:31 alpine is for desktop usage just fine, but it's not a particular focus 2017-06-29 22:14:30 plasma 5 is likely to land in alpine soon 2017-06-29 22:14:39 oh? 2017-06-29 22:14:43 i just do not have any interest personally, but the adelie guys do 2017-06-29 22:15:06 so likely we will just import it from them 2017-06-29 22:16:09 sounds good. KDE is pretty heavy though; I only run it on a grand total of one machine that has the hardware for it 2017-06-29 22:17:04 i'm glad kde can run without systemd 2017-06-29 22:20:00 I imagine there's a lot of systemd integration in Gnome these days 2017-06-29 22:20:28 not really 2017-06-29 22:20:40 gnome 3 is running quite excellently on alpine 2017-06-29 22:20:43 i just need to sort gdm 2017-06-29 22:20:54 which for some reason has the screensaver built into it (wtf?) 2017-06-29 22:21:28 kaniini: i think that's to prevent screensaver crashes from dropping the user back into the DE 2017-06-29 22:21:53 i should clarify 2017-06-29 22:22:04 by 'screensaver' i mean screen locking only 2017-06-29 22:22:09 there are no screensavers in gnome anymore 2017-06-29 22:22:15 because why would anyone want those 2017-06-29 22:27:12 speaking of which, anyone happen to know a screensaver that basically just fetches and renders a web page? 2017-06-29 22:45:32 PaddyMac: running adelie (custom alpine spin) on my laptop, it only uses 300 MB RAM for full KDE Plasma 5 desktop + firefox :) but it is very early days. don't have any of the KDE stuff ready for upstreaming to alpine yet. 2017-06-29 22:45:48 ACTION <- lead of adelie, which is how I get it first :p 2017-06-29 22:46:34 PaddyMac: I would personally suggest xfce for the next few weeks. hoping to have KDE fully "ready" by mid July. 2017-06-29 22:46:46 so it will probably be in edge some time in Late July or early August? 2017-06-29 22:47:26 I think actually that plasma only uses ~210 or such MB, but firefox is of course large too 2017-06-29 23:24:16 Tor released 0.3.0.9, can someone merge https://github.com/alpinelinux/aports/pull/1793 please? 2017-06-30 04:14:16 foxkit: Thanks for the heads up. 2017-06-30 05:45:03 Xe: done 2017-06-30 07:39:28 kaniini: ty 2017-06-30 13:05:06 Shiz sorry sent message to you in wrong channel so here now 2017-06-30 13:05:11 Could somebody merge https://github.com/alpinelinux/aports/pull/1792 ? 2017-06-30 17:03:42 ncopa: https://dev.alpinelinux.org/~clandmeter/patches/linux-4.9.y-rpi-201704120.patch doesn't seem to apply for linux-rpi 4.9.35