2016-07-01 00:00:01 <^7heo> jirutka: I can't even find the list of mirrors 2016-07-01 00:00:06 I will not, I’m definitely not gonna replace Firefox with Chrome 2016-07-01 00:00:35 <^7heo> I know that the mirror list is available somewhere 2016-07-01 00:00:39 <^7heo> but I can't seem to find it 2016-07-01 00:00:44 but I believe that my coworkers are not so insane to be trying to force me into it :) 2016-07-01 00:01:02 here https://github.com/alpinelinux/aports/blob/master/main/alpine-mirrors/mirrors.yaml 2016-07-01 00:02:45 I’ll see, I have nothing to lose now and it’s really very interesting opportunity 2016-07-01 00:03:02 <^7heo> /usr/share/alpine-mirrors/MIRRORS.txt 2016-07-01 00:03:07 <^7heo> looks liks they're there 2016-07-01 00:03:34 <^7heo> but not on my laptop 2016-07-01 00:03:36 hmm, I don’t have this file on my system 2016-07-01 00:04:04 anyway, I think that it’s just copy of http://rsync.alpinelinux.org/alpine/MIRRORS.txt and this list is not complete 2016-07-01 00:04:10 <^7heo> weird, it's referrenced in /sbin/setup-apkrepos:MIRRORS_PATH=/usr/share/alpine-mirrors/MIRRORS.txt 2016-07-01 00:04:16 it contain just a subset of mirrors 2016-07-01 00:05:15 <^7heo> $ grep -rn ^MIRRORS_PATH /sbin/setup-* 2016-07-01 00:05:15 <^7heo> /sbin/setup-apkrepos:177:MIRRORS_PATH=/usr/share/alpine-mirrors/MIRRORS.txt 2016-07-01 00:05:46 <^7heo> Anyway, thanks for the yaml link 2016-07-01 00:11:27 <^7heo> http://dl-cdn.alpinelinux.org/alpine/edge/main/x86_64/ says r9 2016-07-01 00:11:32 <^7heo> and then if I follow the link, 404. 2016-07-01 00:11:56 dl-cdn should be most up-to-date 2016-07-01 00:13:43 <^7heo> yeah well, the file list isnt' 2016-07-01 00:13:51 going to sleep, see ya 2016-07-01 00:14:04 <^7heo> yeah same 2016-07-01 07:02:10 i wonder if i should look at gcc 6.1, and start thinking about migration to libressl 2016-07-01 07:14:40 and pick up finally on the armv7 port 2016-07-01 07:18:42 :) 2016-07-01 07:19:10 i looked at the gcc apkbuild, and ill leave it up to you :) 2016-07-01 07:20:44 yeah, it's slightly non-trivial. especially doing the initial cross-build 2016-07-01 07:20:56 i need to find my existing fixes 2016-07-01 08:29:32 ncopa: any preferences about header-only packages like http://patchwork.alpinelinux.org/patch/2139/ ? 2016-07-01 08:29:42 it ships static library and a header 2016-07-01 08:29:54 should it be named -dev? 2016-07-01 09:34:30 hey :) 2016-07-01 10:28:17 i am currently huntind down a bug in consolekit 2016-07-01 10:28:22 that software is horrible 2016-07-01 10:28:48 it really depresses me how much crappy and insecure software a normal linux desktop user has to run in order to have a desktop environment 2016-07-01 10:30:16 you don't have to run it 2016-07-01 10:32:26 just be convinced that a Windows desktop is at least as much crappy and insecure 2016-07-01 10:37:17 i'm not sure about that (but only if its a default install without anything 3rd party installed) 2016-07-01 10:38:07 ms has a very good security process. i doubt any xorg desktop environment comes even close to that 2016-07-01 10:40:44 xorg itself is pretty secure ... messy but secure since it has privilege seperation 2016-07-01 10:40:59 but all the rest around it is so horrible 2016-07-01 10:41:00 xorg is secure, said no one ever 2016-07-01 10:41:11 compared to wayland it is 2016-07-01 10:43:17 i take xorg every day over wayland (weston, mutter, clayland) ... 2016-07-01 10:51:16 you seriously consider xorg more secure than wayland? 2016-07-01 10:51:23 yes 2016-07-01 10:51:26 not sure if there is any way I could discuss this 2016-07-01 10:51:41 just read the code 2016-07-01 10:52:43 xorg got a lot of audits over the years, not so wayland 2016-07-01 10:52:55 so yes, i concider it more secure than wayland 2016-07-01 10:53:59 hah, all the reviews i saw were horrible 2016-07-01 10:55:15 but dont get me wrong. its not one good software and the other one bad software. its more like: bad software and even more bad software 2016-07-01 10:55:57 i'd put wayland and xorg in the same category, and a few categories above that the ms desktop... /o\ 2016-07-01 10:57:14 nCn9Ow35Ffww: i actually would agree with your statement when it comes to a bare windows 7 desktop. but there are two arguments that crash windows as a secure thing. A: cortana integration, B: rendering engine embedding in the normal explorer, that is simply insecure 2016-07-01 10:57:29 when you talk about the stack they use to render there windows, then yes 2016-07-01 10:57:37 that stuff is better than the linux things we have 2016-07-01 11:03:00 yes, when i wrote ((but only if its a default install without anything 3rd party installed)) i meant "a bare windows 7 desktop" 2016-07-01 11:03:17 then yes, i fully agree 2016-07-01 11:11:50 fabled, ncopa: no builders for edge armhf? 2016-07-01 11:23:33 strange. need to look at it 2016-07-01 11:23:38 back in 30 2016-07-01 14:16:16 looks like ncopa has holiday today, but he forgot to apply it. 2016-07-01 16:52:53 <^7heo> btw 2016-07-01 16:53:05 <^7heo> python segfaults with any different PaX flags than m, x 2016-07-01 16:53:43 <^7heo> so, if one wants to use gdb python, along with the libpython.py helpers; it's bound to fail on the frame, since it is not possible to access it. 2016-07-01 16:53:46 <^7heo> https://wiki.gentoo.org/wiki/Hardened/Debugging#Solving_the_.27.3F.3F.27_issue. 2016-07-01 16:53:53 <^7heo> That causes python 2.7 to segfault. 2016-07-01 16:55:04 <^7heo> there's more doc on the gdb python helpers here: https://fedoraproject.org/wiki/Features/EasierPythonDebugging 2016-07-01 17:49:02 can someone here trigger rebuilds? 2016-07-01 17:49:12 rebuilds of what? 2016-07-01 17:49:18 mpv to be exact 2016-07-01 17:49:29 sure 2016-07-01 17:49:37 the current version segfaults to do an ffmpeg update 2016-07-01 17:49:50 just rebuild, not upgrade? 2016-07-01 17:50:02 in edge…? 2016-07-01 17:50:02 rebuild or if you have permissions upgrade as well :) 2016-07-01 17:50:06 yes, in edge 2016-07-01 17:50:16 0.18.0 is the newest version 2016-07-01 17:50:17 :) 2016-07-01 18:18:41 jirutka: did you trigger the rebuild? 2016-07-01 18:19:02 yeah 2016-07-01 18:19:20 https://pkgs.alpinelinux.org/package/edge/community/x86_64/mpv 2016-07-01 18:19:59 awesome, then i can update and continue my movie evening :) 2016-07-01 18:20:45 big thanks jirutka 2016-07-01 18:23:10 oh, movie evening! thanks for reminding it 2016-07-01 19:40:05 http://pkgstest.alpinelinux.org/packages.html 2016-07-01 19:40:05 simple js base api usage 2016-07-01 19:41:00 "api Consumer On a Page for Aports" 2016-07-01 19:41:00 maybe call it COPA 2016-07-01 19:41:37 if pre-qualified with "nano" - then nCOPA 2016-07-01 19:41:42 ;) 2016-07-01 19:47:14 code is here: github.com/insteps/aports-ui 2016-07-01 20:40:06 jirutka: if not watching movie, http://www.irclogger.com/.alpine-devel/2016-07-01#1467402005 2016-07-01 20:40:44 wow, this is very nice irc logger! 2016-07-01 20:40:55 did not implement /package yet, but left it for api consumers to understand and implement 2016-07-01 20:41:21 and but algitbot gets all excited about it 2016-07-01 20:42:59 route /packages/{filter} hides /search resource 2016-07-01 20:43:37 so there maynot be a need to document /search 2016-07-01 20:44:39 planning to convert the js version to php, but not soonish 2016-07-01 21:33:29 Private memory use (memory actively being used): 36,5 MB • Visible lines: 86 2016-07-01 21:44:13 refering to api/ui ? 2016-07-02 07:34:39 is there a way to keep an older version of the kernel available on upgrade ? 2016-07-02 09:00:40 coredumb: probably not 2016-07-02 09:43:22 clandmeter: ok 2016-07-04 06:57:21 morning climbers 2016-07-04 07:33:50 morning 2016-07-04 07:34:05 its not raining! 2016-07-04 08:57:49 morning. indeed 2016-07-04 09:00:08 fabled: any news on armhf builders for edge? 2016-07-04 09:47:24 <^7heo> I am sorry to say that this bluntly but... 2016-07-04 09:47:37 <^7heo> in 3.3, setup-disk is broken beyond recognition. 2016-07-04 09:47:51 <^7heo> I spent 1h30 trying to fix problems along the way 2016-07-04 09:47:59 <^7heo> and it's still failing. 2016-07-04 09:50:08 <^7heo> someone should be able to specify a mounted drive for that 2016-07-04 09:50:35 <^7heo> it would help with the failing script, at least one could manually setup the disk and pass the setup to the script for it to install 2016-07-04 09:52:16 <^7heo> oh, it seems to kinda work with a mounted partition. Well, at least there's that. 2016-07-04 09:52:27 hey :) 2016-07-04 09:52:49 <^7heo> hey. 2016-07-04 10:01:08 hoi 2016-07-04 10:04:05 barthalion, oh, i should go wake it up 2016-07-04 10:05:07 <^7heo> too bad 3.4 doesn't boot on my computer 2016-07-04 10:05:21 <^7heo> I could (try to) contribute to the script at least. 2016-07-04 10:17:51 ScrumpyJack: w3m has no maintainer but was moved to community. Could you maintain this package? 2016-07-04 10:56:47 the ffmpeg-libs update right now broke mpv again :) 2016-07-04 10:56:50 no sound 2016-07-04 10:56:57 it needs a rebuild to work properly 2016-07-04 10:58:58 ncopa: sure, can you add me as maint? 2016-07-04 11:06:36 leo-unglaub: weird, it used to work with minor upgrades 2016-07-04 11:07:23 barthalion: yeah, i know. i have no idea why no one all of the sudden can keep abi compat in small releases 2016-07-04 11:07:25 pushed the rebuild, you can nag someone about upgrading to 0.18 as well 2016-07-04 11:07:33 leo-unglaub: meh, ffmpeg does keep it 2016-07-04 11:07:40 but according to the mpv guyes they have that problem very often 2016-07-04 11:07:41 mpv must be doing something weird behind the scenes 2016-07-04 11:08:04 when i joined there channel to report the bug they replyed instantly with "rebuild abi break" 2016-07-04 11:08:20 I maintained both ffmpeg and mpv at Arch, and I don't remember any issues 2016-07-04 11:08:34 i have no idea ... 2016-07-04 11:08:39 thats what they told me :) 2016-07-04 11:09:04 back then, mpv was throwing a warning if it has been built with older ffmpeg than running at the moment 2016-07-04 11:09:24 but nothing was broken, they apparently changed the tactic 2016-07-04 11:09:34 seams like it 2016-07-04 11:10:53 well, thanks for reuilding it 2016-07-04 11:11:05 so i can continue watching the finaly of true detective :) 2016-07-04 11:11:19 first or second? 2016-07-04 11:11:27 finaly of the first season! 2016-07-04 11:11:31 (y) 2016-07-04 11:11:43 second kind of sucks 2016-07-04 11:12:14 it has some moments, and I like the ending, but in overall it sucks, yeah 2016-07-04 11:12:31 i didnt finish it, so i cannot comment on the ending. 2016-07-04 11:13:09 I cant seriously watch Vince Vaughn 2016-07-04 11:14:40 ScrumpyJack: can you please create a patch with it? and also bump pkgrel and tpaste it here? 2016-07-04 11:17:36 i'll send a patch, there seem to be other issues 2016-07-04 11:21:51 ncopa: i'm interested in helping too 2016-07-04 11:32:45 since there are lots changes going in for v3.5, any thoughts on have toolchain branch in git ? 2016-07-04 11:34:00 benefits, 2016-07-04 11:34:00 1. AL oriented optimization 2016-07-04 11:34:00 2. free pkgs that have features but cannot be added as it may effect current toolchain 2016-07-04 11:35:16 same pkgs name can now have names -generic attached to it 2016-07-04 11:35:16 meta-pkg named toolchain.apk created 2016-07-04 11:35:46 alpine-sdk pulls in toolchain.apk 2016-07-04 11:37:44 leo-unglaub: that’s why people should not use edge on workstation… mpv is in community, so why not use stable branch? 2016-07-04 11:38:05 so I can have curl-generic with new features 2016-07-04 11:38:29 eg. --with-nghttp2 2016-07-04 11:38:48 jirutka: because i am a new software junkie and like to get all new software all the time. also only by testing it in a real environment you can find the bugs 2016-07-04 11:39:03 i think i have reported a lot of bugs that i simply found by using edge 2016-07-04 11:39:38 leo-unglaub: well, that’s true 2016-07-04 11:40:29 leo-unglaub: if you don’t mind that you have sometimes broken system just because of ABI incompatibilities :) 2016-07-04 11:40:54 nah, i dont mind. as long as someone is there to quickly trigger a rebuild *g* 2016-07-04 11:41:05 leo-unglaub: anyway, any progress with Rust? I’m really impatient :) 2016-07-04 11:41:23 you shouldnt run edge except if you intend to fix it. 2016-07-04 11:41:38 jirutka: https://i.imgur.com/ECXZfM7.png 2016-07-04 11:41:43 clandmeter +1 2016-07-04 11:42:20 leo-unglaub so you have working rustc on Alpine? How? Please tell me! 2016-07-04 11:42:46 simple 2016-07-04 11:43:14 i ssh'ed to my OpenBSD laptop and executed rustc there on files i mounted from my alpine linux *g* 2016-07-04 11:43:22 its a little bit cheating, but it works 2016-07-04 11:43:24 hehe 2016-07-04 11:44:57 leo-unglaub: but this will not help me to package Rust programs and push them into the official repo :( 2016-07-04 11:45:14 yes and no 2016-07-04 11:45:23 or its called , I don't wanna know where its installed ;) 2016-07-04 11:45:35 leo-unglaub: I’m developing on OS X, so I have no problem with Rust, but I’m looking forward making Alpine packages for Rust programs 2016-07-04 11:45:59 you can write rust stuff and then use the musl linux target to compile it 2016-07-04 11:46:16 the written program itself should then be runable on alpine 2016-07-04 11:46:28 not rust itself, but the created binary 2016-07-04 11:47:03 leo-unglaub: I know, but Alpine packages should not pull precompiled binaries from somewhere 2016-07-04 11:47:13 jirutka: absolutly!!!!! 2016-07-04 11:47:16 i 1000000% agree 2016-07-04 11:47:38 but when you can show off how cool your new binary is and how much alpine needs it maybe rust gets done quicker :) 2016-07-04 11:49:13 leo-unglaub: it shouldn’t be so hard to build rustc on musl for someone experienced with cross-compilation, should it? 2016-07-04 11:49:34 jirutka: thats that stupid trusted trust thing they go 2016-07-04 11:49:57 but thats not just rust, getting clang to compile it a pain as well when you do it the first time! 2016-07-04 11:50:17 i found a new blog post on rust somewhere where they had some new compiler flags that got me very far 2016-07-04 11:50:23 but i hand at the last step somewhere 2016-07-04 11:50:47 ACTION leo-unglaub: someone already ported rustc to totally different architecture, so it’s definitely possible 2016-07-04 11:51:17 ^ huh, why is this messages purple and starting with bullet? 2016-07-04 11:51:47 sure its possible ... its also possible to loose 20kg ... but i am also unable of getting it done *g* 2016-07-04 11:51:56 btw I don’t feel well since friday and I can barely focus on what I’m writing, so me English is probably even worse than usual 2016-07-04 11:52:01 for a trained compiler guy this is propobly a 2 hour thing 2016-07-04 11:52:58 unfortunately I don’t know about any trailed compiler guy to persuade :( 2016-07-04 11:53:20 i know 2 ... and they told me to fuck off with rust *g* 2016-07-04 11:53:30 leo-unglaub: pfff 2016-07-04 11:54:10 leo-unglaub: hmm, I bet that one of them is skarnet 2016-07-04 11:54:13 well, they are old school c guys ... so dont expect them to like it 2016-07-04 11:54:17 leo-unglaub: i'm glad you use edge. you do provide valuable feedback and bugreports 2016-07-04 12:06:33 Now, now. "Rust, like any high-level language, isn't a magic pill and it probably won't solve all you seem to think it will solve" is very different from "fuck of with Rust". :P 2016-07-04 12:07:01 off*, even 2016-07-04 12:12:23 skarnet: rust is not a high level language ;) 2016-07-04 12:13:50 It does automatic heap management? Then it's a high-level language. 2016-07-04 12:14:11 Rust is a systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety 2016-07-04 12:14:14 ;) 2016-07-04 12:14:49 yeah, and it also makes coffee and solves world hunger, I know. 2016-07-04 12:14:55 hehehe 2016-07-04 12:15:36 that "prevents all segfaults" is wrong. i already managed to get it to segfault *g* 2016-07-04 12:15:43 but its still a nice language *g* 2016-07-04 12:15:46 but since it makes coffee, it shouldn't be hard to convince ncopa that having it is very important 2016-07-04 12:16:46 skarnet: No, it does not have automatic heap management _by default_. Actually, it allocates at stack everywhere when possible. 2016-07-04 12:17:51 jirutka: uh, yeah, it's as if you said "it uses native CPU operations when possible". I very much hope it does so, duh - that's a given, not an accomplishment. 2016-07-04 12:18:23 well, its still better than javascript ... *g* 2016-07-04 12:18:45 that's not an accomplishment either. :P 2016-07-04 12:18:57 skarnet: It uses unique ownership and borrowing model for managing memory. No GC, no reference counting (actually it provides it as well, as optional, on top of its memory model), no allocating everything on heap. Everything around memory management is done on compile time, it doesn’t have any runtime overhead. 2016-07-04 12:19:43 uuuuh... what's the catch? what you just said is "it solves the halting problem". 2016-07-04 12:19:58 it makes coffe too? wow! it needs to be prioritized! :) 2016-07-04 12:20:25 skarnet: Please read https://doc.rust-lang.org/book/ownership.html, I guarantee that it will be interesting for you. 2016-07-04 12:20:44 will do. 2016-07-04 12:20:49 skarnet: It should be actually easier to understand for someone how know C. 2016-07-04 12:21:02 it tries allocate on stack? does that mean it will require bigger stack? 2016-07-04 12:21:40 musl has very small default stack size 2016-07-04 12:21:45 for threads 2016-07-04 12:22:37 ncopa: I don’t think so. Rust already supports musl for static compilation. 2016-07-04 12:23:36 ncopa: no, the footprint is not that much bigger 2016-07-04 12:23:42 a little bit, but not that much 2016-07-04 12:24:37 there are 3 pages to read to understand rust: https://doc.rust-lang.org/book/ownership.html, https://doc.rust-lang.org/book/references-and-borrowing.html and https://doc.rust-lang.org/book/lifetimes.html 2016-07-04 12:26:14 what I just read means that rust forbids weak aliases 2016-07-04 12:27:01 skarnet: the most awesome thing about rust is that you can use the #![no_std] attribute. that way you dont get the rust std at all. you can simple use your libc you want and get a complete native and indipenend binary out of it 2016-07-04 12:27:28 leo-unglaub: or write your own libc in rust… 2016-07-04 12:27:40 lol 2016-07-04 12:28:09 a C library written in rust :) 2016-07-04 12:28:10 leo-unglaub: yay for multiple incompatible versions, and companies providing their own rust compiler because their software won't compile or work with any other version 2016-07-04 12:28:13 for alpine you could use #![no_std] and then use extern crate x86_64-unknown-linux-musl. that way rust used musl and skips all stuff from the standard library, making sure that you have a small and secure binary that only depends on musl 2016-07-04 12:28:41 more market fragmentation is exactly what the world does NOT need 2016-07-04 12:28:42 everything you have in musl is available here to: https://doc.rust-lang.org/libc/x86_64-unknown-linux-musl/libc/index.html 2016-07-04 12:28:58 skarnet: wtf? there aren’t any other rust compilers (yet) 2016-07-04 12:29:07 skarnet: or do you mean just stable vs. nightly? 2016-07-04 12:29:54 oh, sorry, not their own compiler. Their own "standard" library. 2016-07-04 12:30:07 and that WILL happen. 2016-07-04 12:30:24 skarnet: i dont understand that complaint. there is only one rustc out there. rustc itself contains multiple components, yes. the chain goes: rust source -> HIR -> MIR -> LLVM IR -> binary 2016-07-04 12:30:56 ah, i get whant skarnet means ... 2016-07-04 12:30:58 and he has a point 2016-07-04 12:31:12 but thats exactly the same problem c has 2016-07-04 12:31:12 skarnet: I think that you don’t understand what it’s about… 2016-07-04 12:31:31 jirutka: nah, he has a point. but c has the same problem 2016-07-04 12:31:36 yes it has 2016-07-04 12:31:49 skarnet vs Rust lovers 2016-07-04 12:31:55 ACTION gets some popcorn 2016-07-04 12:31:58 \o/ 2016-07-04 12:31:59 so why would a new language willingly jump into the exact same mistakes that C did 2016-07-04 12:32:18 simple, to keep compat. because no one has the balls to drop c compat 2016-07-04 12:32:35 I'm talking about from a software design standpoint 2016-07-04 12:32:44 building a language infrastructure has been done many times 2016-07-04 12:32:55 and for system stuff, has been done extensively at least one: with C 2016-07-04 12:32:55 there’s just one rust stdlib; the point of `#[no_std]` is not to write your own stdlib for every project, but to be able to write e.g. kernels in Rust 2016-07-04 12:32:55 from a pure design standpoint you are right 2016-07-04 12:33:14 C has done much stuff right, and much stuff wrong 2016-07-04 12:33:24 I'd expect new language developers to actually LEARN from C's mistakes 2016-07-04 12:33:40 well, they did in a way 2016-07-04 12:33:51 they killed off race conditions 2016-07-04 12:33:56 they killed of memory leaks 2016-07-04 12:34:21 "let's just kill pointer aliases" isn't exactly a smart way to stop memory leaks 2016-07-04 12:34:26 it's more like a big hammer 2016-07-04 12:34:26 skarnet: what exactly do you mean with what you wrote? are you talking about no_std or about something else? 2016-07-04 12:34:49 no, thats now what they did 2016-07-04 12:35:03 they simple do a lot of compile time checks 2016-07-04 12:35:24 i mean you cannot say that the c way of handling strings is better than the rust way of doing it? 2016-07-04 12:35:28 skarnet: okay, please stop and read the articles; it seems that you’ve just made up some conclusions from first few sentences… 2016-07-04 12:35:38 jirutka: about no_std *and* everything else. You shouldn't need annotations in your source if you're not going to be using the standard library, this should be automatically inferred by the linker. 2016-07-04 12:35:46 even c guys after 10 years of c fuck up strings because its horrible .. and thats even excluding unicode 2016-07-04 12:36:49 skarnet: as I said, no_std is needed for some use cases like writing a kernel and programming some microchips, i.e. really low-level stuff 2016-07-04 12:37:38 and as I said, why would you need a specific annotation in your code to accomplish that 2016-07-04 12:37:58 skarnet: https://doc.rust-lang.org/book/no-stdlib.html 2016-07-04 12:39:00 skarnet: well, that comparison is not fair 2016-07-04 12:39:07 also in c you get some stuff by default 2016-07-04 12:39:32 skarnet: maybe before rust docs, read this http://www.garin.io/rust-vs-c-pitfalls 2016-07-04 12:39:39 int main () {return 0;} <- if you compile that without any includes you still depend on libc.so 2016-07-04 12:39:44 oh, ok. You need that to get rid of the runtime. 2016-07-04 12:42:04 leo-unglaub: the problem is that you wrote #[no_std] and skarnet started daydreaming what does it mean, instead of reading docs what it’s really about ;) 2016-07-04 12:42:20 well my point still stands 2016-07-04 12:42:23 he thought it meant something else, yes 2016-07-04 12:42:42 rust gives you a big runtime by default instead of inferring that you will need it 2016-07-04 12:42:59 skarnet: big runtime? heh, no 2016-07-04 12:43:31 what the std is in rust is the "language" in c 2016-07-04 12:43:46 from the page you linked: Rust’s standard library provides a lot of useful functionality, but assumes support for various features of its host system: threads, networking, heap allocation, and others. 2016-07-04 12:43:51 the std also contains the definition of all integers, floats, ... 2016-07-04 12:44:18 but he is right that the rust std is bigger than the c one 2016-07-04 12:44:24 there is no question about that 2016-07-04 12:44:41 fmt for example has no reason to be in std 2016-07-04 12:45:21 also all collections::* are nice, but should not be in std 2016-07-04 12:46:22 My general point, independent from the way things may or may not be implemented in Rust, is that the questions of safety etc. are *hard*, and that blindly supporting such or such language because "it will do it" is simply deferring the work of balancing solving those problems against writing flexible and efficient code to the compiler authors. 2016-07-04 12:46:47 Of course you can make a language with more guarantees than C. It would actually be hard to come up with a language with *less* guarantees. 2016-07-04 12:46:52 leo-unglaub: I dissagree, think about consequences, look at JS or Lua… no stdlib → A LOT of dependencies 2016-07-04 12:46:53 But that means _there will be tradeoffs_. 2016-07-04 12:47:25 And using a language with in-baked guards means that the compiler will decide of those tradeoffs for you. 2016-07-04 12:47:30 leo-unglaub: I’m not 100% sure about it know, but when you compile rust program in release mode, it strips of all unused code, right? 2016-07-04 12:47:59 skarnet: rust is not a cure ... you can write shit rust programs as well ... look at 90% of the rust software on github. but i am now using it for nearly a year and i am happy with it because it has reduces the number of memory bug i had to track down in my software quit a lot. 2016-07-04 12:48:01 You will gain safety, etc. etc. You will lose on other aspects. 2016-07-04 12:48:22 but again, of course you can write shit programs in rust, no question about that. it still depends on the programmer 2016-07-04 12:48:32 skarnet : of course, that’s why we have so many languages and not just one… 2016-07-04 12:49:20 and that's why I'm saying that for system stuff, nothing comes close to "good" (I'll settle for "decent") old C, which lets you have control. 2016-07-04 12:49:56 Dangerous? yes. Error-prone? yes. Horrible with UB pitfalls and such? definitely. 2016-07-04 12:50:32 I would love to have "friendly C" or "boring C", that would clean up all those silly UB cases. 2016-07-04 12:51:07 you dont have to sell me on c .. i have done hat for now 10 years of so .... and i still use it. but for a lot of my cases rust has proven to be a good alternative 2016-07-04 12:51:37 and I appreciate Rust for what it should aim at being: a higher-level language than C, for writing *applications* more easily, with a healthy dose of control, but a much healthier dose of safety 2016-07-04 12:51:58 Rust should not, however, try to be something that it's not. 2016-07-04 12:52:36 and "an alternative to C for system programming" it is definitely not. 2016-07-04 12:53:10 I'm now going to stop wasting time on this and get back to my work. 2016-07-04 12:55:39 skarnet: pardon, but you still don’t understand what Rust is… Rust is NOT a high-level application language, Rust is system programming language 2016-07-04 12:55:44 (ih, and jirutka: I have read the pages you linked. That's interesting, definitely, but not world-changing: I've had that internal memory model in my programs for a long time, it's a question of good programming practices. It's nice that the language enforces them, but *programmers should learn them*.) 2016-07-04 12:56:04 jirutka: oh, is it? then it will fail at it. End of story. 2016-07-04 12:56:19 jirutka: its hard to understand rust without seeing it in code 2016-07-04 12:56:26 sorry to interrupt, but maybe we could take this discussion to #rust or similar? 2016-07-04 12:56:53 ncopa: i think its over 2016-07-04 12:56:54 :) 2016-07-04 12:57:15 i have to do wash dishes and skarnet has to work again :) 2016-07-04 12:57:45 skarnet: I don’t understand why you’re so extremely stubborn… to be more clear, I respect your opinions, the problem is that you arguments are mostly invalid 2016-07-04 12:57:47 so soon... I haven't finished my popcorn yet :( 2016-07-04 12:58:23 coredumb: if you want popcorn ... get me started on libressl *g* 2016-07-04 12:58:41 skarnet: you’re arguing against lang that you don’t know; and you can’t understand it from few paragraphs 2016-07-04 12:59:41 Go back to work too before ncopa throws us all out. 2016-07-04 12:59:57 skarnet: I’m not saying that Rust is the best language ever, not at all, it has its tradeoff, I’m just saying that C is NOT superior and NOT the only right solution, actually the opposite… https://cve.mitre.org/ 2016-07-04 13:00:08 leo-unglaub: should just create #alpine-rust channel :D 2016-07-04 13:00:41 just #alpine-offtopic 2016-07-04 13:00:49 oh is there ? 2016-07-04 13:00:51 cool 2016-07-04 13:00:57 no, it is not 2016-07-04 13:01:04 but I sometimes feel there should be 2016-07-04 13:01:05 :( 2016-07-04 13:05:30 coredumb: I’ve finally switched to proper IRC client, so I can now correctly autocomplete your nickname… happy? :) 2016-07-04 13:05:45 \o/ 2016-07-04 13:06:20 ncopa: you use xfce4 as well, right? 2016-07-04 13:08:21 <^7heo> jirutka: bump #111 2016-07-04 13:08:34 <^7heo> builds and AFAIK, ready to merge. 2016-07-04 13:09:01 ^7heo: okay, I’ll look at it 2016-07-04 13:10:39 <^7heo> jirutka: thanks. 2016-07-04 13:11:01 <^7heo> if it can be merged soon, that'd be awesome: I am looking forward to using the latest release of gogs on alpine. 2016-07-04 13:11:24 <^7heo> (that isn't latest, that is just a fix for that version) 2016-07-04 13:11:33 <^7heo> (but I won't maintain a broken package) 2016-07-04 13:13:12 is anyone having issues with xen dom0? 2016-07-04 13:13:41 leo-unglaub: yes i use xfce4 2016-07-04 13:21:07 does your thunar also crash all the time when you rename files? 2016-07-04 13:23:17 no 2016-07-04 13:23:37 okay, thanks 2016-07-04 13:31:08 <^7heo> I don't understand the need for a file explorer 2016-07-04 13:31:17 <^7heo> unless you need media preview. 2016-07-04 13:31:27 <^7heo> then you might as well want a media explorer. 2016-07-04 13:31:34 that was not the question ... i am reading up on a bug and wanted feedback ;) 2016-07-04 13:32:02 <^7heo> jirutka: thanks a lot for the merge ;) 2016-07-04 13:32:17 ^7heo: np :) 2016-07-04 13:32:46 <^7heo> jirutka: how long does it usually take for a package in testing to be available in nl.a.o? 2016-07-04 13:33:19 ^7heo: usually several tens of minutes 2016-07-04 13:40:22 i have to go 2016-07-04 13:40:27 see you guys later 2016-07-04 13:40:38 keep up the work and dont get RUSTy ;) 2016-07-04 13:40:39 hahaha 2016-07-04 13:41:38 <^7heo> jirutka: so pretty quick 2016-07-04 13:41:42 <^7heo> kwel 2016-07-04 14:26:55 <^7heo> I hate UEFIs... 2016-07-04 14:27:00 <^7heo> they just randomly fuckup. 2016-07-04 14:42:39 ncopa: can we finish the cloudfoundry-cli package? :) 2016-07-04 14:46:08 ncopa: http://sprunge.us/RXZR this is the APKGBUILD for cloudfoundry-cli 2016-07-04 15:57:28 <^7heo> damn, it's challenging to setup encryption by hand with a deported header. 2016-07-04 16:05:12 mosez: done 2016-07-04 16:08:23 <^7heo> ncopa: do you know if mkinitfs supports the header luks parameter? 2016-07-04 16:08:42 <^7heo> because, with a deported header, it's necessary to have it. 2016-07-04 16:09:18 <^7heo> for now I have "cryptroot=/dev/sda --header /dev/sdb cryptdm=luks" 2016-07-04 16:09:36 <^7heo> but I fail to boot; I'm not sure if cryptroot is going to contain the --header /dev/sdb part. 2016-07-04 16:14:50 ^7heo: it does not 2016-07-04 16:15:50 but it should not be too hard to add support for it 2016-07-04 16:16:22 how do you specify the header on boot cmdline on other distros? 2016-07-04 16:19:49 <^7heo> I don't use other distros 2016-07-04 16:20:01 <^7heo> but with luksOpen it's like --header /dev/sdX 2016-07-04 16:20:06 <^7heo> or wherever it is located. 2016-07-04 16:20:17 <^7heo> and I can mount all the stuff by hand and all 2016-07-04 16:20:23 <^7heo> but when I mkinitfs it 2016-07-04 16:20:24 <^7heo> it fails. 2016-07-04 16:20:28 yes 2016-07-04 16:20:32 and i know why 2016-07-04 16:20:37 <^7heo> ok? 2016-07-04 16:20:49 it probably broke since v3.3 2016-07-04 16:20:52 <^7heo> oh 2016-07-04 16:21:00 <^7heo> bad luck, I'm using 3.3 2016-07-04 16:21:26 we need add support for it 2016-07-04 16:21:32 <^7heo> ok, I can do that. 2016-07-04 16:21:38 <^7heo> in nlplug-findfs? 2016-07-04 16:22:21 yes 2016-07-04 16:22:23 <^7heo> ok 2016-07-04 16:22:33 <^7heo> -h is already taken for the the help 2016-07-04 16:22:40 <^7heo> would it make sense to implement it with -H? 2016-07-04 16:22:55 <^7heo> or rather -d (for deported header) 2016-07-04 16:23:49 <^7heo> so in short, if I adapt initramfs-init to use/accept cryptheader; and update nlplug-findfs to recognize a flag for that 2016-07-04 16:23:52 <^7heo> would it work? 2016-07-04 16:23:56 <^7heo> or does it need more work? 2016-07-04 16:24:31 yes, that should work 2016-07-04 16:24:34 <^7heo> good. 2016-07-04 16:24:40 <^7heo> Doing that tonight. 2016-07-04 16:24:42 cryptheader=/dev/sdb 2016-07-04 16:24:45 right? 2016-07-04 16:24:49 <^7heo> yeah 2016-07-04 16:24:53 sounds good 2016-07-04 16:24:55 <^7heo> or /dev/sdXY 2016-07-04 16:25:12 <^7heo> if you need other partitions 2016-07-04 16:25:18 <^7heo> but yeah essentially, that. 2016-07-04 16:25:25 ofc 2016-07-04 16:25:26 hum 2016-07-04 16:25:40 actually, it might be a bit complicated 2016-07-04 16:25:46 might not be so easy 2016-07-04 16:25:54 <^7heo> yeah I expected so 2016-07-04 16:26:06 <^7heo> because nlplug-findfs is just to find the device 2016-07-04 16:26:24 <^7heo> not automatically do the rest of the work (luksOpen and all) 2016-07-04 16:26:33 it will need to wait til both are found 2016-07-04 16:26:40 <^7heo> so that would lack the passing of the --header argument to the underlying luksOpen 2016-07-04 16:26:50 both the cryptroot and cryptheader 2016-07-04 16:26:56 <^7heo> ah yeah true 2016-07-04 16:27:02 <^7heo> and that wouldn't support a file-based cryptheader. 2016-07-04 16:27:08 <^7heo> I would also like to support that. 2016-07-04 16:27:19 we can do that later 2016-07-04 16:27:30 <^7heo> maybe 2016-07-04 16:27:36 <^7heo> depends how harder it is. 2016-07-04 16:27:41 because we currently do mount found devices to look for apkovl and or .boot_repository 2016-07-04 16:27:45 <^7heo> if it's just "accept a file instead of /dev/whatever 2016-07-04 16:27:48 <^7heo> " 2016-07-04 16:27:50 <^7heo> it would be okay 2016-07-04 16:28:02 not much harder than that 2016-07-04 16:28:44 <^7heo> the comments in https://skrilnetz.net/bullet-proof-data-encryption-with-luks-and-a-detached-header/ describe how to use a file-based header with cryptsetup 2016-07-04 16:30:22 <^7heo> but yeah there's a loop device setup and all 2016-07-04 16:30:25 <^7heo> so more complicated. 2016-07-04 16:30:26 <^7heo> so later. 2016-07-04 16:31:27 <^7heo> okay so, I will add the support for cryptheader in initramfs-init and nlplug-findfs 2016-07-04 16:31:32 <^7heo> and then I will do some testing 2016-07-04 16:31:42 <^7heo> let's see how that goes. 2016-07-04 16:32:02 <^7heo> it will probably fail on "/dev/sda isn't a valid LUKS device" 2016-07-04 16:32:14 <^7heo> but that's fine then, I will have went further. 2016-07-04 16:32:39 <^7heo> and that will mean that the initfs is trying to mount /dev/sda already; and just needs the header passed to it. 2016-07-04 16:33:47 <^7heo> ncopa: nlplug is from __20h__? 2016-07-04 16:34:03 <^7heo> it looks a lot like a suckless source. 2016-07-04 16:34:08 yes 2016-07-04 16:34:17 i think bits are from there 2016-07-04 16:34:28 <^7heo> yeah makes sense; as suckless is pretty sane. 2016-07-04 16:35:09 <^7heo> is nlplug-findfs the binary from the nlplug source? 2016-07-04 16:35:48 <^7heo> nevermind, I'll check aports 2016-07-04 16:35:58 its a fork 2016-07-04 16:36:08 or rewrite 2016-07-04 16:36:10 <^7heo> ok 2016-07-04 16:39:21 <^7heo> weird 2016-07-04 16:39:31 <^7heo> http://git.alpinelinux.org/cgit/mkinitfs/tree/nlplug-findfs.c and http://git.alpinelinux.org/cgit/user/ncopa/nlplug/tree/nlplug.c 2016-07-04 16:39:50 <^7heo> no idea what the latter is for. 2016-07-04 16:40:00 <^7heo> or is it the original version? 2016-07-04 16:43:06 yes 2016-07-04 16:43:15 then it got merged into mkinitfs 2016-07-04 16:43:56 <^7heo> I see. 2016-07-04 16:44:17 <^7heo> Okay so the luks API interfacing is done by nlplug-findfs 2016-07-04 16:44:30 <^7heo> therefore I have to do the header implementation there. 2016-07-04 16:44:55 <^7heo> looks interesting; but I fail to find the header api for deported headers so far. 2016-07-04 16:46:18 <^7heo> I believe that in this case it's necessary to use int crypt_init_by_name_and_header () instead. 2016-07-04 16:47:44 <^7heo> (instead of crypt_init()) 2016-07-04 17:36:15 <^7heo> ncopa: for a patch to git.alpinelinux.org 2016-07-04 17:36:27 <^7heo> should I submit with a bug in bugs.a.o? 2016-07-04 17:37:05 sure 2016-07-04 17:37:19 or send it to alpine-devel 2016-07-04 17:39:16 <^7heo> nah it's easier for me to do it via the b.a.o interface 2016-07-04 17:39:24 <^7heo> yeah that, algitbot. 2016-07-04 17:39:36 <^7heo> 3.3.4 hasn't been released yet? 2016-07-04 17:40:23 <^7heo> I used "category: security" since I don't know if it should go in setup scripts or toolchain 2016-07-04 17:40:32 <^7heo> ah no boot sequence 2016-07-04 17:46:40 <^7heo> #5868 created. Will add the patch there. 2016-07-04 18:20:08 <^7heo> ncopa: I see what you meant with "it will need to wait til both are found" 2016-07-04 18:20:48 yes. we do this while coldplugging 2016-07-04 18:20:53 <^7heo> I have to change the logic of dispatch_uevent 2016-07-04 18:21:49 <^7heo> but it's a good thing that there are both conf->crypt_device and conf->crypt_devnode. 2016-07-04 18:22:09 <^7heo> that way; it's easy to know if it has been found. 2016-07-04 18:22:24 <^7heo> since the memset() happening at the top of main() 2016-07-04 18:26:34 yes, you will have to also look for crypt_header and crypt_header_devnode in similar way 2016-07-04 18:26:47 <^7heo> yeah 2016-07-04 18:26:48 <^7heo> done. 2016-07-04 18:26:53 <^7heo> I mean 2016-07-04 18:27:00 <^7heo> you will definitely review that I guess. 2016-07-04 18:27:06 <^7heo> but I think it's gonna work. 2016-07-04 18:27:13 <^7heo> can't confirm here, can't build it easily yet. 2016-07-04 18:28:13 <^7heo> I essentially copy/pasted the block for if (searchdev(ev, conf->crypt_device, NULL, NULL)) then strncpy; after removing the "start_cryptsetup" call... 2016-07-04 18:28:42 <^7heo> then replaced the crypt_device by crypt_header and crypt_devnode by crypt_devnode_header in the second block 2016-07-04 18:28:50 <^7heo> so it can find either first. 2016-07-04 18:28:54 git diff | tpaste 2016-07-04 18:28:59 <^7heo> yeah 2016-07-04 18:29:11 <^7heo> gimme a sec, finishing the diff so you won't have to review more than necessary 2016-07-04 18:46:01 this refacoring might make things nicer: http://tpaste.us/GmBE 2016-07-04 18:48:48 <^7heo> ncopa: http://ix.io/10kb 2016-07-04 18:49:44 <^7heo> wait, did I miss "device"? 2016-07-04 18:50:25 <^7heo> yeah apparently so. 2016-07-04 18:50:47 <^7heo> ah no I missed "name" 2016-07-04 18:51:18 <^7heo> which is used. 2016-07-04 18:51:37 <^7heo> not a lot, but enough for my patch to be broken. 2016-07-04 18:51:47 <^7heo> thanks for the refactoring ncopa; I'm gonna use it. 2016-07-04 18:52:35 <^7heo> ncopa: are you fine with me taking it, or do you want to commit first and I merge with your commit? 2016-07-04 18:52:49 i'd like it in a separate commit 2016-07-04 18:53:05 <^7heo> me too. 2016-07-04 18:53:11 I'll commit it 2016-07-04 18:53:17 <^7heo> so please commit it to mkinitfs asap :) 2016-07-04 18:53:19 <^7heo> so I can merge. 2016-07-04 18:53:32 <^7heo> it's really better to do it this way even if I change nothing. 2016-07-04 18:54:12 +1 2016-07-04 18:54:48 ^7heo: pushed 2016-07-04 18:55:05 <^7heo> awesome. 2016-07-04 18:55:31 i think we should move the crypt logic to a separate function 2016-07-04 18:56:25 <^7heo> yeah well, we can refactor later; but with what you just commited; it's gonna be easier anyway. 2016-07-04 18:56:27 so something like: if (search_cryptdev(ev, &conf->crypt)) { start_crypt(...); } 2016-07-04 18:56:50 <^7heo> well, look at my diff, how I moved the start_crypt away. 2016-07-04 18:56:57 yes 2016-07-04 18:57:07 <^7heo> that needs to be done this way; so no matter in what order the devices come up 2016-07-04 18:57:12 <^7heo> it will fire when both are there. 2016-07-04 18:57:35 exactly 2016-07-04 18:57:40 but i do worry about one thing 2016-07-04 18:57:41 <^7heo> anyway, thanks a lot for the commit; I'll refactor asap 2016-07-04 18:57:44 <^7heo> yep? 2016-07-04 18:58:08 lets say we find both, and fire the start_crypt 2016-07-04 18:58:29 then next uevent, which is block device 2016-07-04 18:58:43 the conditions for firing the start_crypt will still be there 2016-07-04 18:58:48 so i think it will fire again 2016-07-04 18:58:51 <^7heo> ah 2016-07-04 18:58:53 <^7heo> true. 2016-07-04 18:58:58 ;) 2016-07-04 18:59:14 <^7heo> well, I'll have to do something about that then. 2016-07-04 18:59:23 ;) 2016-07-04 18:59:40 <^7heo> thanks for catching that one. 2016-07-04 18:59:51 <^7heo> it wasn't necessarily trival. 2016-07-04 18:59:53 <^7heo> trivial* 2016-07-04 19:00:31 but as i said, i'd like to move that logic to separate function 2016-07-04 19:00:38 <^7heo> yeah 2016-07-04 19:00:41 <^7heo> but wait 2016-07-04 19:00:58 <^7heo> before, the loop would also continue to loop after the crypt_setup would have been started, right? 2016-07-04 19:01:04 <^7heo> how come this didn't happen? 2016-07-04 19:01:18 <^7heo> ooh; because there is only ONE device that had the start_crypt in it... 2016-07-04 19:01:20 because the same device wouldnt show up more than once 2016-07-04 19:01:22 <^7heo> yeah yeah 2016-07-04 19:01:23 <^7heo> sorry 2016-07-04 19:01:23 <^7heo> :D 2016-07-04 19:01:38 <^7heo> my fingers are faster than my brain now. 2016-07-04 19:01:42 no, i was just waiting for that question :) 2016-07-04 19:01:45 <^7heo> thanks for confirming tho. 2016-07-04 19:01:48 <^7heo> :D 2016-07-04 19:01:54 ok i gotta go 2016-07-04 19:01:58 thanks for looking into this! 2016-07-04 19:02:02 <^7heo> you're welcome 2016-07-04 19:02:05 <^7heo> and I need it 2016-07-04 19:02:06 i look forward to your patch 2016-07-04 19:02:12 <^7heo> so, me too ;D 2016-07-04 19:02:21 <^7heo> Guten feierabend! 2016-07-04 19:02:22 <^7heo> o/ 2016-07-04 19:05:29 <^7heo> ncopa: you missed one thing your patch; though. You didn't memset the new struct. in conf->crypt. 2016-07-04 19:05:42 <^7heo> so it can't be expected to behave like it did before. 2016-07-04 19:07:01 <^7heo> I actually am not sure about this; I know too little about how structs are stored. 2016-07-04 19:07:40 <^7heo> maybe the fact that the struct is into the other struct is reserving the space in the same memory, and thus the memset is memsetting it too... 2016-07-04 19:07:56 <^7heo> but I dunno why I would feel 2016-07-04 19:08:00 <^7heo> "safer" 2016-07-04 19:08:17 <^7heo> to use a p_struct and malloc/memset/free that explicitely. 2016-07-04 19:08:30 <^7heo> even if... well... it's really superfluous. 2016-07-04 20:00:45 <^7heo> ncopa: added patch to #5868 2016-07-04 20:01:25 <^7heo> ncopa: I also have that http://ix.io/10la suggestion for the patch, but I wasn't sure about the correctness of this code, so I didn't add it yet. 2016-07-04 20:07:10 ncopa: thanks. i have also submitted updates for sassc and libsass. now i will prepare even more :) 2016-07-04 20:10:25 what was the url to see the build queue status? 2016-07-04 20:10:59 mosez: http://build.alpinelinux.org/ 2016-07-04 20:11:09 thanks 2016-07-04 20:12:22 clandmeter: is this stuff oss? i'm thinking about a build system for personal packages 8) 2016-07-04 20:14:28 which "stuff"? 2016-07-04 20:16:42 the tools behind build.al.org 2016-07-04 20:17:50 yes its very simple 2016-07-04 20:18:00 check the src of that page 2016-07-04 20:21:13 ah, communicating to mqtt 2016-07-04 20:50:52 yay... terraform incoming 8) 2016-07-05 06:19:24 i'm working on gcc 6.1 currently. it seems to be okish now. 2016-07-05 06:19:35 the pending commit is http://sprunge.us/ajUc 2016-07-05 06:58:16 fabled: nice. 2016-07-05 06:58:26 except better support for arm, what can we expect? 2016-07-05 07:01:49 https://gcc.gnu.org/gcc-6/changes.html :) 2016-07-05 07:09:30 ok, ill research it when i have a few days off :) 2016-07-05 07:50:28 ncopa: morning. i'd like to bump wxgtk2.8 to wxgtk3.0, but the version number might be misleading: wxwidgets still uses gtk2, but people might think it's a new build with gkt3 support. what do you think? 2016-07-05 07:51:16 wasn't there a similar issue with webkitgtk? 2016-07-05 07:52:40 yes 2016-07-05 07:52:57 there are no wxgtk for gtk3? 2016-07-05 07:53:15 are there any project that stil require wxgtk2.8? 2016-07-05 07:53:26 or can we remove wxgtk2.8 2016-07-05 08:12:52 arch have just called it wxgtk now, which i think makes sense 2016-07-05 08:15:36 we should probably keep wxgtk2.8 as a seperate package though, as renaming a package like that will break stuff of course 2016-07-05 08:16:44 does that sound ok? 2016-07-05 08:17:21 yes 2016-07-05 08:17:31 how many packages needs wxgtk2.8? 2016-07-05 08:30:48 in edge, 5 2016-07-05 08:31:39 ok 2016-07-05 08:31:45 we will need wxgtk2.8 then 2016-07-05 08:34:00 I'll create a new package called wxgkt, then patch the 5 packages to build then against the new wxgtk so that we can remove wxgkt2.8 2016-07-05 08:34:23 it's only really 3 packages, as two are subpackages of wxgtk2.8! 2016-07-05 08:34:47 they are: truecrypt, amule and audacity 2016-07-05 08:39:31 check if any of those supports wxgtk3 2016-07-05 08:39:53 ^7heo: thanks for your patch! 2016-07-05 08:40:07 i'd like to split it 2016-07-05 08:40:23 so nlplug-findfs is in separate commit from the initramfs-init 2016-07-05 08:40:58 also, please use `git format-patch` so I can apply with you as author 2016-07-05 08:41:30 there are a few missing `struct` which makes it fail to compile 2016-07-05 08:41:48 http://tpaste.us/ARv4 2016-07-05 08:44:44 the fixes: http://tpaste.us/GnbV 2016-07-05 08:44:47 <^7heo> ncopa: ok, doing this when I reach work 2016-07-05 08:44:56 i think i can do it 2016-07-05 08:45:06 <^7heo> ok cool :) 2016-07-05 08:45:15 i manually edited the patch.diff so i could git am it 2016-07-05 08:45:25 i removed the initramfs-init stuff 2016-07-05 08:45:31 <^7heo> ok 2016-07-05 08:45:44 and i can git commit --amend the above fixes 2016-07-05 08:45:48 so it compiles at least 2016-07-05 08:46:00 <^7heo> yeah 2016-07-05 08:46:06 there are some mem leaks too in error path 2016-07-05 08:46:17 in case of error it will leak mem 2016-07-05 08:46:32 i think we should have tha params on stack instead of malloc it 2016-07-05 08:46:37 i can fix that 2016-07-05 08:46:51 i also think we should refactor the structs a bit too 2016-07-05 08:46:54 <^7heo> wait wat? mem leak? where? 2016-07-05 08:47:31 in cryptsetup_thread 2016-07-05 08:47:31 <^7heo> ah cause the free after error 2016-07-05 08:47:51 yes 2016-07-05 08:47:59 if crypt_init fails it will not free params 2016-07-05 08:48:10 same if crypt_load fails 2016-07-05 08:48:23 i think we put params buffer on stack 2016-07-05 08:48:32 to avoid that 2016-07-05 08:48:50 <^7heo> yeah but if the process is reaped, there's no more leak right? 2016-07-05 08:49:13 yes. its not a problem. its just "best practices" 2016-07-05 08:49:24 <^7heo> yah ok 2016-07-05 08:49:31 <^7heo> you're right anyway 2016-07-05 08:49:59 ok if I add this: http://tpaste.us/GnbV with you as author? 2016-07-05 08:50:58 the commit will in total end up as: http://tpaste.us/2zr5 2016-07-05 08:51:04 and i fix the leak etc from there 2016-07-05 08:51:28 <^7heo> totally 2016-07-05 08:51:34 thanks! 2016-07-05 08:51:56 actually, i'll also edit some style fixes 2016-07-05 08:52:16 <^7heo> I didn't see that last crypt_devnode_header 2016-07-05 08:52:28 gcc did :) 2016-07-05 08:52:28 <^7heo> I feel sloppy now 2016-07-05 08:52:45 i think its kinda good given that you didnt even compile test it :) 2016-07-05 08:52:48 <^7heo> thanks for catching tho 2016-07-05 08:53:10 style fixes: http://tpaste.us/GXBv 2016-07-05 08:54:43 i'm not sure the (size_t)atoi is a good idea either 2016-07-05 08:55:06 it means you need to have your offset in the first 4G on your disk 2016-07-05 08:55:13 on your partition 2016-07-05 08:55:25 atleast on 32bit 2016-07-05 09:02:09 <^7heo> ncopa: but it's a size_t in the API... 2016-07-05 09:02:14 <^7heo> so... 2016-07-05 09:02:21 atoi 2016-07-05 09:02:46 int atoi() 2016-07-05 09:02:50 will return an int 2016-07-05 09:03:46 <^7heo> yeah 2016-07-05 09:05:08 <^7heo> I mean: https://gitlab.com/cryptsetup/cryptsetup/wikis/API/structcrypt__params__luks1.html 2016-07-05 09:06:23 yes 2016-07-05 09:06:31 so we should not use atoi 2016-07-05 09:06:40 we should use seomthing that is size_t safe 2016-07-05 09:09:54 <^7heo> yeah I searched for that 2016-07-05 09:10:05 sscanf %zu 2016-07-05 09:10:10 <^7heo> but the stackoverflow answer I found about it said: use atoi 2016-07-05 09:10:18 <^7heo> thanks for showing me better tho. 2016-07-05 09:10:38 <^7heo> I should find that answer back and downvote it with a comment and answer that sscanf thing. 2016-07-05 09:10:50 http://stackoverflow.com/questions/32325479/how-to-get-size-t-from-string 2016-07-05 09:11:08 <^7heo> cool 2016-07-05 09:11:23 <^7heo> I can even downvote without answering, with just a link ;) 2016-07-05 09:12:16 <^7heo> that was the answer: http://stackoverflow.com/questions/10510077/size-t-convert-cast-to-string-in-c 2016-07-05 09:12:23 <^7heo> andt he duplicate is wrong then 2016-07-05 09:12:24 <^7heo> the* 2016-07-05 09:14:37 <^7heo> so, basically, should I write the sscanf part? 2016-07-05 09:14:51 <^7heo> because, I can apply the diffs you sent 2016-07-05 09:14:56 <^7heo> but I'm not sure if you sent all you changed. 2016-07-05 09:15:02 yes please 2016-07-05 09:15:06 i am still chaning things 2016-07-05 09:15:15 changing 2016-07-05 09:18:01 <^7heo> ok 2016-07-05 09:18:10 <^7heo> I patched my commits with the corrections you sent. 2016-07-05 09:18:20 <^7heo> So next patch I send will be including them. 2016-07-05 09:18:29 ok 2016-07-05 09:18:37 <^7heo> and sorry for breaking the code style. 2016-07-05 09:18:42 np 2016-07-05 09:18:53 <^7heo> I'm used on putting the opening curly brackets on next line; I like it a lot. 2016-07-05 09:19:11 <^7heo> but I totally get that it artificially increases the SLOC for no valid reason 2016-07-05 09:20:00 i dont have strong opinion there, except that its better to be consistent than use your own prefered style 2016-07-05 09:21:02 memleak fix: http://tpaste.us/2LO4 2016-07-05 09:21:12 i'll do a struct refactoring too 2016-07-05 09:22:15 <^7heo> but the memleak fix is yours, I won't push it in my commit. 2016-07-05 09:22:21 <^7heo> or I will push it as a separate commit 2016-07-05 09:22:42 doesnt matter 2016-07-05 09:23:02 <^7heo> ok 2016-07-05 09:23:17 <^7heo> never seen alloca before. 2016-07-05 09:24:20 chould also done: struct crypt_params_luks1 paramsbuf; struct crypt_params_luks1 params = ¶msbuf; 2016-07-05 09:31:57 <^7heo> chould? 2016-07-05 09:32:01 <^7heo> could or should? 2016-07-05 09:32:11 <^7heo> oh 2016-07-05 09:32:11 could 2016-07-05 09:32:15 <^7heo> sorry yeah I reread 2016-07-05 09:32:18 <^7heo> with the lines above 2016-07-05 09:32:20 <^7heo> makes sense. 2016-07-05 09:36:29 struct crypt_params_luks1 paramsbuf; struct crypt_params_luks1 params = ¶msbuf; 2016-07-05 09:36:38 methinks you forgot a * somewhere 2016-07-05 09:36:48 ofc 2016-07-05 09:37:07 struct crypt_params_luks1 *params = ¶msbuf; 2016-07-05 09:37:09 <^7heo> yeah 2016-07-05 09:37:16 <^7heo> doesn't matter tho, the idea is good. 2016-07-05 09:37:27 in this case i kinda like alloca better 2016-07-05 09:37:29 <^7heo> gives a pointer 2016-07-05 09:37:33 <^7heo> doesn't need a free. 2016-07-05 09:37:46 <^7heo> but yeah, I didn't know alloca 2016-07-05 09:37:59 I hate alloca with a passion 2016-07-05 09:38:13 :) 2016-07-05 09:38:13 <^7heo> warum? 2016-07-05 09:38:18 it's not portable, it's unsafe, it goes against expectations 2016-07-05 09:38:45 <^7heo> yeah I see what you mean 2016-07-05 09:38:48 oh 2016-07-05 09:38:51 its not in posix 2016-07-05 09:38:53 <^7heo> no 2016-07-05 09:38:57 no it's not 2016-07-05 09:39:03 <^7heo> I'm gonna go for the other alternative ncopa if you're okay with that. 2016-07-05 09:39:03 then the other is better 2016-07-05 09:39:07 <^7heo> I prefer that trick much more. 2016-07-05 09:39:08 yes 2016-07-05 09:39:31 <^7heo> I'm glad I learned about alloca tho 2016-07-05 09:39:34 <^7heo> now I know more. 2016-07-05 09:39:46 declaring structs in the stack early on and passing around pointers to them is a perfectly standard C idiom 2016-07-05 09:39:48 <^7heo> but I don't like it either, I have to agree with skarnet here. 2016-07-05 09:39:58 if its not in posix, then better unlearn it :) 2016-07-05 09:40:08 <^7heo> ncopa: I have to read code sometimes ;) 2016-07-05 09:40:24 <^7heo> it's not hard to remember: alloca == malloc + atexit + nonposix. 2016-07-05 09:40:34 not atexit. 2016-07-05 09:40:40 <^7heo> ah? 2016-07-05 09:40:41 at exit of the _function_ 2016-07-05 09:40:43 fabled: can you take a look at http://patchwork.alpinelinux.org/patch/2134/ 2016-07-05 09:40:44 <^7heo> oh ok 2016-07-05 09:41:00 <^7heo> hence why it can't be ported. 2016-07-05 09:41:10 <^7heo> I see. 2016-07-05 09:41:21 that's why it's non-intuitive: it sets the scope to the current function, not the current block 2016-07-05 09:41:25 unlike anything else in C 2016-07-05 09:41:35 <^7heo> "Normally, gcc(1) translates calls to alloca() with inlined code." 2016-07-05 09:41:46 <^7heo> — man alloca 2016-07-05 09:41:56 "Normally, you shouldn't care what gcc does" 2016-07-05 09:42:01 <^7heo> yeah totally. 2016-07-05 09:42:12 <^7heo> but that's why it works I guess. 2016-07-05 09:42:33 <^7heo> you're right to hate it I think; given that there are alternatives, which are MUCH nicer. 2016-07-05 09:42:43 yeah. I like my stack clean. 2016-07-05 09:43:29 I like my heap empty, too, but if I can't predict what I'm going to push on the stack, then heap it is. 2016-07-05 09:43:45 <^7heo> yeah, makes sense. 2016-07-05 09:44:05 <^7heo> games make an intensive use of heap. 2016-07-05 09:44:12 <^7heo> for that very reason. 2016-07-05 09:44:21 <^7heo> because a predictable game is hardly fun. 2016-07-05 09:57:36 <^7heo> Anyway, about the patch, I still have to separate the changes and then I'll send the new version. 2016-07-05 10:09:50 <^7heo> moin jirutka 2016-07-05 10:10:02 ^7heo hi 2016-07-05 10:19:29 <^7heo> ncopa, skarnet: what do you think of http://ix.io/10yJ btw? 2016-07-05 10:19:34 <^7heo> I'm not too sure about it 2016-07-05 10:20:00 <^7heo> but I wanted to remove copy/pasted code. 2016-07-05 10:20:07 understand 2016-07-05 10:20:09 interesting 2016-07-05 10:20:27 i ws thinking of move both to a separate function 2016-07-05 10:20:57 if (search_cryptdev(ev, &conf->crypt) start_cryptsetup(conf); 2016-07-05 10:21:07 yeah, that probably works, but a separate function would be cleaner 2016-07-05 10:21:18 <^7heo> that gives a lot of warnings in my vi-syntastic 2016-07-05 10:21:19 with 2 function invocations 2016-07-05 10:21:31 <^7heo> So I guess I would rather have a function. 2016-07-05 10:21:38 the idea of looping is nice though 2016-07-05 10:21:55 run_now is a bit misleading 2016-07-05 10:22:00 <^7heo> yeah well 2016-07-05 10:22:09 <^7heo> if you have a better name for it ;) 2016-07-05 10:22:14 may_run 2016-07-05 10:22:19 <^7heo> yeah ok. 2016-07-05 10:22:20 i am thnking we dont need it at all 2016-07-05 10:22:25 <^7heo> why? 2016-07-05 10:22:31 <^7heo> what you said yesterday is valid. 2016-07-05 10:22:40 <^7heo> it will fire multiple times now. 2016-07-05 10:22:47 <^7heo> if we have that run_now it won't. 2016-07-05 10:22:47 also 2016-07-05 10:22:52 its broken as is 2016-07-05 10:22:57 <^7heo> ah? 2016-07-05 10:23:01 <^7heo> what did I break? 2016-07-05 10:23:07 conf->crypt_data.devnode will never be NULL 2016-07-05 10:23:16 <^7heo> ah it's not broken in my version then 2016-07-05 10:23:17 <^7heo> ;) 2016-07-05 10:23:24 <^7heo> I fixed that already. 2016-07-05 10:23:30 you should check conf->crypt_data.devnode[0] 2016-07-05 10:24:03 <^7heo> oh wait 2016-07-05 10:24:08 <^7heo> no I didn't fix THAT. 2016-07-05 10:24:10 <^7heo> I fixed something else. 2016-07-05 10:24:20 <^7heo> thanks for reporting. 2016-07-05 10:25:24 <^7heo> wait ncopa 2016-07-05 10:25:30 <^7heo> isn't that about what I wrote yesteday? 2016-07-05 10:25:38 <^7heo> 21:05 < ^7heo> ncopa: you missed one thing your patch; though. You didn't memset the new struct. in conf->crypt. 2016-07-05 10:25:46 probably :) 2016-07-05 10:26:02 <^7heo> s/your/in &/ 2016-07-05 10:26:45 <^7heo> but I was expecting the new struct to be contained in the bigger struct, mem-wise. 2016-07-05 10:26:52 <^7heo> and therefore, to be memset with it. 2016-07-05 10:26:56 <^7heo> isn't it so? 2016-07-05 10:27:52 <^7heo> because of struct in struct, I'm not sure how it behaves. 2016-07-05 10:27:57 <^7heo> ncopa, skarnet: do you know? 2016-07-05 10:28:27 <^7heo> we have that struct that contains two struct in it... 2016-07-05 10:28:29 strictly speaking, you shouldn't memset structs. 2016-07-05 10:28:31 <^7heo> and we do a memset on it. 2016-07-05 10:28:39 <^7heo> that is from the original code. 2016-07-05 10:28:39 memset will clear struct in struct 2016-07-05 10:28:40 Because there may be padding you don't know about. 2016-07-05 10:28:47 <^7heo> yeah so then NULL it is. 2016-07-05 10:28:49 <^7heo> or? 2016-07-05 10:28:57 <^7heo> skarnet: true. 2016-07-05 10:29:19 <^7heo> it's cleaner to init the struct field by field. 2016-07-05 10:29:25 What I like to do is to #define FOOBAR_ZERO { .field1 = 0, .field2 = 0, ... } 2016-07-05 10:29:38 <^7heo> yeah 2016-07-05 10:29:43 and initialize my structs with: struct foobar_s foo = FOOBAR_ZERO ; 2016-07-05 10:29:48 <^7heo> yeah gotcha 2016-07-05 10:29:50 <^7heo> nice ;) 2016-07-05 10:30:15 BUT\ 2016-07-05 10:30:16 <^7heo> ? 2016-07-05 10:30:37 if you know that all your fields are numeric and 0 is the neutral value 2016-07-05 10:30:59 then you can do memset(&foo, sizeof(struct foobar_s), 0) 2016-07-05 10:31:09 because the sizeof will take padding into account 2016-07-05 10:31:12 <^7heo> well, in the case of a pointer, it works too. 2016-07-05 10:31:14 <^7heo> it goes for NULL. 2016-07-05 10:31:19 yeah, that works too 2016-07-05 10:31:28 that doesn't work with opaque types though. 2016-07-05 10:31:37 memset(target, value, size) 2016-07-05 10:31:49 eh, I always mix those 2016-07-05 10:31:53 <^7heo> yeah so 0, sizeof 2016-07-05 10:31:55 <^7heo> but same idea. 2016-07-05 10:32:05 <^7heo> skarnet: nice to know. 2016-07-05 10:32:17 don't do it if you have stuff like a regex_t in your struct though 2016-07-05 10:32:25 <^7heo> skarnet: is a struct in a struct an opaque type? 2016-07-05 10:32:38 not if you know what's in your inside struct 2016-07-05 10:32:58 <^7heo> it's some integer and pointer. 2016-07-05 10:33:02 then it's ok 2016-07-05 10:33:20 <^7heo> the only two types I can see to cause problems in the main struct are: pthread_t and pthread_mutex_t 2016-07-05 10:33:28 oh 2016-07-05 10:33:31 then don't do it 2016-07-05 10:33:33 <^7heo> not sure about those. 2016-07-05 10:33:36 nope 2016-07-05 10:33:48 <^7heo> they're gonna cause problems with padding? 2016-07-05 10:33:48 the implementation isn't specified 2016-07-05 10:33:51 <^7heo> ok 2016-07-05 10:33:57 <^7heo> how to init them tho? 2016-07-05 10:34:22 not with padding, but for all you know, (pthread_mutex_t)0 is very special and crashes your process :D 2016-07-05 10:35:02 if you have to init them, then the spec should define a safe value to init them with; use that value to init field by field 2016-07-05 10:35:17 if you don't have to init them, just init the other fields and leave that one uninitted 2016-07-05 10:36:44 http://tpaste.us/GZ7d 2016-07-05 10:37:15 this one first: http://tpaste.us/3lDn 2016-07-05 10:38:21 I'm worried that you need threads in nlplug_findfs 2016-07-05 10:38:48 yup, it makes things a bit trickier 2016-07-05 10:38:53 when I last checked that piece of code it was very simple and single-threaded 2016-07-05 10:39:06 I'm worried it's turning into a kitchen sink 2016-07-05 10:40:33 we want it multithreaaded so that we dont have idling cpu cores 2016-07-05 10:40:47 that is for performance 2016-07-05 10:41:33 it also solves the ordering problem 2016-07-05 10:41:42 do you have enough shared state that you can't just use multiprocess ? 2016-07-05 10:42:16 what if the crypt device shows up before the keyboard dirvier is loaded? 2016-07-05 10:42:27 then will you not be able to enter passphrase 2016-07-05 10:43:02 so now, we will continue load the drivers while waiting for user to enter password 2016-07-05 10:43:24 are you reimplementing a service manager in the initramfs 2016-07-05 10:43:34 correct 2016-07-05 10:43:50 kill it with fire 2016-07-05 10:44:01 well 2016-07-05 10:44:09 its a small, very specialized 2016-07-05 10:44:30 the only thing it needs to do is find all components needed for setting up the root fs 2016-07-05 10:44:45 it is not a service manager really 2016-07-05 10:45:15 we dont start/stop services 2016-07-05 10:45:22 just wait until next year 2016-07-05 10:45:41 I'll apply my favorite text editor to it 2016-07-05 10:45:48 the axe 2016-07-05 10:46:30 well, only if you need editor to set up your root fs 2016-07-05 10:46:48 to set up your root fs you need: 2016-07-05 10:46:54 load kernel modules 2016-07-05 10:46:58 support for cryptsetup 2016-07-05 10:47:02 support for raid 2016-07-05 10:47:08 support for lvm 2016-07-05 10:47:38 cryptsetup requires you to have drivers for keyboard 2016-07-05 10:47:54 yeah, we talked about it 2016-07-05 10:48:18 then i need be able to stack crypt/raid/lvm in any order 2016-07-05 10:48:30 so i can have lvm on top of mdadm 2016-07-05 10:48:35 or opposite 2016-07-05 10:48:54 can have crypt on top of either mdadm or lvm 2016-07-05 10:48:59 or have lvm on top of crypt 2016-07-05 10:49:43 crypt over lvm over crypt over raid 2016-07-05 10:49:46 need to find the root if its specified as LABEL=... or UUID=... or /dev/mapper/something or /dev/sdXy 2016-07-05 10:50:03 crypt over crypt wont work 2016-07-05 10:50:09 pity 2016-07-05 10:50:26 but lvm/raid over lvm/raid/crypt will 2016-07-05 10:50:28 well 2016-07-05 10:50:34 i think you can only have one crypt 2016-07-05 10:50:43 so radi over crypt wont work either 2016-07-05 10:50:46 raid* 2016-07-05 10:50:57 this is an unacceptable limitation, we should work on a kernel patch! 2016-07-05 10:51:06 :) 2016-07-05 10:52:03 also, it does find the things it needs fast 2016-07-05 10:52:09 even on arm devices 2016-07-05 10:53:45 skarnet: but yes I agree. the code is not very simple 2016-07-05 10:53:53 but the problem it solves it not simple either 2016-07-05 10:53:57 I understand 2016-07-05 10:54:14 maybe it would be beneficial to turn it into a real, separate project 2016-07-05 10:54:25 that could even be used outside of Alpine 2016-07-05 10:54:25 possibly 2016-07-05 10:54:31 well 2016-07-05 10:54:33 not right now obviously 2016-07-05 10:54:38 but it's something I'll think about 2016-07-05 10:54:43 it has a few alpine specific bits 2016-07-05 10:55:00 we need find *.apkovl.tar.gz and the apk repository 2016-07-05 10:55:39 if we want make it a general tool we'd need to add that functionality to some kind of plugin 2016-07-05 10:56:13 yeah. More design required. I think it would be a good idea, but I agree it's not a priority :) 2016-07-05 10:56:34 i actually thought to use it as a general hotplug handler 2016-07-05 10:56:37 initially 2016-07-05 10:56:53 but I'm no longer convinced thats a good idea anymore 2016-07-05 10:57:37 you don't need something that complex as a hotplug handler: once your system is started you can have a netlink listener that will get hotplug events sequentially 2016-07-05 10:58:58 thats what i mean with hotplug handler 2016-07-05 11:01:55 i am actually relatively happy with nlplug-findfs 2016-07-05 11:02:19 it makes it possible to use same syslinux.cfg for cdrom as for disk images 2016-07-05 11:02:32 as long as it works and does what you want it to do, knock yourself out :) 2016-07-05 11:02:50 ACTION knocked himself out 2016-07-05 11:03:16 i'm still interested in some udev replacement and openrc replacement 2016-07-05 11:03:51 they'll come, they'll come 2016-07-05 11:04:15 as soon as I have enough $$$ to work on that fulltime :P 2016-07-05 11:07:12 <^7heo> contributing with IRC is painful AF 2016-07-05 11:07:20 <^7heo> I have to hunt for links with /lastlog 2016-07-05 11:07:26 <^7heo> and I have to read the whole log 2016-07-05 11:12:46 <^7heo> okay so 2016-07-05 11:12:56 <^7heo> I spent several minutes checking that I wasn't missing anything from the log. 2016-07-05 11:13:00 <^7heo> I hope I didn't. 2016-07-05 11:14:35 <^7heo> ncopa: with your two last patches, it gets more complicated tho. 2016-07-05 11:15:37 Hm, http://lists.alpinelinux.org/alpine-aports/201607bydate.html 404s 2016-07-05 11:16:06 byindex works fine though. 2016-07-05 11:16:45 ncopa: why openrc replacement ? 2016-07-05 11:17:35 ^7heo: the 4 patches in serie: http://tpaste.us/GdyW 2016-07-05 11:18:13 coredumb: openrc is okish, but not optimal 2016-07-05 11:18:27 <^7heo> ncopa: thanks 2016-07-05 11:18:44 ^7heo: what is missing is the size_t atoi thingy 2016-07-05 11:18:52 <^7heo> yeah that's fine it's in my code now 2016-07-05 11:18:55 and add the initramfs-init patch as separate commit 2016-07-05 11:19:00 <^7heo> that too 2016-07-05 11:19:17 <^7heo> I have 3 commits in my git 2016-07-05 11:19:22 <^7heo> one for the main thing 2016-07-05 11:19:23 then i only need to test it 2016-07-05 11:19:25 Anyways, I've sent new aports (main{lzlib,plzip}) to the ML on Jun 25th but haven't seen any reaction to it yet. Do I just have to wait? 2016-07-05 11:19:29 <^7heo> one for the initramfs 2016-07-05 11:19:42 <^7heo> one for the refactoring with the for (or the function if we go for that) 2016-07-05 11:19:45 kl3: sorry. just busy. 2016-07-05 11:19:48 will look at it now 2016-07-05 11:20:10 kl3: i know why i didnt react on it 2016-07-05 11:20:19 <^7heo> I just had to look for the log a lot because there were things said that weren't into patches. 2016-07-05 11:20:24 <^7heo> such as the memset thingy. 2016-07-05 11:20:27 ncopa: Ok, any ressource listing what you whish would be better 2016-07-05 11:20:29 ncopa: What is it? 2016-07-05 11:20:33 for my curiosity :) 2016-07-05 11:20:35 kl3: they need to be added to testing/* instead of main/* 2016-07-05 11:20:44 Ah, well :) 2016-07-05 11:21:04 i'll answer your emails 2016-07-05 11:21:09 there are more nitpicks 2016-07-05 11:21:18 ncopa: Thanks 2016-07-05 11:25:39 sent 2016-07-05 11:25:42 sorry for the delay 2016-07-05 11:26:00 <^7heo> ncopa: given that you probably have a daily job as well; I totally understand the delays personally. 2016-07-05 11:34:44 ncopa: Do you want me to merge the update of lzip into the new lzlib aport commit? If so, why? 2016-07-05 11:38:49 yes 2016-07-05 11:39:16 i dont see why i should add 3 patches when only 2 is necessary 2016-07-05 11:39:33 the third patch does not add any value which could not be solved in the first 2016-07-05 11:39:42 i mean, there is no value in splitting it 2016-07-05 11:40:23 just adds more work for me who will have to review and apply 3 patches instead of 2 2016-07-05 11:40:43 for a single contributor that is ofc no problem 2016-07-05 11:40:49 but if you deal with 100 2016-07-05 11:40:55 the difference is 100 patches 2016-07-05 11:41:00 for me 2016-07-05 11:41:55 <^7heo> ncopa: that's thing with github, you can git checkout && git push 2016-07-05 11:42:04 <^7heo> no matter the amount of patches or anything :) 2016-07-05 11:42:06 <^7heo> ACTION hides 2016-07-05 11:43:22 still needs review 2016-07-05 11:43:39 sure it does not matter that much 2016-07-05 11:43:52 but those trivial things makes the difference from apply now and move on 2016-07-05 11:44:07 or if it ends up in the que for 3 weeks 2016-07-05 11:44:28 <^7heo> ncopa: the review in github is pretty nice too :P 2016-07-05 11:44:31 <^7heo> but okay I stop :D 2016-07-05 11:44:48 My point is that lzlib is needed for plzip, but not for lzlip. 2016-07-05 11:45:15 oh!!!! 2016-07-05 11:45:17 my bad 2016-07-05 11:45:20 totally sorry 2016-07-05 11:45:27 Don't worry ;) 2016-07-05 11:45:45 s/lzlip/lzip/ 2016-07-05 11:45:56 yeah exactly.. 2016-07-05 11:45:57 I'm starting to confuse them as well :D 2016-07-05 11:46:17 lzlib != lzip 2016-07-05 11:46:22 ^ 2016-07-05 11:48:10 ncopa: Do you want me to send new patches that add those packages to testing instead of main? 2016-07-05 11:48:23 i'll apply the 3/3 patch 2016-07-05 11:49:40 Btw, I added lzlib and plzip to main simply because lzip is already in main. 2016-07-05 11:49:53 understand 2016-07-05 11:50:04 but i want them to testing first 2016-07-05 11:50:07 ScrumpyJack, why changing the 'mv' to 'cp -a' in http://patchwork.alpinelinux.org/patch/2134/ ? 2016-07-05 11:50:27 fabled: i suspect the target dir exists 2016-07-05 11:50:31 or similar 2016-07-05 11:50:33 the first hunk looks appropriate 2016-07-05 11:50:59 ncopa, the dir is just created one line before, so it's guaranteed to be there 2016-07-05 11:51:06 ncopa: Sure 2016-07-05 11:51:11 i think it was 1st suspect for not copying subdirs 2016-07-05 11:51:21 but 'mv' moves the subdirs too 2016-07-05 11:51:29 fabled: only if -p is removed that is guaranteed 2016-07-05 11:51:39 ncopa, read the code 2016-07-05 11:51:47 it's "mv $foo/* $target" 2016-07-05 11:51:53 mkdir "$DBDIR" || return 1 2016-07-05 11:52:01 will guarantee 2016-07-05 11:52:01 and just before that there's mkdir -p $target 2016-07-05 11:52:11 ? 2016-07-05 11:52:34 ncopa, it's $DESTDIR which is generated 2016-07-05 11:52:38 it's guranteed to be empty 2016-07-05 11:52:49 when i only look at the hunk 2016-07-05 11:52:56 yes. you don't get the context there 2016-07-05 11:53:00 correct 2016-07-05 11:53:12 depends on context 2016-07-05 11:53:32 ScrumpyJack, i'm ok with the first hunk, not with the second 2016-07-05 11:53:38 the first hunk should fix any issues 2016-07-05 11:54:10 and i agree with fabled, mv is better 2016-07-05 11:54:48 fabled: back. just looking 2016-07-05 11:55:20 i can cherry-pick the first hunk 2016-07-05 11:55:50 mv $DTB_STAGING/* "$DTBDIR" doesn't work 2016-07-05 11:56:22 ScrumpyJack, what error you get? 2016-07-05 11:56:25 or what breaks? 2016-07-05 11:57:25 i can't remember :) 2016-07-05 11:57:34 let me think 2016-07-05 11:59:44 ncopa, i think i finally have gcc6.1 set. i wonder if i should test compile a kernel first or something similar 2016-07-05 11:59:51 but it's able to re-compile itself 2016-07-05 12:01:00 ok 2016-07-05 12:01:16 i can build it here, and build kernel and test boot it 2016-07-05 12:01:30 java works finally now too 2016-07-05 12:01:38 nice! 2016-07-05 12:01:44 it had upstream bug (fixed in branch, but needed to cherry-pick it) 2016-07-05 12:01:52 were you able to reduce numbers of patches? 2016-07-05 12:01:56 custom patches 2016-07-05 12:02:13 47 files changed, 1347 insertions(+), 1892 deletions(-) 2016-07-05 12:02:25 \o/ 2016-07-05 12:02:53 very good 2016-07-05 12:03:04 it was 46 .patch files, now it is 34 2016-07-05 12:03:35 its going in the right direction 2016-07-05 12:03:36 and they are mostly less intrusive 2016-07-05 12:04:09 the commit is http://sprunge.us/QgSH 2016-07-05 12:04:28 thanks 2016-07-05 12:04:30 building now 2016-07-05 12:04:43 i will try build and boot vanilla kernel 2016-07-05 12:08:34 fabled: I can't rememeber why the mv failed. i'll have to check later when i get home and use an RPi 2016-07-05 12:09:45 (trying on another arch for now) 2016-07-05 12:20:56 ncopa, i think the as-needed patch is broken 2016-07-05 12:21:14 or hum 2016-07-05 12:22:51 ncopa: Do you still want lzlib removed as a dependency from the plzip aport? I'll then send new commits that add those two packages to testing. 2016-07-05 12:23:58 kl3: yes remove it unless there there are some /usr/bin/* files needed 2016-07-05 12:24:35 ncopa: Ok, will do. 2016-07-05 12:24:45 fabled: kernel compile failed with: http://tpaste.us/24gr 2016-07-05 12:24:56 i suppose we have to add -fno-PIE 2016-07-05 12:25:15 or -fno-PIC 2016-07-05 12:25:31 yes 2016-07-05 12:25:45 What's the point in explicitly removing dependencies? I get that it's automatically detected, but still. 2016-07-05 12:25:47 i wonder if it can be added to specs 2016-07-05 12:26:12 kl3: well, that's the main reason 2016-07-05 12:26:20 kl3: then abuild can figure out way better deps 2016-07-05 12:26:30 kl3: not package level, but by provided soname 2016-07-05 12:26:56 barthalion: Fair point. 2016-07-05 12:27:00 kl3: that means that apk will find the correct package even if it is renamed 2016-07-05 12:27:21 without needing rebuild 2016-07-05 12:27:30 ncopa: Yeah, I see now. 2016-07-05 12:28:50 fabled: i can't reproduce the problem that mv might have caused 2016-07-05 12:29:03 :) 2016-07-05 12:29:37 pebkac 2016-07-05 12:29:41 ncopa, ok figured out the problem i had. as-needed should work. my cross build was broke.. 2016-07-05 12:30:31 fabled: so by all means, cherry pick only first hunk 2016-07-05 12:31:02 can't remember for the life of me what the problem was. it should seem obvious 2016-07-05 12:32:30 fabled: do you have any idea how i pass the -fno-PIC flag? 2016-07-05 12:37:08 ncopa: Patches are out, thanks. 2016-07-05 13:29:30 fcolista: hi dude. you about? 2016-07-05 13:54:31 I'm trying to now revive my cross build scripts. 2016-07-05 13:54:37 at least creating cross compiler works 2016-07-05 13:54:45 though, i have pending patches to push 2016-07-05 14:16:33 ok, cross building up until openssl works now 2016-07-05 14:16:38 seems cross building openssl has some issues 2016-07-05 14:51:04 <^7heo> try to expain C to a C++ developer: http://stackoverflow.com/questions/10510077/size-t-convert-cast-to-string-in-c?noredirect=1#comment63836845_10510077 2016-07-05 15:00:25 is somebody here who wants to add http://sprunge.us/gJMB? 2016-07-05 15:00:30 maybe ncopa? 2016-07-05 15:01:59 <^7heo> mosez: why don't you submit it via gh? 2016-07-05 15:03:47 ^7heo: because that's not the workflow. it's submitted via email and ncopa also added already some packages through a sprunge paste. 2016-07-05 15:04:08 <^7heo> mosez: https://github.com/alpinelinux/aports 2016-07-05 15:04:18 Readonly mirror of aports ;) 2016-07-05 15:04:23 ^7heo: posting patches here is completely fine way to contribute 2016-07-05 15:04:25 <^7heo> https://github.com/alpinelinux/aports/pulls 2016-07-05 15:04:29 http://git.alpinelinux.org/cgit/aports/tree/testing 2016-07-05 15:04:32 no reason to tell people where should they contribute 2016-07-05 15:04:40 <^7heo> mosez: it's not, poeple contribute there. 2016-07-05 15:05:15 ^7heo: the title of the repo say readonly mirror. and the docs also say just git send-email to the patchwork mailing list. 2016-07-05 15:05:24 <^7heo> barthalion: and if people send YOU links you have to commit yourself, I won't say anything. 2016-07-05 15:05:50 https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package#Commit_your_work 2016-07-05 15:05:53 <^7heo> but maybe ncopa has enough work as it is not to have to do more work. 2016-07-05 15:06:06 <^7heo> anyway 2016-07-05 15:06:06 ncopa isn't the only developer sitting here 2016-07-05 15:06:40 ^7heo: i do it like for other packages before. via patchwork email or via sprunge on irc until somebody tells me this is wrong please do it differently. 2016-07-05 15:06:42 <^7heo> mosez: and the README.md file I am trying to get there describes how to contribute. 2016-07-05 15:06:58 we dont apply PR's on top of github, we apply them to git.a.o and it auto closes them on github. 2016-07-05 15:07:00 mosez: there is default prepare() now, you don't hae to specify it explicitly 2016-07-05 15:07:01 <^7heo> mosez: I just think that it's easier to have a gh remote in git 2016-07-05 15:07:03 <^7heo> and be like 2016-07-05 15:07:10 <^7heo> git pull gh whatever 2016-07-05 15:07:12 <^7heo> git push 2016-07-05 15:07:24 <^7heo> clandmeter: I've seen the bot do that, yes. 2016-07-05 15:07:39 barthalion: uhm... ok. i just did it the same way as for my last golang package 2016-07-05 15:08:03 <^7heo> mosez: I mean, it's totally okay for the content to post patches on IRC. 2016-07-05 15:08:08 <^7heo> but I don't do it for aports. 2016-07-05 15:08:08 ^7heo: stop pushing for gh use when someone's happy not to use it, dammit. :P 2016-07-05 15:08:11 mosez: also there is 'ls' in package(), I personally dislike "for \n do" 2016-07-05 15:08:21 mosez: and I guess all go commands should have || return 1 2016-07-05 15:08:23 <^7heo> skarnet: well, let's use gogs then. 2016-07-05 15:08:32 damn, the ls is wrong :D 2016-07-05 15:08:49 <^7heo> skarnet: and I agree, using gh for everything is a bad idea. 2016-07-05 15:08:54 <^7heo> but gogs is really cool 2016-07-05 15:09:09 mosez: also some line breaking in _providers would be appreciated 2016-07-05 15:09:27 but in general, LGTM 2016-07-05 15:09:28 wth do you want to push to any webui? alpine uses patchwork which in turn just uses a plain mailinglist. 2016-07-05 15:09:28 <^7heo> the main reason I'm reacting to it is that IMHO, github requires less workflow than ML or IRC submitted patches. 2016-07-05 15:09:50 <^7heo> mosez: the point isn't the webui. The point is to be able to PR. 2016-07-05 15:09:53 barthalion: should i also send a patch for my other packages that drops the prepare? 2016-07-05 15:09:56 the main reason we don't care is, we don't care 2016-07-05 15:10:06 mosez: yes, that would make sense 2016-07-05 15:10:12 ^7heo: you know http://patchwork.alpinelinux.org/project/aports/list/? 2016-07-05 15:10:18 we accept patches here, or via ML, or via github 2016-07-05 15:10:20 period 2016-07-05 15:10:29 end of discussion 2016-07-05 15:10:32 kthxbye 2016-07-05 15:10:32 :) 2016-07-05 15:10:39 <^7heo> mosez: I didn't. 2016-07-05 15:10:53 <^7heo> That's the kind of workflow that is unnecessary with the existing tools; such as gogs. 2016-07-05 15:10:54 ^7heo: this is the frontend for the mailing list. 2016-07-05 15:10:59 so stop generating backlog, #alpine-offtopic welcomes things unrelated to actual development 2016-07-05 15:11:00 <^7heo> mosez: does that grab patches from IRC automatically? 2016-07-05 15:11:11 EOD :) 2016-07-05 15:11:14 <^7heo> yeah. 2016-07-05 15:11:20 <^7heo> Enough waste. 2016-07-05 15:11:41 <^7heo> I don't wanna spend time trying to convince people that re-implementing what works well is a bad idea. 2016-07-05 15:11:58 I just joined #alpine-offtopic, believing it existed 2016-07-05 15:12:04 I'm feeling very lonely there 2016-07-05 15:12:06 skarnet: sorry to disappoint you 2016-07-05 15:12:07 <^7heo> Afterall, there almost nothing broken, so it's not like we should that time fixing anything, right? 2016-07-05 15:12:22 barthalion: http://git.alpinelinux.org/cgit/aports/tree/testing/cloudfoundry-cli/APKBUILD drop prepare, and something else? 2016-07-05 15:12:37 go install ${_gourl}/main || return 1 2016-07-05 15:12:46 also s/_builddir/builddir/ 2016-07-05 15:13:10 ^7heo: as a last statement. the ml works totally fine, what do you think are the kernel developers doing? accept patches from a ml. 2016-07-05 15:13:40 _builddir="${srcdir}/cli-${pkgver}" :) 2016-07-05 15:14:03 I meant the underscore 2016-07-05 15:14:08 should i also rename the godir things? 2016-07-05 15:14:21 no, only builddir 2016-07-05 15:14:23 <^7heo> mosez: yeah sure. and they sprunge all on IRC also, right? 2016-07-05 15:14:54 it's clandmeters fault... most stuff have been copied from http://git.alpinelinux.org/cgit/aports/tree/community/godep/APKBUILD :D 2016-07-05 15:15:31 ^7heo: no, but that's up to the project maintainer, isn't it? 2016-07-05 15:18:19 <^7heo> mosez: I would say that it's up to the person who's gonna have to do the work from IRC to git. 2016-07-05 15:18:23 <^7heo> whoever that is. 2016-07-05 15:18:50 <^7heo> and if ncopa is fine with doing the extra work, I suppose it's okay. 2016-07-05 15:19:11 barthalion: http://sprunge.us/ZBhj 2016-07-05 15:19:14 <^7heo> now, if it's me who has to do that; I'll do it once or twice, but I won't do it again and again. 2016-07-05 15:19:28 <^7heo> not without helpers such an IRC bot or something. 2016-07-05 15:19:37 barthalion: will try to build it again 2016-07-05 15:19:49 I bet algitbot could help 2016-07-05 15:20:02 yeah, accepting patches via IRC is really wonderful… it’s the best automation of work ever, don’t you see how these patches are automatically tested and merged? :P 2016-07-05 15:20:43 as long as a maintainer is fine with that, why not? 2016-07-05 15:23:34 ^7heo: friendly advice, don’t waste your time by trying to convince them, it doesn’t work, I’ve already tried it; be glad that GH is actually one of the supported options, let others use whatever they want 2016-07-05 15:23:41 <^7heo> jirutka: thanks. 2016-07-05 15:23:47 <^7heo> I won't. 2016-07-05 15:23:55 <^7heo> skarnet: algitbot could definitely help. 2016-07-05 15:24:21 ^7heo: btw algitbot is also on GitHub :P https://github.com/algitbot 2016-07-05 15:24:24 <^7heo> mosez: well, aside from the fact that it's more workflow to the maintainer, it's also a lot more noise. 2016-07-05 15:24:30 <^7heo> jirutka: thanks :) 2016-07-05 15:24:54 <^7heo> mosez: c.f. the chat yesterday evening and this morning between ncopa and me about patching stuff that isn't on gh. 2016-07-05 15:25:12 <^7heo> the truth is, github comments are much more readable than IRC. 2016-07-05 15:25:17 <^7heo> mails also are. 2016-07-05 15:25:29 <^7heo> but I don't want to be part of a ML just for submitting patches once every 6 months. 2016-07-05 15:25:46 <^7heo> so for me, gh is the best option. 2016-07-05 15:25:50 <^7heo> but again 2016-07-05 15:25:52 <^7heo> EOD> 2016-07-05 15:25:54 <^7heo> as you said. 2016-07-05 15:26:08 so if that works for you it's totally fine. and i'm fine to use the ml or even irc. 2016-07-05 15:26:42 ^7heo: and some ppl already envies that patches on GH are automatically tested, but patches from ML are not :) so I’m gonna do some simple integration of patchwork and GH, just to create PRs for patches to be tested on CI for now 2016-07-05 15:27:01 <^7heo> jirutka: yeah, it would be possible to host a gogs and get rid of gh 2016-07-05 15:27:07 <^7heo> and automatically test the same way 2016-07-05 15:27:14 <^7heo> if there's any issue with github. 2016-07-05 15:27:35 <^7heo> I'm not a fan of gh, but I really dislike doing more work than necessary. 2016-07-05 15:27:40 is gogs *entirely* open source? I can't figure it out from its pages 2016-07-05 15:27:48 ^7heo: I see it from the other side now in my new job… I have when they trying to convince me to use their preferred tools… so I don’t want to do the same thing to Alpine guys 2016-07-05 15:28:06 <^7heo> skarnet: it is. 2016-07-05 15:28:18 <^7heo> skarnet: written in go by a chinese dude. 2016-07-05 15:28:24 ^7heo: it’s okay to provide and support alternative ways, not to force anyone to anything 2016-07-05 15:28:30 i think you can forget gogs for aports. even the kernel is so daaaaaaaaaamn slow within it. 2016-07-05 15:28:42 ^7heo: that’s exactly what I really don’t like about gogs… 2016-07-05 15:28:47 a chinese dude studying in the us. 2016-07-05 15:28:54 i'm also a contributor for gogs... 2016-07-05 15:29:05 <^7heo> jirutka: as long as it's not asking me to write a complex irssi plugin in perl in order to be able to read this channel, I'm fine too. 2016-07-05 15:29:20 <^7heo> jirutka: are you being racist or just anti go? 2016-07-05 15:30:01 lol 2016-07-05 15:30:12 <^7heo> (I'm not trying to troll, but I hope you really don't like go) 2016-07-05 15:30:51 <^7heo> but hey look everybody 2016-07-05 15:30:56 <^7heo> there's #alpine-offtopic nwo. 2016-07-05 15:30:57 <^7heo> now* 2016-07-05 15:31:02 ^7heo: what? I don’t care if the author or Chinese or whatever, I just don’t like Go 2016-07-05 15:31:03 <^7heo> aka #alpine-troll 2016-07-05 15:31:07 jirutka: than take gitbucket, it's from a chinese guy written in scala >P 2016-07-05 15:31:09 <^7heo> jirutka: good answer ;) 2016-07-05 15:31:24 oh no, please no GitBucket 2016-07-05 15:31:25 <^7heo> scala v_v 2016-07-05 15:31:41 I can’t even see the Atlassian logo… 2016-07-05 15:31:52 GitBucket, not BitBucket... 2016-07-05 15:31:56 aha, pardon 2016-07-05 15:32:02 https://github.com/gitbucket/gitbucket 2016-07-05 15:32:12 https://gitbucket.github.io/gitbucket-news/ 2016-07-05 15:32:24 interesting, didn’t know about it 2016-07-05 15:32:50 they had been a copy of github but in oss. now they have been forced to change the ui :) 2016-07-05 15:32:53 https://gitbucket.github.io/gitbucket-news/gitbucket/2016/03/20/change-user-interface.html 2016-07-05 15:33:04 <^7heo> yea I also read bitbucket the first time but then I was like "What? Atlassian is an Aussie company..." 2016-07-05 15:33:05 Scala is still better than GoShit 2016-07-05 15:33:06 guys, come to #alpine-offtopic, we have cookies 2016-07-05 15:33:15 <^7heo> yeah 2016-07-05 15:33:16 but be warned, the only use the java embedded database... hbase? or how was it named? 2016-07-05 15:33:32 nope, I need to prepare some presentations 2016-07-05 15:33:34 leave the chan to actual alpine work 2016-07-05 15:33:41 wee 2016-07-05 15:34:09 yeah, just stopping to spam. 2016-07-05 15:34:19 <^7heo> yeah, so, if you wanna troll about ML or IRC or GH or else, -> /join #alpine-offtopic 2016-07-05 15:35:02 meh, #alpine-offtopic is totally offtopic :P 2016-07-05 15:40:31 ^7heo: last OT… it’s still better sending patches via IRC than Slack channel with disabled XMPP/IRC gateway… :P okay, back to work 2016-07-05 15:45:36 barthalion: http://sprunge.us/FDiY should be fine? 2016-07-05 15:45:52 http://sprunge.us/ZBhj is still building on my arm machine... 2016-07-05 15:51:49 <^7heo> jirutka: we could also be contributing to node-os instead... 2016-07-05 15:51:49 yay... patchwork 2180 2181 2168 and 2169 :) 2016-07-05 15:52:04 <^7heo> but we're not looking for the worse things to do, are we? 2016-07-05 15:52:32 ^7heo: OS built on top of Node.js? I hope that you’re just kidding… 2016-07-05 15:53:30 unfortunately it exists, but the place to talk about it is #alpine-offtopic 2016-07-05 15:57:12 <^7heo> jirutka: it exists. 2016-07-05 15:57:20 <^7heo> and what skarnet said 2016-07-05 16:04:01 fabled: any idea why the rpi overlays don't load? #5773 2016-07-05 16:14:49 ScrumpyJack, i wonder ifsomething changed in the bootloader 2016-07-05 16:18:50 your guess is better than mine :) 2016-07-05 16:47:51 hey guys 2016-07-05 16:48:07 to submit a new aport, should i file a bug first or it doesn't matter? 2016-07-05 17:16:48 dfs: you can git send-email to alpine-aports or if you have a long list with patches github is also ok 2016-07-05 17:17:03 mosez: sorry i think i pushed wrong patch 2016-07-05 17:18:16 ncopa: deal 2016-07-05 17:19:00 the main problem is that the number of incoming patches are bigger than we manage to review and apply 2016-07-05 17:19:01 or reject 2016-07-05 17:19:28 specially things that needs feedback tend to be left for another time 2016-07-05 17:20:23 has there been any progress on getting ghc into testing since mitchty's aport in january? 2016-07-05 17:21:03 jzono1: i'm actually working on that a bit now again, current status is i've got a port of llvm 3.7 that i'm updating my port to use 2016-07-05 17:21:03 (I just tried to build it with that aport, and there's breakage both in the docker bootstrap, and in the aport itself when using his precompiled bootstrap ghc) 2016-07-05 17:21:14 cool mitchty 2016-07-05 17:21:16 i'm building things on arm atm 2016-07-05 17:21:26 just to be sure that everything still works 2016-07-05 17:21:36 the wip branch should have what it will become 2016-07-05 17:22:04 unless i forgot to push something 2016-07-05 17:22:25 but i've got 16 hours to go on the arm build 2016-07-05 17:23:38 jzono1: its mostly my fault tbh, but summertime is for running not as much for computer stuff after work :) 2016-07-05 17:26:54 jzono1: ok https://github.com/mitchty/alpine-linux-ghc-bootstrap/tree/wip should have what i'm testing, that version should bootstrap as of sunday iirc 2016-07-05 17:31:09 why the sha changed on the debian package at haskell.org that the bootstrap uses is a good question but the contents were the same 2016-07-05 17:52:06 ncopa: which one? i have submitted all to patchwork 2016-07-05 17:52:34 mosez: the one i found here on irc 2016-07-05 17:53:18 ncopa: yep, it's the one including prepare and so on. should i submit a new one that updates it? 2016-07-05 17:53:38 http://patchwork.alpinelinux.org/patch/2180/ can be skipped 2016-07-05 17:54:03 i will create a diff 2016-07-05 17:54:24 thanks! 2016-07-05 17:56:26 ok 2016-07-05 17:56:29 here comes gcc6! 2016-07-05 17:56:45 building kernels and kernel modules will be broken atm 2016-07-05 17:57:06 kernels needs to be built with make KCFLAGS="-fno-pie" 2016-07-05 17:57:35 3rdparty modules will likely need MODULE_CLFAGS="-fno-pie" 2016-07-05 17:59:24 overquota for sprunge -.- 2016-07-05 18:00:18 ncopa: should i submit it to the ml? 2016-07-05 18:01:19 mosez: yes please 2016-07-05 18:01:47 gotta go 2016-07-05 18:01:51 have a nice evening 2016-07-05 18:02:48 http://patchwork.alpinelinux.org/patch/2182/ 2016-07-05 18:02:51 you too 2016-07-05 18:06:23 ncopa: i think http://patchwork.alpinelinux.org/patch/2137/ can get canceled... i have not seen that before but now we already got a terraform package. 2016-07-05 18:25:19 mosez: tpaste.us 2016-07-05 19:40:21 https://bugs.alpinelinux.org/issues/5869 <- aport fixed, I could abuild my own updated wget apk, but I when is expected the official alpine version from the official repositories? 2016-07-05 19:41:48 btw, nice doc, rebuilding wget was easy enough :) 2016-07-05 19:42:59 tru_tru: it's already included in edge, the rolling release 2016-07-05 19:43:22 my guess is ncopa will backport the fix to stable branches soon 2016-07-05 19:45:59 ok, I will have a look at running edge 2016-07-05 20:11:31 tru_tru: backported to 3.4 2016-07-05 20:15:26 and 3.3 2016-07-05 20:15:47 will take a look at 3.2 and 3.1 tomorrow 2016-07-05 20:19:50 barthalion: thx :D 2016-07-05 20:20:14 https://gist.github.com/truatpasteurdotfr/e149b23626e07970ee61cbce2fcae73f#gistcomment-1819089 trying to build my first aport package 2016-07-05 20:21:04 I don't understand why the cd "builddir" works fine for the build() not for the intall() part 2016-07-05 20:24:38 ACTION back later, will read scrollback if any 2016-07-05 20:31:33 tru_tru: maybe i can help if you show me the error 2016-07-05 20:34:02 tru_tru: your builddir is nor relative to $srcdir 2016-07-05 20:34:08 s/nor/not 2016-07-05 20:34:52 https://dpaste.de/bGWH/raw <- full abuild output 2016-07-05 20:36:11 tru_tru: do you have 'cd "$_builddir"' before the 'make install'? 2016-07-05 20:36:22 builddir shoul be an absolute path? or relative to where the APKBUILD src are ? 2016-07-05 20:36:47 dfs: yes 2016-07-05 20:37:06 https://gist.github.com/truatpasteurdotfr/e149b23626e07970ee61cbce2fcae73f#gistcomment-1819089 package() has it 2016-07-05 20:37:08 barthalion: yeah i have submitted it via email 2016-07-05 20:37:53 I really have to leave now, sorry back in a few hours 2016-07-05 20:37:56 tru_tru: try "$_builddir" instead of "$builddir" 2016-07-05 20:38:31 like cd "$_builddir" && make ... ? 2016-07-05 20:38:32 tru_tru: your $builddir is relative to pwd which is not defined for prepare() or install(), you should make it absolute, e.g. $srcdir/singularity-master 2016-07-05 20:39:34 https://dpaste.de/vy5M/raw 2016-07-05 20:41:14 dfs: _builddir is just a name, it does not hold special meaning (or is defined by default) in abuild afaik 2016-07-05 20:41:59 chris|: true 2016-07-05 20:42:06 hmmm 2016-07-05 20:42:51 chris|: that works :) I need to create the sub packages at the next iteration 2016-07-05 20:43:01 yay 2016-07-05 20:43:03 https://dpaste.de/H88X/raw with builddir=$srcdir/singularity-master 2016-07-05 20:43:23 or you can do it and have singularity on alpine :) 2016-07-05 20:43:31 see you later 2016-07-05 20:47:12 and take all the fun away? no thanks :) 2016-07-05 20:48:30 true hehe 2016-07-05 20:49:02 mosez: I will go through patchwork tomorrow morning 2016-07-05 20:53:56 barthalion: cool 2016-07-05 20:54:53 already started to use terraform and cloudfoundry-cli packages at https://github.com/drone-plugins/drone-terraform/pull/23/files and https://github.com/drone-plugins/drone-cloudfoundry/pull/11/files 8) 2016-07-05 21:01:42 <^7heo> ncopa: so, I'm gonna send that final version of the patch tomnght I hope 2016-07-05 21:01:58 <^7heo> ncopa: I guess it's already too late for you if I take more than half an hour right? 2016-07-05 22:28:53 <^7heo> yeah as I said. 2016-07-06 06:56:16 fabled: I don't think it's a bootloader issue, you can't load overlays at runtime either 2016-07-06 07:56:11 every new aport must be a single commit. can I also submit multiple new aports at once? i want to package a python tool that depends on python libs that are not packaged yet. 2016-07-06 07:56:43 we normally want each aport in separate commit 2016-07-06 07:57:13 also single patchwork submits? 2016-07-06 07:57:30 depends on how many patches there are 2016-07-06 07:57:38 if less than 5 patchwork works 2016-07-06 07:57:59 or maybe first another question. do you have any interest in https://github.com/dbcli/mycli and https://github.com/dbcli/pgcli to be packaged? 2016-07-06 07:58:00 if more than 5, then its easier with a public git repo 2016-07-06 07:58:19 sure 2016-07-06 07:58:38 as long as someone maintains it 2016-07-06 07:58:46 pgcli got 5 missing deps, mycli got 4 missing deps. while multiple of them are required for both. 2016-07-06 07:59:27 github pr is ok for this 2016-07-06 07:59:35 that is 1 pr with 5-6 commits 2016-07-06 07:59:45 so i can git pull in one shot 2016-07-06 07:59:51 ok, will do it through gh with single commits for every aport 2016-07-06 07:59:58 perfect 2016-07-06 08:00:13 thats better than 5 individual git am 2016-07-06 08:01:57 i really like the alpine packaging. it's so easy :) 2016-07-06 08:05:53 :) 2016-07-06 08:06:04 that was one of the goals 2016-07-06 08:26:45 ^7heo: you recently send a patch for gogs 2016-07-06 08:29:31 ^7heo: any reason you didnt update the pkg? 2016-07-06 08:55:52 ncopa: PyMySQL should be named py-mysql if i compare it with py-crypto, right? 2016-07-06 08:56:26 gogs package on alpine? that will be a fun to maintain xD 2016-07-06 08:57:36 yeah I looked at the package and ... I just compile it on my desktop and upload the binary on my server 2016-07-06 08:57:41 not worth the hassle 2016-07-06 08:57:46 mosez: yes 2016-07-06 08:58:07 haven't we switched to py2 yet ? 2016-07-06 08:59:34 ncopa: thanks, will rename my package :) 2016-07-06 09:03:16 <^7heo> clandmeter: yeah. 2016-07-06 09:03:27 <^7heo> clandmeter: it was broken, I fixed it. 2016-07-06 09:03:42 are you ok with upgrading it? 2016-07-06 09:03:54 <^7heo> clandmeter: I'm working on it as a second step since a few days 2016-07-06 09:04:13 <^7heo> clandmeter: Having issues with some go include not automatically detected 2016-07-06 09:04:23 i have it in my git local 2016-07-06 09:04:30 <^7heo> working? 2016-07-06 09:04:40 gogs --help works 2016-07-06 09:04:46 is that enough? :) 2016-07-06 09:04:59 <^7heo> I would like to see the APKBUILD you made 2016-07-06 09:05:01 <^7heo> what changes 2016-07-06 09:05:10 <^7heo> becasue that's what blocks me. 2016-07-06 09:05:40 <^7heo> I can give you more details in like 2h 2016-07-06 09:05:43 <^7heo> would that be fine for you? 2016-07-06 09:05:45 <^7heo> I gotta run nwo 2016-07-06 09:05:47 <^7heo> now* 2016-07-06 09:06:37 ^7heo: http://tpaste.us/GxJJ 2016-07-06 09:12:16 rnalrd: can we update py-configobj? the version is damn old and i need a more current version. 2016-07-06 09:12:33 hi, sure 2016-07-06 09:13:49 rnalrd: should it stay like it is with the snapshot stuff? or should i patch it like https://github.com/alpinelinux/aports/blob/master/testing/py-click/APKBUILD excluding the prepare? 2016-07-06 09:14:19 since i don;t have access to the snapshot servers it's a little bit hacky for me :) 2016-07-06 09:14:29 <^7heo> clandmeter: where is abuild deps getting the deps from? 2016-07-06 09:15:15 clandmeter: ah... options="!strip" disables binary stripping, correct? 2016-07-06 09:15:26 mosez, i'm upgrading py-configobj to 5.0.6 release as we speak 2016-07-06 09:15:40 or your need specific git snapshot? 2016-07-06 09:15:58 rnalrd: that's totally fine. thanks! 2016-07-06 09:16:05 k 2016-07-06 09:16:23 <^7heo> clandmeter: nevermind, its' from https://github.com/alpinelinux/aports/blob/master/testing/gogs/APKBUILD#L11 I would guess. 2016-07-06 09:16:32 i need >= 5.0.6 https://github.com/dbcli/mycli/blob/v1.7.1/setup.py#L20 :) 2016-07-06 09:18:06 <^7heo> clandmeter: and yes it would work, but I don't like using go get with a hardcoded list of packages, thats' what I'm having problems with. 2016-07-06 09:18:31 <^7heo> Anyway bbl 2016-07-06 09:18:52 mosez, pushed and avail on master mirror 2016-07-06 09:19:09 rnalrd: awesome! thanks again :) 2016-07-06 09:19:14 yw 2016-07-06 09:20:49 rnalrd: but the snapshot method is broken now, right? as it's moved to github and still referencing hg :) 2016-07-06 09:21:20 actually I forgot removing it 2016-07-06 09:21:53 since we don't plan on building from snapshots usually, and abuild, btw has its own snapshot fuction 2016-07-06 09:22:15 ah :) 2016-07-06 09:22:58 removed 2016-07-06 09:23:06 thumbs up :) 2016-07-06 09:40:03 ^7heo: i have no idea what you mean with "go get with a hardcoded list of packages" 2016-07-06 10:09:04 ncopa: https://github.com/alpinelinux/aports/pull/147 now i've got everything 8) 2016-07-06 10:40:07 mosez: build fails 2016-07-06 10:40:24 checksum error on mycli-1.7.1.tar.gz 2016-07-06 10:44:19 ncopa: https://wiki.alpinelinux.org/wiki/Alpine_Linux:Releases is something off with dates here? 2016-07-06 10:45:14 damn checksum, will update. 2016-07-06 10:48:47 barthalion: whoops 2016-07-06 10:48:55 my bad 2016-07-06 10:50:53 :) 2016-07-06 10:51:17 did we settle on tabs for indentation? 2016-07-06 10:51:25 yes 2016-07-06 10:51:36 for abuilds, yes 2016-07-06 10:51:43 yeah, I mean apkbuilds 2016-07-06 10:52:27 <^7heo> clandmeter: https://github.com/alpinelinux/aports/blob/master/testing/gogs/APKBUILD#L35 2016-07-06 10:53:10 btw, read https://github.com/alpinelinux/aports/pull/147#issuecomment-230739905 (PyPI source URLs) 2016-07-06 10:53:28 I’ll update our existing packages soon 2016-07-06 10:54:27 ACTION really loves when $@#$@& breaks URLs… URL should be persistent! 2016-07-06 10:59:26 <^7heo> rnalrd: what to do with snapshots functions in APKBUILDs then? 2016-07-06 10:59:38 <^7heo> ncopa: did you get my email? 2016-07-06 11:00:17 jirutka: updated https://github.com/alpinelinux/aports/pull/147 just waiting for a green travis :) 2016-07-06 11:01:35 failed -.- 2016-07-06 11:05:58 jirutka: now travis is green :) 2016-07-06 11:06:21 so 6 new deps and 2 really new cli apps :D 2016-07-06 11:10:52 ncopa: maybe you also want to check https://github.com/alpinelinux/aports/pull/147 which includes the packages we talked about this morning 2016-07-06 11:14:24 ScrumpyJack: working on your patches now 2016-07-06 11:14:45 indent is either wrong or my vim went postal, but I'll fix it locally 2016-07-06 11:15:37 enough packaging for today. got to work :D 2016-07-06 11:22:41 ^7heo, i think nobody cared to remove git and svn snapshot functions in APKBUILDs 2016-07-06 11:23:03 after all they don't hurt, they just override default abuild snapshot() 2016-07-06 11:27:53 barthalion: the ones in patchwork? thanks dude 2016-07-06 11:33:40 ^7heo: i commited my part to gogs, but it fails to build now. 2016-07-06 11:35:17 <^7heo> yeah as I expected. 2016-07-06 11:35:21 <^7heo> clandmeter: can I get more time to fix it? 2016-07-06 11:35:41 <^7heo> clandmeter: I'm at work now and I had issues with the go import paths and all. 2016-07-06 11:35:55 <^7heo> I'd like to clean that APKBUILD up if possible, before we can go further with the version. 2016-07-06 11:36:27 <^7heo> rnalrd: would it hurt if I would remove the function from an APKBUILD I'm supposed to maintain (gogs)? 2016-07-06 11:36:42 absolutely no 2016-07-06 11:37:22 make sure you specify the giturl/svnurl and disturl in APKBUILD 2016-07-06 11:37:43 otherwise abuild snapshot won't work 2016-07-06 11:37:54 ^7heo: the issue is new gcc and the sqlite driver 2016-07-06 11:38:32 ^7heo: please dont use abuild snapshot function 2016-07-06 11:42:58 <^7heo> clandmeter: why? 2016-07-06 11:43:13 how will you get additional sources? 2016-07-06 11:44:04 <^7heo> I fail to understand your last question. 2016-07-06 11:44:26 you checkout gogs 2016-07-06 11:44:34 but ti needs aditional sources 2016-07-06 11:44:37 go get... 2016-07-06 11:44:39 <^7heo> you mean, additional packages. 2016-07-06 11:44:41 <^7heo> yeah 2016-07-06 11:44:43 <^7heo> ok. 2016-07-06 11:44:49 <^7heo> well, obviously, the build should do that. 2016-07-06 11:44:54 how can you control its always the same? 2016-07-06 11:45:01 they aremostly checked out from master 2016-07-06 11:45:01 <^7heo> always the same as what? 2016-07-06 11:45:05 <^7heo> depends. 2016-07-06 11:45:09 <^7heo> go get -u will update them 2016-07-06 11:45:17 reproducable. 2016-07-06 11:45:24 <^7heo> without -u, it will stay the way it is on the disk. 2016-07-06 11:45:34 our builder will cleanup our disk 2016-07-06 11:45:34 <^7heo> so, of course; if we ditch the environment after build 2016-07-06 11:45:39 <^7heo> yeah exactly. 2016-07-06 11:45:41 next spin will have different source 2016-07-06 11:45:46 which is not what we want. 2016-07-06 11:45:48 <^7heo> yeah 2016-07-06 11:45:53 <^7heo> then we need to use tags 2016-07-06 11:46:06 <^7heo> but there is no doc for -tags in go get 2016-07-06 11:46:09 for every dep? 2016-07-06 11:46:10 <^7heo> I'm not sure it is supported 2016-07-06 11:46:13 <^7heo> well 2016-07-06 11:46:17 <^7heo> how do you want to do it? 2016-07-06 11:46:21 so thats why we have those snapshots 2016-07-06 11:46:30 it has all the sources 2016-07-06 11:46:36 and all builds will use the same source 2016-07-06 11:46:37 <^7heo> I see 2016-07-06 11:46:42 <^7heo> so essentially 2016-07-06 11:46:45 <^7heo> for ALL go packages 2016-07-06 11:46:50 <^7heo> you're gonna host a copy of all the sources 2016-07-06 11:46:52 <^7heo> in one version 2016-07-06 11:47:02 unless there is an alternative way 2016-07-06 11:47:03 <^7heo> just to avoid getting the right version from the RCS? 2016-07-06 11:47:09 go sucks 2016-07-06 11:47:10 <^7heo> well, storing what version you need. 2016-07-06 11:47:13 <^7heo> I like go. 2016-07-06 11:47:16 <^7heo> I'll think about this. 2016-07-06 11:47:34 <^7heo> I can't do much right now, because I'm not supposed to spend too much time on this 2016-07-06 11:47:37 <^7heo> but it's a valid point. 2016-07-06 11:47:47 <^7heo> I'll research how to do that. 2016-07-06 11:47:54 go is nice as a language 2016-07-06 11:47:58 <^7heo> yeah 2016-07-06 11:47:59 but it sucks for packagers 2016-07-06 11:48:02 <^7heo> nah but I gotcha 2016-07-06 11:48:06 <^7heo> the toolchain is made for dev 2016-07-06 11:48:09 <^7heo> not for distributing. 2016-07-06 11:48:23 <^7heo> but I'm sure there are options one can use. 2016-07-06 11:48:30 <^7heo> anyway, I'll see that tonight ;) 2016-07-06 11:48:42 but still 2016-07-06 11:48:46 <^7heo> ncopa: did you get my patches via email? 2016-07-06 11:48:46 we need a fix for sqlite 2016-07-06 11:48:54 <^7heo> true. 2016-07-06 11:48:59 <^7heo> but that's another problem :P 2016-07-06 11:49:05 <^7heo> in any case 2016-07-06 11:49:14 or build without ti. 2016-07-06 11:49:20 <^7heo> I would like to confirm that one can install latest alpine 2016-07-06 11:49:30 ^7heo: yes i got it 2016-07-06 11:49:31 <^7heo> and apk add gogs@testing 2016-07-06 11:49:37 <^7heo> and get gogs working 2016-07-06 11:49:44 <^7heo> I'll test that on a VM tonight. 2016-07-06 11:49:47 <^7heo> ncopa: nice. 2016-07-06 11:50:31 <^7heo> I'd like to add functionality tests for packages 2016-07-06 11:50:40 <^7heo> like, it's good that we test the build 2016-07-06 11:50:41 ^7heo: currently it doesnt build, so apk add gogs@testing will not work 2016-07-06 11:50:52 <^7heo> clandmeter: can you revert? 2016-07-06 11:50:57 no 2016-07-06 11:51:00 <^7heo> ?! 2016-07-06 11:51:01 its not my change 2016-07-06 11:51:03 its gcc 2016-07-06 11:51:08 <^7heo> wait wat? 2016-07-06 11:51:09 we just upgraded to 6.1 2016-07-06 11:51:16 <^7heo> I see. 2016-07-06 11:51:22 <^7heo> So 2016-07-06 11:51:28 <^7heo> I gotta find a mirror out of sync 2016-07-06 11:51:37 <^7heo> and use that. 2016-07-06 11:52:27 i guess our leaseweb has it 2016-07-06 11:52:35 it syncs slowly 2016-07-06 11:52:58 lets see if we can fix it. 2016-07-06 11:57:45 why is alpine's go 110mb? 2016-07-06 12:00:58 <^7heo> clandmeter: btw, isn't the repo keeping the previous packages in case they fail to build? 2016-07-06 12:02:18 i dont think so 2016-07-06 12:02:20 not sure. 2016-07-06 12:03:00 <^7heo> We should definitely not get rid of packages that cannot be replaced with a building version. 2016-07-06 12:03:03 <^7heo> also 2016-07-06 12:03:15 <^7heo> I wanted to know if we could keep some older versions for some time. 2016-07-06 12:03:23 <^7heo> esp. for testing. 2016-07-06 12:03:31 <^7heo> s/testing/edge/ 2016-07-06 12:04:09 <^7heo> I had the problem the other day that I was running a python processus in which I forgot to implement debug output 2016-07-06 12:04:18 <^7heo> and I tried to hook gdb python to it 2016-07-06 12:04:37 <^7heo> but the version of musl-dbg I could find wasn't matching the version on my system 2016-07-06 12:04:46 <^7heo> and that sucked. 2016-07-06 12:05:00 <^7heo> in the end, I found an out of sync mirror that I was able to use for that 2016-07-06 12:05:24 <^7heo> and then I hit the problem that PaX prevents effective debugging by default 2016-07-06 12:05:31 <^7heo> but that's unrelated. 2016-07-06 13:21:45 that's it for today, I'll continue with patchwork tomorrow 2016-07-06 13:22:37 58 left 2016-07-06 13:26:16 thanks 2016-07-06 13:26:36 i'm trying to get my cross build / bootstrap scripts working again 2016-07-06 13:26:42 i'm almost there 2016-07-06 14:25:52 okay 2016-07-06 14:26:06 managed to bootstrap armv7 now 2016-07-06 14:31:25 clandmeter: the size of the go package could be reduced by removing the source files from it. Last time I checked the go compiler needed the source files in certain edge cases not sure if this is still the case 2016-07-06 16:43:17 could please someone revert gogs? it’s failing and it seems that it blocks build servers… 2016-07-06 17:20:40 jirutka: IIRC builders are in non-blocking mode 2016-07-06 17:21:38 barthalion: then why the latest packages haven’t be built? 2016-07-06 17:22:37 can you prove that somehow? because I see new packages built perfectly fine 2016-07-06 17:22:59 at least for x86 and amd64 2016-07-06 17:42:07 barthalion: see #alpine-commits 2016-07-06 18:08:27 jirutka: that's not a proof 2016-07-06 18:09:16 barthalion: what do you want? new aports have been pushed, but not deployed to be built… and they are also missing on pkgs.a.o… 2016-07-06 18:11:14 maybe build of gogs and terraform has to fail before it builds the rest of commits 2016-07-06 18:11:40 I pushed my changes after gogs and terraform broke and they made it 2016-07-06 18:12:09 reverting gogs won't help anyway, the cause of build error there is new gcc 2016-07-06 18:12:25 we could disable gogs completely instead 2016-07-06 18:13:26 ^7heo: what do you think about it? 2016-07-06 18:19:47 jirutka: looks like only commits to testing are blocked by build failure 2016-07-06 18:39:49 <^7heo> barthalion: terraform fails too, because go? 2016-07-06 18:40:43 <^7heo> also, from what clandmeter said; it's not gogs or terraform that fails, it's gcc. 2016-07-06 18:40:46 <^7heo> the new gcc 2016-07-06 18:40:56 <^7heo> if we would revert that, maybe it would work again. 2016-07-06 18:41:15 <^7heo> c.f. 2016-07-06 18:41:15 <^7heo> <@clandmeter> ^7heo: currently it doesnt build, so apk add gogs@testing will not work 2016-07-06 18:41:19 <^7heo> < ^7heo> clandmeter: can you revert? 2016-07-06 18:41:34 <^7heo> <@clandmeter> no 2016-07-06 18:41:38 <^7heo> <@clandmeter> its not my change 2016-07-06 18:41:48 <^7heo> <@clandmeter> its gcc 2016-07-06 18:42:12 <^7heo> (sorry for the copy/pasting but it's relevant) 2016-07-06 18:43:01 <^7heo> jirutka: ^ 2016-07-06 18:43:13 uh, okay… why we have malfunctioning gcc on testing…? 2016-07-06 18:43:22 <^7heo> it's a functionning gcc 2016-07-06 18:43:26 <^7heo> that doesn't work with go. 2016-07-06 18:43:28 <^7heo> AFAIK. 2016-07-06 18:43:54 okay, so we’re back again… just revert gogs…? 2016-07-06 18:44:04 <^7heo> < barthalion> reverting gogs won't help anyway, the cause of build error there is new gcc 2016-07-06 18:44:54 you wrote that gcc is fine, just go doesn’t work with it… so get rid of go and all non-go packages would built fine, no? 2016-07-06 18:44:55 <^7heo> the only way to make it work again would be to delete the incriminated packages, I think. 2016-07-06 18:45:11 <^7heo> yeah, that'd be deleting quite some packages, but yeah. 2016-07-06 18:45:20 <^7heo> IMHO we should revert gcc 2016-07-06 18:45:30 I mean new/updated go packages that currently fails 2016-07-06 18:45:39 <^7heo> yeah but we don't know how many 2016-07-06 18:45:40 hey :( 2016-07-06 18:45:41 <^7heo> (I don't) 2016-07-06 18:45:44 äh, wrong smilie 2016-07-06 18:45:44 and that are in queue 2016-07-06 18:45:45 :) 2016-07-06 18:45:49 <^7heo> salut leo-unglaub 2016-07-06 18:46:17 <^7heo> I would like to see what reverting gcc does. 2016-07-06 18:46:28 why? 2016-07-06 18:46:49 is gcc functional? you wrote that yes 2016-07-06 18:47:09 <^7heo> well only partly. 2016-07-06 18:47:26 what does it mean? that go doesn’t work with latest gcc? 2016-07-06 18:47:30 <^7heo> see 5b7befa1b989315a57f4fb49b8381ce06ded96c9 2016-07-06 18:48:08 <^7heo> but wait 2016-07-06 18:48:12 <^7heo> that isn't logical 2016-07-06 18:48:23 <^7heo> because 5b7befa1b989315a57f4fb49b8381ce06ded96c9 has been pushed on the 1st 2016-07-06 18:49:11 <^7heo> and on the 4th, 34793a33c9f6bf9f947ac625bc8f2fad9f29145c (gogs) was passing the tests. 2016-07-06 18:49:25 <^7heo> and you (jirutka) even merged it. 2016-07-06 18:49:43 passed on Travis? 2016-07-06 18:49:44 <^7heo> jirutka: I don't know what it exactly means. 2016-07-06 18:49:47 <^7heo> jirutka: yeah. 2016-07-06 18:49:57 <^7heo> I don't know what is the state of gcc 2016-07-06 18:50:08 <^7heo> but essentially, I know what clandmeter wrote. 2016-07-06 18:50:15 <^7heo> and I know that barthalion also said it's gcc. 2016-07-06 18:50:19 <^7heo> (maybe because clandmeter said so) 2016-07-06 18:50:24 <^7heo> (maybe not) 2016-07-06 18:50:34 <^7heo> long story short; I didn't check much myself until now. 2016-07-06 18:50:45 <^7heo> I don't even know what's failing atm. 2016-07-06 18:50:54 the last change in gogs is from clandmeter https://github.com/alpinelinux/aports/commit/2867d304f9c04812d4a029d518159411ecf944c2 2016-07-06 18:50:55 not from me 2016-07-06 18:51:05 this patch hasn’t been tested on Travis 2016-07-06 18:51:13 <^7heo> hmm 2016-07-06 18:51:16 <^7heo> lemme check the change 2016-07-06 18:51:32 <^7heo> oh 2016-07-06 18:51:36 <^7heo> he pushed the new version. 2016-07-06 18:51:41 <^7heo> jirutka: can you revert? 2016-07-06 18:51:55 <^7heo> I am not sure if that is breaking it but... 2016-07-06 18:51:58 terraform is also some go crap 2016-07-06 18:52:08 yeah, we’ll see what will happen 2016-07-06 18:52:09 <^7heo> s/crap/software/ 2016-07-06 18:52:16 <^7heo> I don't hate go. 2016-07-06 18:52:26 <^7heo> I don't love it but I don't hate it. 2016-07-06 18:52:32 <^7heo> and afaik, it's MUCH better than what it replaces. 2016-07-06 18:52:40 <^7heo> but that's a discussion for #alpine-offtopic 2016-07-06 18:53:32 whats the problem with gcc? 2016-07-06 18:53:35 <^7heo> no idea. 2016-07-06 18:53:38 <^7heo> ask clandmeter 2016-07-06 18:53:46 <^7heo> or maybe barthalion knows. 2016-07-06 18:54:33 <^7heo> jirutka: do you know where I can see/find what's currently failing? 2016-07-06 18:54:54 ah, you were right, I’m stupid… reverting obviously can’t help, because it triggers rebuild of the previous commit and since the problem is outside of this pckage, it fails too… 2016-07-06 18:54:59 <^7heo> aka where can I see the state of build servers. 2016-07-06 18:55:12 state is http://build.alpinelinux.org/ 2016-07-06 18:55:15 <^7heo> thanks. 2016-07-06 18:55:24 but better is to watch #alpine-commits 2016-07-06 18:55:35 or messages from MQTT broker 2016-07-06 18:55:44 <^7heo> no idea where to find that. 2016-07-06 18:55:56 so we’re pretty fucked up… 2016-07-06 18:56:15 <^7heo> why? 2016-07-06 18:56:25 MQTT runs on msg.alpinelinux.org 2016-07-06 18:56:31 <^7heo> thanks. 2016-07-06 18:56:44 <^7heo> obviously not on / ;) 2016-07-06 18:57:01 <^7heo> and http://msg.alpinelinux.org/mqtt returns 502 bad gateway 2016-07-06 18:57:05 because reverting these failing go packages doesn’t help 2016-07-06 18:57:13 <^7heo> yeah well 2016-07-06 18:57:19 it’s MQTT, it doesn’t talk HTTP… 2016-07-06 18:58:06 <^7heo> yeah, well, it's the first time of my life that I read this acronym... 2016-07-06 18:58:11 <^7heo> so I tried to access it via http. 2016-07-06 18:58:24 so we need someone to fix go… 2016-07-06 18:58:52 <^7heo> I dunno exactly what's broken. 2016-07-06 18:58:58 me neither 2016-07-06 18:58:59 <^7heo> I still didn't see any error or error message. 2016-07-06 18:59:08 <^7heo> I mean, I'm reading stuff, accessing places... 2016-07-06 18:59:16 <^7heo> but there's nothing more than an IRC discussion for me atm. 2016-07-06 18:59:26 <^7heo> and missing packages too, apparently. 2016-07-06 18:59:38 you can see error message here http://build.alpinelinux.org/buildlogs/build-edge-x86/testing/terraform/terraform-0.6.16-r0.log 2016-07-06 18:59:59 and this is for gogs http://build.alpinelinux.org/buildlogs/build-edge-x86_64/testing/gogs/gogs-0.9.13-r0.log 2016-07-06 19:00:28 wait a moment… it seems that there are at least two unrelated problems 2016-07-06 19:00:31 <^7heo> http://build.alpinelinux.org/buildlogs/ is a useful link. 2016-07-06 19:00:32 <^7heo> thanks. 2016-07-06 19:00:52 <^7heo> I don't know why it's not on the main page. 2016-07-06 19:01:03 <^7heo> but whatever, now that I know it, it's fine; thanks. 2016-07-06 19:01:17 this log is from built of the latest commit by clandmeter … and this is definitely not caused by gcc 2016-07-06 19:01:36 <^7heo> I dunno, again; I just got access to the log ;) 2016-07-06 19:02:17 <^7heo> But the log from gogs isn't very informative. 2016-07-06 19:02:31 <^7heo> just that the problem was with the subpackages. 2016-07-06 19:04:11 yeah, try to build it locally 2016-07-06 19:04:14 why is terraform only built for a single platform? http://pkgs.alpinelinux.org/packages?name=&branch=&repo=&arch=&maintainer=Thomas+Boerger 2016-07-06 19:04:32 dunno 2016-07-06 19:04:42 and cloudfoundry-cli not for arm? 2016-07-06 19:05:17 jirutka: and do you have the time to review y python packages again? :) 2016-07-06 19:05:35 mosez: what python packages? 2016-07-06 19:06:03 <^7heo> jirutka: the first problem I see is that we're not using the github source. 2016-07-06 19:06:10 mosez: but no, not today, I have to preprare two presentations for tomorrow… and I’m still procrastinating :( 2016-07-06 19:06:29 jirutka: ah sorry... it's merged. totally missed the notification 2016-07-06 19:06:58 mosez: yeah, these are merged, but not built, because there’s some problem on build server 2016-07-06 19:07:12 mosez: that’s what we’re currently discussing… 2016-07-06 19:08:24 ah sorry, have not seen the lines about terraform :D 2016-07-06 19:09:30 <^7heo> mosez: no worries; it's a giant SNAFU 2016-07-06 19:09:36 <^7heo> lots of logs to read everywhere 2016-07-06 19:09:41 <^7heo> including IRC 2016-07-06 19:10:09 memory error while building terraform? i have built it on my scaleway server with 2mb memory :D 2016-07-06 19:10:31 s/mb/gb/ 2016-07-06 19:10:39 mosez: hmm, maybe it just doesn’t work on x86 and arm 2016-07-06 19:11:01 mosez: because x86_64 succeeded 2016-07-06 19:11:11 i have built it on arm at scaleway and x86_64 locally in a docker container 2016-07-06 19:11:17 mosez: also this package is from yesterday 2016-07-06 19:11:57 ^7heo: who told you that it’s related to new gcc? 2016-07-06 19:11:58 i know, it have been merged yesterday 2016-07-06 19:12:22 <^7heo> clandmeter: 2016-07-06 19:12:27 <^7heo> jirutka: ^ 2016-07-06 19:12:44 <^7heo> jirutka: it's currently building locally with a slightly different APKBUILD 2016-07-06 19:12:51 <^7heo> jirutka: I keep you posted. 2016-07-06 19:12:58 because I don’t think that it’s related; as I’m investigating logs etc. 2016-07-06 19:13:00 <^7heo> if it works, I commit and push and PR 2016-07-06 19:13:13 <^7heo> yeah it didn't look like it was from my POV 2016-07-06 19:13:21 <^7heo> so I just took the gogs APKBUILD and tried it locally 2016-07-06 19:13:25 <^7heo> and I'm fixing as I go. 2016-07-06 19:13:29 <^7heo> so far so good. 2016-07-06 19:13:53 <^7heo> still dl-ing the deps 2016-07-06 19:14:15 <^7heo> one issue is that go isn't using releases for deps 2016-07-06 19:14:22 <^7heo> it's using master AFAIK 2016-07-06 19:14:40 <^7heo> so if the master of any deps would break; the dep would cause the build to fail. 2016-07-06 19:14:47 it's time that they really start vendoring. but Unknwon the author of gogs did some strange decisions... maybe it's time to revive gitea... 2016-07-06 19:15:20 of course, because go doesn’t use releases, they just push the latest somethinf from repos… 2016-07-06 19:15:41 http://dave.cheney.net/2016/06/24/gophers-please-tag-your-releases 2016-07-06 19:15:42 <^7heo> yeah well, for now I'm trying to fix the mess 2016-07-06 19:15:51 <^7heo> THEN I'll think about how to make it right 2016-07-06 19:16:02 <^7heo> mosez: on gh it's tagged 2016-07-06 19:16:09 <^7heo> mosez: so we could use that. 2016-07-06 19:16:22 ^7heo: but the deps are not vendored. 2016-07-06 19:16:24 ^7heo: if you want to really fix the mess, then remove go and all go packages… I’m not kidding now… go ecosystem is a mess 2016-07-06 19:16:30 <^7heo> mosez: what strange decision? 2016-07-06 19:16:34 <^7heo> s/decision/&s/ 2016-07-06 19:16:51 <^7heo> jirutka: we can't afford to remove go; more and more software is using go. 2016-07-06 19:17:05 decline real improvements, decline automation in favor of manually rolling releases etc pp 2016-07-06 19:17:19 ^7heo: and? more and more distros uses systemd, does it mean that we must use it too? 2016-07-06 19:17:22 <^7heo> mosez: do you have any source? 2016-07-06 19:17:29 <^7heo> jirutka: good point. 2016-07-06 19:17:52 <^7heo> at the same time 2016-07-06 19:18:07 <^7heo> I was expecting to have to build gogs myself when I installed it here. 2016-07-06 19:18:13 <^7heo> (here -> work) 2016-07-06 19:18:14 ^7heo: yeah, me.... i wanted to intriduce different things. i have prepared entirely drone ci based releases, asked for different features if i should provide them and so on 2016-07-06 19:18:37 <^7heo> mosez: yeah but that is a severly subjective opinion then 2016-07-06 19:18:49 i like go. but the dep management can get a lot of improvements. 2016-07-06 19:18:53 <^7heo> mosez: please pardon my doubt but I can't see sources so... maybe he had reasons. 2016-07-06 19:19:11 <^7heo> yeah well, if I have to implement the dep mgmt myself, I will. 2016-07-06 19:19:36 <^7heo> let's make an option for go get 2016-07-06 19:19:39 <^7heo> go get --lost 2016-07-06 19:19:41 mosez: because Go doesn’t have any deps management! that thing that you call a “deps management” in go is made ex-post and it’s just a incredibly stupid workaround 2016-07-06 19:19:45 https://github.com/gogits/gogs/pull/2372 2016-07-06 19:19:52 <^7heo> thanks mosez 2016-07-06 19:20:23 <^7heo> so essentially, the APKBUILD I got from clandmeter for gogs; after I did the fixes to get it work again here 2016-07-06 19:20:38 <^7heo> is failing EXACTLY where I was at when he asked me about the state of gogs this morning. 2016-07-06 19:20:41 <^7heo> =/ 2016-07-06 19:20:42 ^7heo: this pr lacks additional conversations from the gitter chat 2016-07-06 19:20:59 nevermind, we should start monitoring build failures and start emailing committers when they package fail to build 2016-07-06 19:21:13 <^7heo> yeh 2016-07-06 19:21:18 <^7heo> or better 2016-07-06 19:21:25 <^7heo> the git commiter 2016-07-06 19:21:40 <^7heo> (I thought you meant maintainer) 2016-07-06 19:22:08 I thought that there’s an unwritten rule for committers to watch #alpine-commits and when the package fail, then fix it… not to leave it failing 2016-07-06 19:22:19 <^7heo> so, why does abuild try to get a fakeroot in ${pkgname}/${pkgname}? 2016-07-06 19:22:30 I dunno 2016-07-06 19:22:40 <^7heo> is it standard? 2016-07-06 19:22:54 <^7heo> s/standard/default/ 2016-07-06 19:22:59 I need to prepare my presentations, not to fix someone else mess know :/ 2016-07-06 19:23:16 <^7heo> IKR 2016-07-06 19:23:22 <^7heo> same here with food and relaxation 2016-07-06 19:24:34 so, mosez, I’m sorry, but your python packages are properly merged, but not built and I don’t know when it will be 2016-07-06 19:24:39 <^7heo> if only I knew how to keep the deps between runs 2016-07-06 19:24:51 <^7heo> (of abuild) 2016-07-06 19:26:01 <^7heo> okay, -K 2016-07-06 19:26:06 <^7heo> will do that next run. 2016-07-06 19:30:01 jirutka: no problem :) 2016-07-06 19:30:32 <^7heo> the number of deps is incredible... 2016-07-06 19:31:04 ^7heo: put the deps in a separate archive? 2016-07-06 19:31:15 <^7heo> mosez: nah that's crappy. 2016-07-06 19:31:24 <^7heo> we should use the RCS tag. 2016-07-06 19:31:46 <^7heo> -K doesn't do shit about the deps... 2016-07-06 19:31:50 <^7heo> I have to DL them EVERY time... 2016-07-06 19:31:51 <^7heo> dafuq. 2016-07-06 19:33:04 the go vendoring would avoid that :D 2016-07-06 19:33:30 how do you install the deps? 2016-07-06 19:35:10 ^7heo: with glide install? 2016-07-06 19:35:35 <^7heo> mosez: go get -v -d 2016-07-06 19:35:47 <^7heo> and one additional go get with a hardcoded dep for now. 2016-07-06 19:35:48 wow... that will fail quite often ;) 2016-07-06 19:35:59 <^7heo> yeah but it's just a debug for now. 2016-07-06 19:36:15 <^7heo> I'll check a better solution once I get a working package. 2016-07-06 19:36:22 make glide a build dependency and cal glide install :) 2016-07-06 19:36:30 <^7heo> it's not really that that's blocking for now 2016-07-06 19:36:35 <^7heo> and yes, I will check out glide. 2016-07-06 19:36:36 <^7heo> thanks for the tip. 2016-07-06 19:36:59 <^7heo> but abuild -K is documented as "keeping the build temp dirs" 2016-07-06 19:37:05 <^7heo> it apparently doesn't 2016-07-06 19:37:07 https://github.com/gogits/gogs/blob/master/glide.lock at least it makes sure that correct dependencies are used. 2016-07-06 19:37:10 <^7heo> as go wouldn't re-downlaod anything. 2016-07-06 19:37:19 <^7heo> yeah 2016-07-06 19:37:22 <^7heo> that'd be good. 2016-07-06 19:37:48 <^7heo> anyway, again; I'm trying to get the APKBUILD to work atm. 2016-07-06 19:37:52 go get will even fail quite often because of the changes on the used lib xorm 2016-07-06 19:37:56 <^7heo> not to fix any build error. 2016-07-06 19:38:03 have fun :) 2016-07-06 19:38:24 <^7heo> I think I need to read the man of go on how to use all the threads of my CPU 2016-07-06 19:38:29 my terraform and cloudfoundry-cli packages are working quite fine beside the memory error 2016-07-06 19:38:31 btw we need someone to delete bash43-042 from distfiles on armhf build machine; it fails on checksum, but the checksum is actually correct 2016-07-06 19:38:46 mosez: on what platform? it seems that it fails just on x86 and armhf 2016-07-06 19:39:10 <^7heo> the binary builds fine btw. 2016-07-06 19:39:11 arm and x86_64 worked fine for me. 2016-07-06 19:39:15 <^7heo> on my computer. 2016-07-06 19:39:23 <^7heo> it's just the packaging that fails. 2016-07-06 19:39:52 i don't have a x86 system to test 2016-07-06 19:41:14 <^7heo> Debbuging gogs's APKBUILD: https://www.youtube.com/watch?v=dTAAsCNK7RA 2016-07-06 19:41:52 ^7heo: what's the issue? 2016-07-06 19:42:08 <^7heo> my lack of knowledge of the abuild system 2016-07-06 19:42:31 <^7heo> and the lack of knowledge of the last contributor of the go build system. 2016-07-06 19:42:46 <^7heo> (leading to use own-hosted archives to build stuff) 2016-07-06 19:42:54 okay, let’s sum it up: gogs r5 was broken and it’s not related to gcc → I’ve reverted that commit; terraform fails on x86 and armhf, builds fine on x86_64 → I’ve disabled it for these platforms 2016-07-06 19:43:22 <^7heo> jirutka: yeah I fixed the previously broken gogs (r3 -> r4 afair) 2016-07-06 19:43:25 build queue for x86 and x86_64 is now clean, new python packages are built 2016-07-06 19:43:29 <^7heo> and then it got broken a day after or so. 2016-07-06 19:43:47 i will build it now again on my arm server 2016-07-06 19:43:53 <^7heo> wait 2016-07-06 19:44:07 <^7heo> I can provide you with a diff to try the new version. 2016-07-06 19:44:12 <^7heo> do you want to try it? :) 2016-07-06 19:44:31 armhf is blocked on main/bash because of incorrect checksum – the checksum in APKBUILD is correct, so it seems that some corrupted file stuck in distfiles 2016-07-06 19:45:22 <^7heo> mosez: I'm still debugging but it's near the end of the package build routine 2016-07-06 19:45:27 <^7heo> should be working soon'ish 2016-07-06 19:45:34 <^7heo> then I'll look into using glide. 2016-07-06 19:45:50 <^7heo> and then I'll commit/push/PR on gh so it gets tested this time. 2016-07-06 19:45:54 new python packages should be already built, they should appear on https://pkgs.alpinelinux.org/packages?name=pgcli&branch=&repo=&arch=&maintainer= in few minutes 2016-07-06 19:46:48 <^7heo> \o/ 2016-07-06 19:46:54 <^7heo> totally algitbot 2016-07-06 19:46:57 <^7heo> TOTALLY. 2016-07-06 19:47:11 so I was right – there’s no problem with gcc, just two broken go packages stuck in build queue 2016-07-06 19:47:17 <^7heo> yeah 2016-07-06 19:47:28 <^7heo> thanks for providing me with the links about logs and stuff. 2016-07-06 19:47:33 maybe the problem with terraform on x86 is related to gcc, I dunno, but there’s no evidence for that 2016-07-06 19:47:39 <^7heo> I don't know much about alpine's build stuff yet. 2016-07-06 19:47:41 http://pkgs.alpinelinux.org/packages?name=&branch=&repo=&arch=&maintainer=Thomas+Boerger yeah :D 2016-07-06 19:47:45 <^7heo> I just made a few packages so far. 2016-07-06 19:48:15 <^7heo> nice list mosez 2016-07-06 19:48:19 I can’t fix the problem on armhf, it seems that someone with dirrect access to the server must remove corrupted bash43-042 2016-07-06 19:48:20 <^7heo> http://pkgs.alpinelinux.org/packages?name=&branch=&repo=&arch=&maintainer=7heo 2016-07-06 19:48:23 <^7heo> just two 2016-07-06 19:48:47 <^7heo> mosez: we should have a beer next time you come to BLN 2016-07-06 19:49:02 <^7heo> gogs passes. 2016-07-06 19:49:03 <^7heo> built. 2016-07-06 19:49:12 <^7heo> okay, lemme remove the debug crap and send the patch 2016-07-06 19:50:02 ^7heo: looks like i will be in berlin in october for the container con 2016-07-06 19:50:07 and linux con 2016-07-06 19:50:20 <^7heo> not going to either I think 2016-07-06 19:50:30 <^7heo> containers are stuff I drop on people who use them. 2016-07-06 19:50:46 <^7heo> and linux, well, I use it, but... I prefer BSD. 2016-07-06 19:50:50 <^7heo> anyway, beer. 2016-07-06 19:50:51 hehe... my official job description at SUSE is Docker Developer ;) 2016-07-06 19:50:59 <^7heo> :'( 2016-07-06 19:51:03 <^7heo> Well, beer is anyway cool 2016-07-06 19:51:06 ^7heo: LOL, what’s this https://www.youtube.com/watch?v=dTAAsCNK7RA ? XD 2016-07-06 19:51:10 <^7heo> We could have a container of it. 2016-07-06 19:51:24 beer is always good 2016-07-06 19:51:24 <^7heo> jirutka: a cool band doing a cool song. 2016-07-06 19:51:28 <^7heo> jirutka: why? 2016-07-06 19:51:46 <^7heo> jirutka: check that out: https://www.youtube.com/watch?v=MejbOFk7H6c 2016-07-06 19:52:14 ^7heo: I thought that it’s somehow go-related when you’ve sent me it XD 2016-07-06 19:52:14 <^7heo> if that isn't music, I don't know what is. 2016-07-06 19:52:28 <^7heo> jirutka: nah, it's 'here it goes again' related ;) 2016-07-06 19:52:35 ^7heo: hmm, BSD… with what prefix? Free, Open…? 2016-07-06 19:52:54 ^7heo: aha 2016-07-06 19:53:03 <^7heo> jirutka: .*BSD. 2016-07-06 19:53:04 ^7heo: this music is not hard enough :) 2016-07-06 19:53:17 <^7heo> mosez: try "Thy art is murder" then. 2016-07-06 19:54:04 ^7heo: that sounds interesting :D 2016-07-06 19:54:15 ^7heo: btw I read somewhere that OpenBSD guys are working on support for containers on OpenBSD :) so maybe we will have really secure containers someday 2016-07-06 19:54:18 ACTION will be lucky at wacken in august... 2016-07-06 19:54:55 jirutka: and freebsd got https://github.com/3ofcoins/jetpack :D 2016-07-06 19:55:17 <^7heo> jirutka: http://ix.io/112m 2016-07-06 19:55:26 <^7heo> that's as fast as I can go :) 2016-07-06 19:55:33 <^7heo> mosez: ^ if you want to try it out. 2016-07-06 19:55:54 <^7heo> ofc its on top of the one that was reverted 2016-07-06 19:55:57 <^7heo> so, not current 2016-07-06 19:56:01 ^7heo: but nevermind, no one will use it, because majority apparently prefers inherently insecure and broken craps (Docker) :P 2016-07-06 19:57:53 jirutka: i'm using alpine within all my containers ;) 2016-07-06 19:58:17 mosez: me to, within LXC… 2016-07-06 19:58:32 an lxc aintainer is my new colleague :D 2016-07-06 19:58:35 <^7heo> I'm not using containers 2016-07-06 19:58:36 maintainer 2016-07-06 19:58:58 mosez: LXC is not great, but still the best vanilla-kernel-based abstraction for containers 2016-07-06 19:59:16 <^7heo> yeah I guess. 2016-07-06 19:59:26 mosez: OpenVZ is much mature and secure, but it needs patched RHEL kernel 2016-07-06 19:59:38 i like docker, even if it got some issues. but since i'm a docker developer started at may i can fix the issues :P 2016-07-06 19:59:58 mosez: If you wanna fix Docker issues, then just run rm -Rf / ;) 2016-07-06 20:00:42 <^7heo> damn, I did a rebase on origin/master instead of upstream/master 2016-07-06 20:00:44 <^7heo> v_v 2016-07-06 20:00:49 <^7heo> taking ages now. 2016-07-06 20:00:51 no way... but maybe we can focus more on rkt or runc. 2016-07-06 20:00:55 mosez: it’s the same as with CVS and SVN… let me quote Linus Torvalds: 2016-07-06 20:00:56 When I say I hate CVS with a passion, I have to also say that if there any SVN users (Subversion users) in the audience, you might want to leave. Because my hatred of CVS has meant that I see Subversion as being the most pointless project ever started, because the whole slogan for the Subversion for a while was 'CVS done right' or something like that. And if you start with that kind of slogan, there is nowhere you can go. It's like, there is no 2016-07-06 20:00:56 way to do CVS right. 2016-07-06 20:01:43 ^7heo: if you could take that effort to read literally 6 lines before my highlight of your nick, you wouldn't have to repeat everything we know already, really 2016-07-06 20:02:22 lo barthalion 2016-07-06 20:02:40 ^7heo: 2012 barthalion | we could disable gogs completely instead 2016-07-06 20:02:42 <^7heo> barthalion: sorry, you're ignored, sometimes. 2016-07-06 20:02:43 mosez: the only promising new container abstraction I know about is https://github.com/tailhook/vagga 2016-07-06 20:02:57 <^7heo> and also, giving crappy solutions. 2016-07-06 20:03:00 ^7heo: but you're too busy insulting people in the channels nearby apparently 2016-07-06 20:03:12 <^7heo> I don't even know what you're talking about. 2016-07-06 20:03:18 of course you don't 2016-07-06 20:03:22 how could you know 8) 2016-07-06 20:03:27 <^7heo> well, since you're inventing the stuff, I dunno. 2016-07-06 20:03:29 <^7heo> tell me. 2016-07-06 20:03:30 to be honest, me neither… 2016-07-06 20:03:32 <^7heo> yeah 2016-07-06 20:03:37 <^7heo> I'm like Oo 2016-07-06 20:03:40 <^7heo> but whatever 2016-07-06 20:03:45 <^7heo> No time for politics 2016-07-06 20:06:16 jirutka: cyphar (one runc maintainer and also a team mate of me) is working on rotless runc containers ;) 2016-07-06 20:06:40 runc and rkt as well are awesome, but they are not pushed like docker 2016-07-06 20:06:51 <^7heo> never even heard of that. 2016-07-06 20:25:27 <^7heo> https://github.com/alpinelinux/aports/pull/151 2016-07-06 20:25:37 <^7heo> I hope this doesn't fail. 2016-07-06 20:35:15 jirutka: so armhf builds successfully for terraform, i have tried it with the latest package version where i just set to all architectures. 2016-07-06 20:35:35 ^7heo: failed :) 2016-07-06 20:36:00 mosez: okay, I’ll try to reenable it after someone will fix the bash problem on armhf 2016-07-06 20:36:11 mosez: now it’s blocked because of it 2016-07-06 20:36:19 >>> ERROR: gogs*: Found textrels: 2016-07-06 20:36:19 TEXTREL /home/travis/build/alpinelinux/aports/testing/gogs/pkg/gogs/usr/bin/gogs 2016-07-06 20:36:53 mosez: yeah, maybe it’s related to gcc after all 2016-07-06 20:37:04 maybe 2016-07-06 20:37:32 mosez: anyway, it seems that this problem doesn’t occur on x86_64 2016-07-06 20:39:50 <^7heo> mosez: I know 2016-07-06 20:40:08 <^7heo> mosez: travis catched the SAME error as what happened during the builds... 2016-07-06 20:40:24 <^7heo> jirutka: why? 2016-07-06 20:40:42 <^7heo> or are you talking about something else than gogs? 2016-07-07 00:28:08 <^7heo> https://travis-ci.org/alpinelinux/aports/builds/142919415 2016-07-07 00:28:17 <^7heo> https://github.com/alpinelinux/aports/pull/151 2016-07-07 00:28:22 <^7heo> sqlite support disabled 2016-07-07 00:28:24 <^7heo> gogs builds. 2016-07-07 06:30:01 ^7heo: please rebase against current aports 2016-07-07 06:31:02 and i think we need sqlite 2016-07-07 06:32:28 and i think i know what the problem is, but i need some help to get it fixed. 2016-07-07 06:34:37 oh seems jirutka has reverted my patch. 2016-07-07 07:06:52 hi all 2016-07-07 07:09:59 hi fcolista 2016-07-07 07:10:34 clandmeter, there's a new version of libmnl, after 4 years. http://sprunge.us/WeZT 2016-07-07 07:10:46 no abi changes 2016-07-07 07:10:59 something in contrary if i push it? 2016-07-07 07:11:52 i dont think so 2016-07-07 07:23:15 morning 2016-07-07 07:26:05 rawtherapee has stopped working. could someone be kind enough to trigger a rebuild? 2016-07-07 07:26:19 http://tpaste.us/AjoK 2016-07-07 07:27:58 darktable version 2 builds, but it seg faults the same way as verion 1.6 did :'(( 2016-07-07 07:31:19 more systemd fun http://lwn.net/Articles/690151/ 2016-07-07 07:31:44 ScrumpyJack, I think ncopa is working on the glib quark fix 2016-07-07 07:32:01 it's complicated problem and upstream is not entirely helpful on it 2016-07-07 07:34:20 i wonder if i should look at aarch64 or libressl next 2016-07-07 07:38:59 wrt systemd, I guess only Fedora will adopt this 2016-07-07 07:39:23 I like the change from desktop distro user perspective, but anywhere else, wat 2016-07-07 07:39:43 fabled: if you're bored, you could take a look at the rpi overlays :) 2016-07-07 07:39:52 fabled: +1 for aarch64 2016-07-07 07:39:53 but i'm pretty sure you're not bored :) 2016-07-07 07:39:59 fabled: also can you remove cached patches for bash? 2016-07-07 07:40:41 fabled: one has been changed by upstream so the build is failing, checksums were corrected in git so it works on non-arm builders 2016-07-07 07:41:50 fabled: i vote for aarch64 :) 2016-07-07 07:43:23 bash43-042: FAILED 2016-07-07 07:43:24 sha512sum: WARNING: 1 of 1 computed checksums did NOT match 2016-07-07 07:43:24 Because the remote file above failed the sha512sum check it will be deleted. 2016-07-07 07:43:24 Rebuilding will cause it to re-download which in some cases may fix the problem. 2016-07-07 07:43:24 Deleting: bash43-042 2016-07-07 07:43:28 it's not deleting it? 2016-07-07 07:47:25 does http://sprunge.us/BHHX look right? 2016-07-07 07:47:31 to support arch="all !armhf" 2016-07-07 07:51:28 ncopa, ^^ Deleting: $file in abuild seems to delete the symlink in $srcdir, not the actual file 2016-07-07 07:54:58 <^7heo> clandmeter: I know we need sqlite for gogs 2016-07-07 07:55:24 <^7heo> clandmeter: why are you pushing so hard for the latest version? 2016-07-07 07:55:45 pushing hard? 2016-07-07 07:56:03 <^7heo> yeah. 0.6 is working fine with the fix I did. 2016-07-07 07:57:03 <^7heo> so, yesterday, when you pushed 0.9 it broke 2016-07-07 07:57:03 its not my push that broke it 2016-07-07 07:57:20 <^7heo> we (jirutka) reverted 0.6 and it worked again 2016-07-07 07:57:28 <^7heo> it is. 2016-07-07 07:57:33 it did? 2016-07-07 07:57:40 thats strange 2016-07-07 07:57:47 0.6 with sqlite? 2016-07-07 07:58:13 <^7heo> yes, 'cause go-sqlite using -r and -pie together in ld 2016-07-07 07:58:19 <^7heo> yep 2016-07-07 07:58:36 <^7heo> but nevermind 2016-07-07 07:58:44 <^7heo> afaik 0.6 works 2016-07-07 07:59:02 <^7heo> and 0.9 on gh has travis for testing 2016-07-07 07:59:22 <^7heo> so I could be autonomous there 2016-07-07 07:59:53 <^7heo> (I could use your knowledge tho) 2016-07-07 08:00:16 <^7heo> the point being: travis does what the build server do 2016-07-07 08:00:33 <^7heo> so if it comes from gh, it builds 2016-07-07 08:01:57 <^7heo> clandmeter: long story short, IMHO, the desired state would be a working 0.6 rather than an incomplete 0.9 2016-07-07 08:02:15 i just tried a local build 2016-07-07 08:02:26 <^7heo> and? 2016-07-07 08:02:28 pkgver=0.6.1 fails 2016-07-07 08:02:37 TEXTREL /home/clandmeter/aports/testing/gogs/pkg/gogs/usr/bin/gogs 2016-07-07 08:02:47 <^7heo> not on the gh or build servers it doesn't 2016-07-07 08:02:52 it's go + gcc6.1 combination that brings the issue 2016-07-07 08:02:57 go needs to be fixed 2016-07-07 08:03:05 <^7heo> fabled: not sure no 2016-07-07 08:03:20 the issue affects all go packages that has native code in it 2016-07-07 08:03:32 ^7heo, i'm sure, i used the source to look up what's happening 2016-07-07 08:03:36 <^7heo> the issue is -r and -pie used in ld in conjunction 2016-07-07 08:03:44 fabled: yes i found it tried to set no-pie, but when i try to disable it, it complains about mixing -pie and -r 2016-07-07 08:03:47 ^7heo, yes, and it's go adding it 2016-07-07 08:03:54 go detects if gcc supports -no-pie, and if yes it adds that 2016-07-07 08:04:02 <^7heo> yeah I believe that too 2016-07-07 08:04:08 gcc5.x did not support it, gcc6.1 does support it, it's new feature there 2016-07-07 08:04:17 that's why it breaks with gcc6.1 only 2016-07-07 08:04:22 but it's go that doing wrong things 2016-07-07 08:04:27 https://github.com/golang/go/blob/master/src/cmd/go/build.go#L3070 2016-07-07 08:04:36 the ticket mentioned has go has now -buildmode pie or something similar 2016-07-07 08:04:38 <^7heo> yeah but then why does 0.6 bui:d? 2016-07-07 08:04:42 we could try adding that 2016-07-07 08:05:06 ^7heo, even if 0.6 builds, other packages are broken because go is broke 2016-07-07 08:05:13 <^7heo> fabled: well, that's the other point 2016-07-07 08:05:15 i'd rather fix the issue, not the symptom 2016-07-07 08:05:22 i tried that, but didnt fix it. 2016-07-07 08:05:45 <^7heo> with me working on fixing th stuff; and clandmeter working on something, we step on each other's toes 2016-07-07 08:05:57 <^7heo> this is very frustarting and time consuming 2016-07-07 08:06:07 <^7heo> so we should define who is 'we' 2016-07-07 08:06:19 ^7heo, that's software development. 2016-07-07 08:06:24 <^7heo> no 2016-07-07 08:06:34 <^7heo> that's crappy sync 2016-07-07 08:06:40 it was unexpected 2016-07-07 08:06:48 <^7heo> what was? 2016-07-07 08:06:57 that upgrading gcc makes go do funky stuff 2016-07-07 08:07:14 <^7heo> I dunno, gcc was upgraded on the 1st 2016-07-07 08:07:22 <^7heo> gogs 0.6 on the 4th 2016-07-07 08:07:29 <^7heo> it worked afaik 2016-07-07 08:07:33 <^7heo> look it up 2016-07-07 08:07:37 i don't think it did 2016-07-07 08:07:47 <^7heo> I think it did 2016-07-07 08:09:02 <^7heo> look, the point now is: it's my name in 'maintainer'. If stuff is broken, I don't care if people push on that file. but afaik it wasn't and the NEW version did broke gogs 2016-07-07 08:09:25 <^7heo> so, REALLY crappy communication 2016-07-07 08:10:04 <^7heo> and more, clandmeter didn't really wait to chat with me for pushig his stuff 2016-07-07 08:10:29 so ^7heo yes, it would have been polite to check with you 2016-07-07 08:10:31 but that's not the problem 2016-07-07 08:10:35 in this particular instance 2016-07-07 08:10:40 i reverted clandmeter's change 2016-07-07 08:10:42 and i get: 2016-07-07 08:10:46 >>> gogs*: Running postcheck for gogs 2016-07-07 08:10:46 >>> ERROR: gogs*: Found textrels: 2016-07-07 08:10:46 TEXTREL /data/aports/testing/gogs/pkg/gogs/usr/bin/gogs 2016-07-07 08:10:46 >>> ERROR: gogs*: prepare_subpackages failed 2016-07-07 08:10:54 pkgname=gogs 2016-07-07 08:10:54 pkgver=0.6.1 2016-07-07 08:10:54 pkgrel=5 2016-07-07 08:10:57 <^7heo> with 0.6? 2016-07-07 08:11:10 <^7heo> hmmm. that's news to me 2016-07-07 08:11:17 the problem really is gcc6.1 upgrade affected go, and go broke 2016-07-07 08:11:22 anything you try to build with go will fail 2016-07-07 08:11:24 not just gogs 2016-07-07 08:11:31 well anything that requires native linking 2016-07-07 08:11:35 <^7heo> ok so now, why did it pass testing, and obviously build on the servers 2016-07-07 08:11:42 it didn't 2016-07-07 08:11:47 because gcc upgrade to 6.1 uncovered bug in go 2016-07-07 08:11:49 the revert didn't trigger a rebuild 2016-07-07 08:11:51 <^7heo> apk begs to differ 2016-07-07 08:11:57 <^7heo> barthalion: 2016-07-07 08:11:59 <^7heo> apk begs to differ 2016-07-07 08:12:02 it just re-used old package 2016-07-07 08:12:13 <^7heo> with renaming to r5? 2016-07-07 08:12:20 <^7heo> FUN 2016-07-07 08:12:22 okay, fair point 2016-07-07 08:12:35 <^7heo> SO WTF 2016-07-07 08:12:40 hm, no 2016-07-07 08:12:45 pkgrel did not change 2016-07-07 08:12:47 <^7heo> WHY AM I TYPING IN ALL CAPS NOW 2016-07-07 08:12:56 <^7heo> ok fixed 2016-07-07 08:12:56 are you on x86 or x86_64 ? 2016-07-07 08:12:58 <^7heo> sorry 2016-07-07 08:13:02 i think the x86 build might've succeeded 2016-07-07 08:13:02 <^7heo> latter 2016-07-07 08:13:09 <^7heo> nope 2016-07-07 08:13:11 <^7heo> latyer 2016-07-07 08:13:12 also 2016-07-07 08:13:19 the gcc commit date is different from author date 2016-07-07 08:13:30 <^7heo> ok? 2016-07-07 08:13:42 <^7heo> i'm on my phone rightnow 2016-07-07 08:13:49 so given the same pkgrel, no build was triggered anyway 2016-07-07 08:13:56 <^7heo> I should get going anyway 2016-07-07 08:14:07 commit 5b7befa1b989315a57f4fb49b8381ce06ded96c9 2016-07-07 08:14:07 Author: Timo Ter*s 2016-07-07 08:14:07 AuthorDate: Fri Jul 1 12:28:16 2016 +0000 2016-07-07 08:14:07 Commit: Natanael Copa 2016-07-07 08:14:07 CommitDate: Tue Jul 5 17:56:14 2016 +0000 2016-07-07 08:14:08 main/gcc: upgrade to 6.1.0 2016-07-07 08:14:11 <^7heo> I'll check tha out at work 2016-07-07 08:14:18 <^7heo> fabled: thanks 2016-07-07 08:14:24 <^7heo> fabled: that's why 2016-07-07 08:14:29 gcc was upgrade on Jul5, not Jul1 2016-07-07 08:14:38 <^7heo> yeah 2016-07-07 08:14:52 <^7heo> that's why packages exist 2016-07-07 08:14:54 yes 2016-07-07 08:14:58 <^7heo> thanks 2016-07-07 08:15:07 <^7heo> problem solved 2016-07-07 08:15:28 <^7heo> and then clandmeter just tried to get stuff fixed 2016-07-07 08:15:42 yes. 2016-07-07 08:15:52 but it's the gcc+go combination that broke things 2016-07-07 08:15:58 <^7heo> sure 2016-07-07 08:16:04 <^7heo> -pie and -r 2016-07-07 08:16:07 <^7heo> in ld 2016-07-07 08:16:14 <^7heo> added by go build 2016-07-07 08:17:01 <^7heo> anyway, clandmeter sorry for ranting at you; I didn't have all the data. 2016-07-07 08:17:02 does adding "-buildmode=pie" to go build work? 2016-07-07 08:17:18 <^7heo> fabled: I'll try that in a few hours 2016-07-07 08:17:23 <^7heo> gotta go 2016-07-07 08:17:29 we should make that default on go 2016-07-07 08:17:33 if it works 2016-07-07 08:17:35 <^7heo> yeah agreed 2016-07-07 08:17:43 <^7heo> pie needed for PaX 2016-07-07 08:17:47 <^7heo> so yeah 2016-07-07 08:17:57 <^7heo> or grsec 2016-07-07 08:18:03 it's good for various reasons 2016-07-07 08:18:14 <^7heo> I'm not too familiar with the details 2016-07-07 08:18:25 PaX does not strictly need it; but it reduces run time memory usage when multiple copies run; and it improves ASLR 2016-07-07 08:19:48 fabled: i think ive tried that, which didnt work. 2016-07-07 08:20:56 hmm looks like it works 2016-07-07 08:22:06 <^7heo> clandmeter: thanks for trying 2016-07-07 08:22:33 ^7heo: ill commit that change so it has sqlite again. 2016-07-07 08:22:49 <^7heo> thanks, ypu're reading my mind 2016-07-07 08:23:19 weird, im sure i tried something like this before. 2016-07-07 08:23:48 maybe i tried -buildmode=-pie 2016-07-07 08:23:58 <^7heo> possibly 2016-07-07 08:24:11 <^7heo> or ldflags? 2016-07-07 08:24:42 <^7heo> because go build has -ldflags 2016-07-07 08:24:52 <^7heo> which I tried 2016-07-07 08:25:07 <^7heo> it does override anything, just appends 2016-07-07 08:25:38 <^7heo> s/does/&n't/ 2016-07-07 08:26:05 <^7heo> anyway 2016-07-07 08:26:24 <^7heo> if 0.9 works, I owe you a beer clandmeter 2016-07-07 08:26:31 <^7heo> now, bbl 2016-07-07 08:26:41 it works, ive got it running here. 2016-07-07 08:26:49 it just sucks for aports 2016-07-07 08:27:00 flat repo's are a no go 2016-07-07 08:27:24 <^7heo> clandmeter: flat repos? 2016-07-07 08:27:39 like aports, instead of repository per package 2016-07-07 08:27:50 yes aports is flat, has many dirs inside main 2016-07-07 08:27:52 clandmeter: it's slow or…? 2016-07-07 08:28:26 so it exec git for each directory to get the git log. 2016-07-07 08:28:33 which is extremely slow 2016-07-07 08:28:41 <^7heo> ah 2016-07-07 08:28:43 there is an issue about it 2016-07-07 08:28:49 but no real fix. 2016-07-07 08:29:03 <^7heo> yeah let's look into that ater 2016-07-07 08:29:04 they didnt add any logic to the caching backend to support it. 2016-07-07 08:29:17 <^7heo> for go? 2016-07-07 08:29:26 gogs has a caching system 2016-07-07 08:29:36 but not for this part 2016-07-07 08:29:38 <^7heo> ah 2016-07-07 08:29:56 it takes serveral minutes to load the dir list of main repo. 2016-07-07 08:30:10 and thats on a 8 core machine. 2016-07-07 08:30:17 i wonder what an rpi would do. 2016-07-07 08:30:32 <^7heo> you meant: gogs is a no go for hosting aports, right? 2016-07-07 08:30:38 right 2016-07-07 08:30:43 <^7heo> ok gotcha 2016-07-07 08:31:24 <^7heo> but first we need to manage the deps better anyway ;) 2016-07-07 08:31:28 repo's that are more horizontal then vertical and larger, will ahve this issue 2016-07-07 08:31:44 redmine has the same issue 2016-07-07 08:32:03 <^7heo> and I don't think that gogs will be wildy accepted here anyway 2016-07-07 08:32:06 they all use external git command to read it. 2016-07-07 08:32:07 <^7heo> so... 2016-07-07 08:32:14 <^7heo> does not matter that much 2016-07-07 08:32:30 gogs doesnt look that bad. 2016-07-07 08:32:36 it has improved 2016-07-07 08:32:55 <^7heo> go is a no go for some of us 2016-07-07 08:32:59 im thinking of setting it up here for my private repo's 2016-07-07 08:33:03 <^7heo> (pun intended) 2016-07-07 08:33:23 <^7heo> clandmeter: I'm using it everywhere 2016-07-07 08:33:32 <^7heo> I like it 2016-07-07 08:33:43 then try to add your own aports to it ;-) 2016-07-07 08:33:57 ncopa, is http://sprunge.us/iVEY ok? 2016-07-07 08:34:00 <^7heo> but yeah mosez had isses with pushing features apparently 2016-07-07 08:34:15 clandmeter, ^7heo : so buildmode=pie works? 2016-07-07 08:34:36 fabled: yes 2016-07-07 08:34:36 <^7heo> fabled: looks like so 2016-07-07 08:34:36 we need to make that the default in go 2016-07-07 08:34:36 <^7heo> yep 2016-07-07 08:34:39 <^7heo> also 2016-07-07 08:34:45 ping? :D 2016-07-07 08:34:50 <^7heo> we need more and better testing 2016-07-07 08:34:57 :) 2016-07-07 08:34:58 <^7heo> moin mosez 2016-07-07 08:35:05 i thought this counts as testing 2016-07-07 08:35:12 edge is allowed to break a little bit at times ;) 2016-07-07 08:35:16 and you should also avoid binary stripping for tools built with go *hint* 2016-07-07 08:35:17 fabled: yes default seems sane. 2016-07-07 08:35:21 <^7heo> fabled: nope. travis does 2016-07-07 08:35:28 <^7heo> fabled: CI does 2016-07-07 08:36:07 <^7heo> spending evenings and mornings to fix stuff with gcc and go doesn't 2016-07-07 08:36:08 to ensure this would not happen it means we would need to build *all* packages with any single change 2016-07-07 08:36:16 <^7heo> no 2016-07-07 08:36:19 <^7heo> just deps 2016-07-07 08:36:22 well 2016-07-07 08:36:24 changing gcc 2016-07-07 08:36:27 means all 2016-07-07 08:36:30 <^7heo> yeap gcc yes 2016-07-07 08:36:39 it's a novel goal 2016-07-07 08:36:45 but i think it's not so simple to achieve 2016-07-07 08:36:45 <^7heo> but we don't change gcc that often so 2016-07-07 08:36:54 <^7heo> let's see 2016-07-07 08:37:13 <^7heo> if we have better testong on the ml than gh 2016-07-07 08:37:26 <^7heo> that would be ace 2016-07-07 08:37:32 <^7heo> testing* 2016-07-07 08:37:40 this is where balance is needed; going forward or using time to make sure nothing breaks 2016-07-07 08:37:49 <^7heo> now, REALLY, bbl 2016-07-07 08:37:51 time is a limited resource 2016-07-07 08:37:52 <^7heo> o/ 2016-07-07 08:37:58 but yeah 2016-07-07 08:38:04 breakage like this is bound to happen 2016-07-07 08:38:09 and it happens on other distros too 2016-07-07 08:38:21 ttyl 2016-07-07 08:39:18 fabled: did you make up your mind regarding the choice of aarch64 and ssl? 2016-07-07 08:40:07 ncopa, i'll push http://sprunge.us/iRUU unless you object 2016-07-07 08:40:23 clandmeter, not yet. aarch64 might be simple now with all updated gcc and fixed bootstrap scripts 2016-07-07 08:40:59 do we have any specs on the board? to see how kernel should be configured 2016-07-07 08:41:10 and need to research a bit to see how to tune gcc 2016-07-07 08:41:17 but those should be pretty straightforward things 2016-07-07 08:42:16 yes i have some docs 2016-07-07 08:43:21 fabled: let me gather them and provide you a link to it. 2016-07-07 08:43:39 looks good for go: http://sprunge.us/XYMT ? 2016-07-07 08:44:13 i think we can drop the no-pie patch too? 2016-07-07 08:44:45 ill pm you the details. I'm not sure which of them can be published or kept confidential. 2016-07-07 08:45:32 http://sprunge.us/VWCQ 2016-07-07 08:47:47 hmm : fails with invalid value "pie" for flag -buildmode: buildmode pie not supported on darwin/386 2016-07-07 08:51:39 thats for the cross compiler? 2016-07-07 08:52:42 ncopa: how do I find packages I need to rebuild due to soname change? I usually grep for foobar-dev in makedeps but I guess you know better way 2016-07-07 08:53:14 apk search -q -r --exact so:liboldname.so.0 2016-07-07 08:53:38 thx 2016-07-07 08:55:16 new suggested go patch: http://sprunge.us/FVXN ; test building now 2016-07-07 08:55:47 ncopa, is the abuild arch="all !x86_64" patch ok? 2016-07-07 09:00:02 looks ok 2016-07-07 09:00:19 maybe add a comment with the example 2016-07-07 09:00:31 as its not clear why we need then !$CARCH 2016-07-07 09:00:52 to the commit comment? 2016-07-07 09:01:08 it's there in the heading 2016-07-07 09:01:18 to the abuild fix 2016-07-07 09:01:47 got patch looks good to me 2016-07-07 09:01:55 ncopa, http://sprunge.us/iRUU 2016-07-07 09:02:41 oh thats better 2016-07-07 09:03:01 i like that 2016-07-07 09:03:03 push that 2016-07-07 09:03:07 i guess you were reading the wrong sprunge ;) 2016-07-07 09:03:12 yeah 2016-07-07 09:03:22 probably the first version 2016-07-07 09:03:37 i am annoyed with glib devs 2016-07-07 09:03:58 first they do insane things for "portability" reasons, like gbooelan gchar 2016-07-07 09:04:06 gchar? 2016-07-07 09:04:07 <^7heo> fabled: why !x86_64? 2016-07-07 09:04:10 why gchar? 2016-07-07 09:04:13 makes no sense 2016-07-07 09:04:24 <^7heo> fabled: I thought x64 was th issue 2016-07-07 09:04:33 ^7heo, that's for entirely different issue 2016-07-07 09:04:39 then they happily sacrifice portability for a *microoptimization* 2016-07-07 09:04:43 <^7heo> oh k 2016-07-07 09:05:04 and say: "since musl dont order the ctors we dont want support musl" 2016-07-07 09:05:10 <^7heo> fabled: can't open all links, I'm usong 2g 2016-07-07 09:05:31 heh. yeah, many things happening at same time 2016-07-07 09:05:44 <^7heo> yeah. at least it's active 2016-07-07 09:05:51 go test build almost done 2016-07-07 09:05:55 i think the pie patch is good 2016-07-07 09:06:01 will push soon 2016-07-07 09:06:08 <^7heo> good 2016-07-07 09:06:12 to avoid make an extra if (G_UNLIKELY(ptr == NULL)) check in a performance critical code path 2016-07-07 09:06:53 which also happen inside a mutex lock 2016-07-07 09:07:02 <^7heo> ncopa: can't check now if you pushed, but was my nlplug patch ok? 2016-07-07 09:07:07 i dont think the extra performance cost can be measured 2016-07-07 09:07:18 ^7heo: will look at it soon 2016-07-07 09:07:26 <^7heo> oh ok 2016-07-07 09:07:39 i need fix glib first, ScrumpyJack's rawtherapee problem 2016-07-07 09:07:46 and then i'll fix wget CVE 2016-07-07 09:07:49 <^7heo> ok ok 2016-07-07 09:08:06 ScrumpyJack: do you use v3.4 or edge? i believe the issue is currently fixed in edge 2016-07-07 09:08:15 but i'll backport it to v3.4 2016-07-07 09:08:40 ncopa: http://patchwork.alpinelinux.org/patch/2120/ opinion on this? please ignore _builddir and prepare() 2016-07-07 09:10:59 barthalion: i'm okish with it 2016-07-07 09:10:59 but 2016-07-07 09:11:02 hum 2016-07-07 09:11:37 i dont think we need to patch the source to set the user/group since they support the --user and --group args 2016-07-07 09:11:40 ncopa: I see the problem in edge 2016-07-07 09:11:41 better use those 2016-07-07 09:12:10 ncopa: okay, will tell that to Valery 2016-07-07 09:12:27 barthalion: the thinking is, dont patch unless needed 2016-07-07 09:12:46 i'm a bit sceptic to the DBUS_LIBS removal too 2016-07-07 09:13:20 i havent checked the sources but if dbus is autodetected unless the DBUS_LIBS and DBUS_CLFAGS is cleared, then i want keep those 2016-07-07 09:13:43 so we dont build with dbus suport by mistake 2016-07-07 09:15:07 and i would prefer to patch the dnsmasq.conf.example instead of sed'ing it 2016-07-07 09:15:33 thanks 2016-07-07 09:15:56 ScrumpyJack: what does `apk version glib` say? 2016-07-07 09:16:03 not sure if I agree about sed, but I see your point 2016-07-07 09:18:35 barthalion: i dont have strong opinion on it though 2016-07-07 09:18:41 so i'm ok with the sed too 2016-07-07 09:19:13 reason is that i want detect if upstream changes the default 2016-07-07 09:20:27 yeah, I know 2016-07-07 09:24:52 ncopa: btw, testing is set to blocking mode in builders, should it be changed? 2016-07-07 09:26:02 <^7heo> ncopa: do you have a daily job also? 2016-07-07 09:26:09 <^7heo> ncopa: or is alpine your daily job? 2016-07-07 09:29:03 ^7heo: i have daily job. alpine is a part of it 2016-07-07 09:39:22 <^7heo> ncopa: that's great :) 2016-07-07 09:39:38 <^7heo> we're lucky it works this way 2016-07-07 09:56:00 ScrumpyJack: does glib-2.48.1-r1 work? 2016-07-07 10:06:19 ncopa: upgrading at the mo 2016-07-07 11:06:49 ncopa: rawtherapee loads after upgrade 2016-07-07 11:07:05 good! 2016-07-07 11:07:16 i'll backport that to 3.4 then 2016-07-07 11:07:17 thanks! 2016-07-07 11:12:40 seems to go failure on x86 is https://github.com/termux/termux-packages/issues/217 2016-07-07 11:13:20 fixed in 1.7 beta2 2016-07-07 11:13:26 but no pointer to what change 2016-07-07 11:14:06 possible caused by the pie change 2016-07-07 11:14:12 seems the issue above also used pie mode 2016-07-07 11:28:05 <^7heo> the gcc upgrade is breaking a lot of stuff, isn't it? 2016-07-07 11:30:53 packaging on rpm based systems is so damn complicated -.- 2016-07-07 11:36:32 <^7heo> I'm having fun imagining a guy working on RPM while he likes alpine 2016-07-07 11:40:49 alpine == spare time, rpm == paid time :D 2016-07-07 11:47:28 <^7heo> yeah I know 2016-07-07 11:47:33 <^7heo> I hope they pay good. 2016-07-07 12:11:29 anyone uses lxd here? 2016-07-07 12:14:38 planning to git it a spin :( 2016-07-07 12:14:46 s/git/give 2016-07-07 12:15:17 i am also planing to svn it a spin 2016-07-07 12:15:26 s/svn/give 2016-07-07 12:15:26 lol 2016-07-07 12:16:21 there's a reason why we don't have lxc ugpraded to 2.0.1? 2016-07-07 12:16:21 leo-unglaub is planing? far out! :) 2016-07-07 12:17:11 ;) 2016-07-07 12:17:40 fcolista: no, no one bumped it 2016-07-07 12:18:06 barthalion, u sure of that? I mean: 1.1.5 is out since nov 2015 2016-07-07 12:18:44 let's ask the source of truth 2016-07-07 12:18:51 ncopa: ^ 2016-07-07 12:23:46 New features 2016-07-07 12:23:46 API: 2016-07-07 12:23:46 API version is 1.2, fully backward compatible with 1.1 and 1.0 2016-07-07 12:23:56 looks that is retro-compatible with 1.1 2016-07-07 12:24:10 The C API remains backward compatible with previous versions and is released as 1.2 2016-07-07 12:26:02 "Note that several commands have been significantly reworked in this release ... test and apapt your scripts ... " 2016-07-07 12:26:17 typo mine 2016-07-07 12:26:46 alpine template might not work 2016-07-07 12:29:18 perhaps we can build an LXC2 package? 2016-07-07 12:30:36 I use lxc on my Arch laptop and it runs Alpine template just fine 2016-07-07 12:30:59 barthalion, do you have lxc 2 in the host? 2016-07-07 12:31:00 please dont introdcure lxc2 2016-07-07 12:31:07 lxc should just work 2016-07-07 12:31:10 let's just update it 2016-07-07 12:31:14 fcolista: yes 2016-07-07 12:31:25 clandmeter, +1 2016-07-07 12:31:30 no lxc2 package 2016-07-07 12:33:11 builds just fine with http://tpaste.us/GBDy 2016-07-07 12:34:03 <^7heo> clandmeter: gogs-0.9.13 present on the repos. 2016-07-07 12:34:04 <^7heo> clandmeter: \p/ 2016-07-07 12:34:07 <^7heo> \o/* 2016-07-07 12:34:12 clandmeter: cool. can you push it? 2016-07-07 12:34:12 ^7heo: :) 2016-07-07 12:34:22 <^7heo> clandmeter: thanks for your help fixing it 2016-07-07 12:34:29 <^7heo> clandmeter: it would have been much slower without you. 2016-07-07 12:34:32 ^7heo: btw, nl is not master repo anymore. 2016-07-07 12:34:36 <^7heo> oh 2016-07-07 12:34:37 <^7heo> ok 2016-07-07 12:34:41 <^7heo> the dl-cdn is? 2016-07-07 12:34:46 kind of 2016-07-07 12:34:49 its not master mirror 2016-07-07 12:34:56 but we prefer users use it intead. 2016-07-07 12:35:00 <^7heo> nl? 2016-07-07 12:35:05 as it should be the fastest 2016-07-07 12:35:08 <^7heo> yeah 2016-07-07 12:35:09 <^7heo> totally 2016-07-07 12:35:11 <^7heo> here too 2016-07-07 12:35:17 <^7heo> I should setup a mirror in Berlin tho 2016-07-07 12:35:23 no nl is just an mirror like others 2016-07-07 12:35:37 <^7heo> I always forget the location of mirrors 2016-07-07 12:35:42 fr.a.o is master now. its on scaleway 2016-07-07 12:35:47 also, lxd either needs cgmanager as a dependancy or remove meed cgmanager from init script 2016-07-07 12:35:50 <^7heo> fr?! 2016-07-07 12:35:51 <^7heo> wow. 2016-07-07 12:35:55 <^7heo> that was unexpected. 2016-07-07 12:36:07 <^7heo> is this skarnet's doing? :P 2016-07-07 12:36:21 scaleway sponsors some infra for us. 2016-07-07 12:36:30 <^7heo> oh cool 2016-07-07 12:37:16 <^7heo> I wonder if they have terraform support 2016-07-07 12:38:24 ScrumpyJack, what's the problem in having cgmanager as dependency? 2016-07-07 12:38:52 nothing. that dependancy isnt met! 2016-07-07 12:39:23 lxd init script requires cgmanager 2016-07-07 12:39:28 ok 2016-07-07 12:39:40 yet cgmanager isn't a dependency of lxd 2016-07-07 12:39:54 <^7heo> my apk is behaving weird. 2016-07-07 12:40:11 <^7heo> apk version returns '?' for available 2016-07-07 12:40:17 <^7heo> but apk search shows the right version 2016-07-07 12:40:24 <^7heo> apk upgrade returns without doing anything 2016-07-07 12:40:30 ScrumpyJack, http://sprunge.us/iTJB 2016-07-07 12:40:32 better now? 2016-07-07 12:41:24 try again 2016-07-07 12:41:49 i mean, check your output :) 2016-07-07 12:41:53 yeah :) 2016-07-07 12:42:05 http://sprunge.us/EUaZ 2016-07-07 12:45:38 also the lxd init script seems to mount the name cgroup systemd. is that right? 2016-07-07 12:45:51 ScrumpyJack: can you try new lxc? 2016-07-07 12:45:56 yes 2016-07-07 12:46:08 check if your containers start properly 2016-07-07 12:46:27 i remember with previous version bump, we have to fix some configs. 2016-07-07 12:46:33 and see if you can create a new container. 2016-07-07 12:46:36 /nick Guinea-pigJack 2016-07-07 12:47:34 <^7heo> do you want a small cage with a wheel? 2016-07-07 12:47:45 can you give me a url for the new package if you've built it locally? 2016-07-07 12:47:56 ScrumpyJack: its on the mirror now 2016-07-07 12:48:06 try fr.a.o for latest pkg 2016-07-07 12:48:20 ScrumpyJack: 2016-07-07 12:48:20 aports:master |Carlo Landmeter| main/lxc: upgrade to 2.0.1 | http://dup.pw/aports/5177ae92 2016-07-07 12:48:30 btw clandmeter, there's 2.0.3 2016-07-07 12:48:38 huh? 2016-07-07 12:48:39 it's not on my mirror yet, and was hoping not to have to browse (no X11 here) 2016-07-07 12:48:57 ok, I'll wait for 2.0.3 :) 2016-07-07 12:48:59 ScrumpyJack: then your mirror syncs every X minutes 2016-07-07 12:49:07 ok ill bump it to .3 2016-07-07 12:49:13 didnt know it was already as .3 2016-07-07 12:49:16 yes 2016-07-07 12:49:28 https://linuxcontainers.org/downloads/lxc/lxc-2.0.3.tar.gz 2016-07-07 12:49:32 https://linuxcontainers.org/lxc/downloads/ 2016-07-07 12:49:43 clandmeter: yes, hourly 2016-07-07 12:52:28 ScrumpyJack: apk add -X http://fr.alpinelinux.org/alpine/edge/main lxc 2016-07-07 12:52:31 should work now 2016-07-07 12:53:00 ah no, it takes from local cache, forget it. 2016-07-07 12:53:23 ill crawl back into my cave now. 2016-07-07 13:06:06 <^7heo> is the -X option in apk broken? 2016-07-07 13:06:10 <^7heo> or do I use it wrong? 2016-07-07 13:08:57 ^7heo: it first need an index update i think, so maybe add -U? 2016-07-07 13:09:01 i never use it like this. 2016-07-07 13:09:23 <^7heo> clandmeter: yeah I try to know why I can't apk upgrade anything 2016-07-07 13:09:28 <^7heo> even tho there are new versions for packages. 2016-07-07 13:10:33 apk add -U -X http://fr.alpinelinux.org/alpine/edge/main 2016-07-07 13:10:42 then apk add -X http://fr.alpinelinux.org/alpine/edge/main lxc 2016-07-07 13:11:22 i think that should work as a single liner 2016-07-07 13:11:25 Error relocating /usr/bin/lxc-create: is_valid_bdev_type: symbol not found 2016-07-07 13:11:31 <^7heo> ScrumpyJack: I just want to search 2016-07-07 13:11:33 <^7heo> http://ix.io/11hQ 2016-07-07 13:11:37 <^7heo> that's what I get ^ 2016-07-07 13:11:53 <^7heo> the only thing I want is to see in what repo my packages are coming from 2016-07-07 13:12:04 <^7heo> the exact equivalent to apk-cache madison on debian 2016-07-07 13:12:34 its wrong version 2016-07-07 13:12:39 3.2 should be v3.2 2016-07-07 13:12:46 <^7heo> ah 2016-07-07 13:12:59 <^7heo> same output. 2016-07-07 13:13:13 <^7heo> (minus the error) 2016-07-07 13:14:33 would someone like to upgrade go to 1.7beta2 ? it should fix the x86 build issue 2016-07-07 13:15:13 ^7heo: apk search -X repo aport 2016-07-07 13:15:28 <^7heo> ScrumpyJack: what do you think I'm trying to do? :) 2016-07-07 13:16:09 you're doing apk -U -X repo search aport right? 2016-07-07 13:16:19 <^7heo> I have tried every combination of apk -X repo search aport and apk search -X repo aport 2016-07-07 13:16:24 <^7heo> with and without -U 2016-07-07 13:17:02 do it in two steps: a) apk -U -X repo b) apk search -X repo aport 2016-07-07 13:17:03 <^7heo> the output is always the version I have in my /etc/apk/repositories 2016-07-07 13:17:12 <^7heo> ok 2016-07-07 13:17:16 it works for me 2016-07-07 13:18:01 why not remove the repo's from your repo file? 2016-07-07 13:18:10 and add the fr.a.o ones. 2016-07-07 13:18:20 <^7heo> ScrumpyJack: just to be clear 2016-07-07 13:18:32 <^7heo> what's the first applet for your first apk command? 2016-07-07 13:18:41 <^7heo> because apk -U -X repo doesn't work here 2016-07-07 13:18:49 sorry, add 2016-07-07 13:18:52 <^7heo> ah 2016-07-07 13:19:36 <^7heo> so for example 2016-07-07 13:19:39 <^7heo> sudo apk add -U -X http://fr.alpinelinux.org/alpine/v3.3/main/ && apk search -X http://fr.alpinelinux.org/alpine/v3.3/main/ util-linux 2016-07-07 13:20:04 <^7heo> is supposed to show util-linux-2.27.1-r0 right? 2016-07-07 13:20:26 yes, although that also seems to return what in index from other repos 2016-07-07 13:20:53 <^7heo> because I get util-linux-2.28-r4 2016-07-07 13:21:02 <^7heo> so... yeah, doesn't work. 2016-07-07 13:21:06 <^7heo> how do you get it to work? 2016-07-07 13:24:36 nope, I've got nothing :( 2016-07-07 13:24:36 <^7heo> because I really would like to understand why apk doesn't show me the availble versions with version but does with serarch 2016-07-07 13:24:39 <^7heo> search* 2016-07-07 13:25:28 clandmeter: lxc-create errors: Error relocating /usr/bin/lxc-create: is_valid_bdev_type: symbol not found 2016-07-07 13:25:55 hmm 2016-07-07 13:26:54 works here 2016-07-07 13:27:02 ScrumpyJack: are you mixing repo's? 2016-07-07 13:33:18 edge only 2016-07-07 13:33:31 does it work for you? 2016-07-07 13:33:43 when does it happen? 2016-07-07 13:33:49 lxc-create --help already? 2016-07-07 13:34:18 lxc-create 2016-07-07 13:35:20 fabled: if tomorrow morning works for you, I can 2016-07-07 13:35:54 ScrumpyJack: --help --version both work for me. 2016-07-07 13:36:10 clandmeter: lxc-attach is also broken Error relocating /usr/bin/lxc-attach: lxc_console_sigwinch_fini: symbol not found 2016-07-07 13:36:17 are you in edgE? 2016-07-07 13:36:21 of course 2016-07-07 13:36:27 its my builder 2016-07-07 13:37:36 can you apk -U upgrade ? 2016-07-07 13:37:56 ah, i upgraded this morning. didn't check what libs upgraded. I'll reboot :( 2016-07-07 13:38:08 reboot? :) 2016-07-07 13:38:17 its not windows 2016-07-07 13:39:18 new kernel? 2016-07-07 13:39:29 has nothing to do with the kernel 2016-07-07 13:39:33 its all userspace 2016-07-07 13:39:40 some lib is not updated i think 2016-07-07 13:39:47 perhaps i have a new kernel anyway :) 2016-07-07 13:40:29 it works at my end, so i guess its ok. 2016-07-07 13:40:44 just dont know it its compat with 1.x installs 2016-07-07 13:40:55 my lxc boxes are running stable. 2016-07-07 13:41:08 ncopa: any reason you were holding lxc back to 1.x? 2016-07-07 13:43:04 ok, got it. lxc-libs are olders one 2016-07-07 13:45:02 what a mess 2016-07-07 13:47:08 fabled: actually will do that now 2016-07-07 13:47:17 clandmeter: right, it works now 2016-07-07 13:47:25 barthalion, thanks! 2016-07-07 13:48:45 clandmeter: scratch that :( 2016-07-07 13:54:30 i can't start a container with lxc2, old or new 2016-07-07 13:59:09 for go projects that don't vendor their deps, should i create a vendor.tgz and make it part of the package? 2016-07-07 14:00:07 ncopa: and can you enable other arches for terraform again? for me it builds fine on arm and x86_64 2016-07-07 14:05:33 ok to submit the patch for hugo here? http://sprunge.us/PbWJ 2016-07-07 14:10:31 http://sprunge.us/JGfX fixed indention for hugo package... 2016-07-07 14:12:05 mosez: second patch has different checksum 2016-07-07 14:12:15 first patch checksum works, second does not 2016-07-07 14:12:57 hum 2016-07-07 14:12:59 thats weird 2016-07-07 14:14:32 i know why 2016-07-07 14:14:48 indentation changed in checksum too 2016-07-07 14:16:01 why ppl loves so much go? 2016-07-07 14:16:12 because its hip 2016-07-07 14:16:30 for programmer go is easier than c or c++ 2016-07-07 14:16:47 though, i think rust and nimrod are probably better for me 2016-07-07 14:16:53 but i guess go has it's large user base too 2016-07-07 14:17:00 it has 2016-07-07 14:17:08 and there are tons of libs etc 2016-07-07 14:17:10 but 2016-07-07 14:17:13 it does not scale 2016-07-07 14:17:20 grrr... why did it change the checksum 2016-07-07 14:17:31 works good if you maintain 10 pakcages 2016-07-07 14:17:35 well 2016-07-07 14:17:41 works good i fyou maintain 1-2 2016-07-07 14:17:50 ah...that's it 2016-07-07 14:18:00 if you maintain 10 it works but probably not so fun 2016-07-07 14:18:09 if you mainain 100 you have serious problem 2016-07-07 14:18:11 maintain go packages is demanding 2016-07-07 14:18:23 so i enjoy working with go except the dependency management :) 2016-07-07 14:18:37 1000 go projects is not possible to maintain 2016-07-07 14:18:42 ncopa: should i give you another patch that fixes indention AND checksums? 2016-07-07 14:18:54 mosez: nah, i think i got it 2016-07-07 14:18:59 ncopa: thanks 2016-07-07 14:19:32 go is not designed to be used with traditional distro packaging 2016-07-07 14:19:47 its designed for you to provide you own binaries 2016-07-07 14:20:01 google just don't care about it 2016-07-07 14:20:04 and let user download precompiled binary from the author 2016-07-07 14:21:20 i know 2 years ago on FOSDEM i asked one of the main authors for proper dependency management... he said it works like it is perfectly for google internally, so they have no plans to change it. 2016-07-07 14:21:33 ... 2016-07-07 14:21:42 a good reason for stop to using it 2016-07-07 14:22:09 in the meantime the pressure increased and they introduced the vendoring of dependencies. but no tool from them so everybody takes a different tool for that. 2016-07-07 14:23:12 but i like the language itself. and i'm earning money with that... rust is also interesting but there is nothing paid in germany... 2016-07-07 14:23:13 in testing we have 16 packages with GO 2016-07-07 14:23:20 in community, 10 2016-07-07 14:23:34 3 of them are maintained by me :D 2016-07-07 14:23:36 so far, a total of 26 packages to maingain 2016-07-07 14:23:42 well done mosez... 2016-07-07 14:23:48 kepp up the good work :) 2016-07-07 14:23:52 *kep 2016-07-07 14:24:15 when next sec issue shows up we'll have to rebuild all 26 2016-07-07 14:24:29 for all 4 matinained banches 2016-07-07 14:24:31 will 2016-07-07 14:24:33 well 2016-07-07 14:24:40 105 2016-07-07 14:24:42 for 1 stable branch + edge 2016-07-07 14:24:42 104 2016-07-07 14:24:53 thats why we dont provide long time support for those 2016-07-07 14:24:55 so, 52 2016-07-07 14:25:03 36 2016-07-07 14:25:12 stable doesn't have testing? 2016-07-07 14:25:16 Right 2016-07-07 14:25:18 that's why 2016-07-07 14:25:18 currect 2016-07-07 14:25:28 the rise of bundled dependencies and language-specific package manager is an obvious sign of traditional distributions' failures to handle software dependencies correctly 2016-07-07 14:25:48 language authors and various vendors need to provide stuff that works no matter the distro 2016-07-07 14:25:53 that's why they adopt this bonkers model 2016-07-07 14:26:10 they also dont want wait til next distro release to get their stuff out 2016-07-07 14:26:11 but honestly, if the distro landscape wasn't so fragmented and clueless, they wouldn't need to do that 2016-07-07 14:26:35 well, look at Debian: 6 years to release a stable version 2016-07-07 14:26:46 so yeah, I can understand they don't want to wait :P 2016-07-07 14:26:50 :) 2016-07-07 14:27:19 i think that apple tracked the road: all static libs. A big package with all-in. 2016-07-07 14:27:26 you don't care about the installation 2016-07-07 14:27:33 just simple drag n'drop 2016-07-07 14:27:38 the problem is, distros that do stuff _almost_ correctly (I'm looking at you Alpine) also suffer from that evolution towards bundling 2016-07-07 14:27:53 then, no matter that you wast GBs . 2016-07-07 14:28:19 fcolista: yeah, bundling - iow, we can't make dependencies work so let's just provide everything 2016-07-07 14:28:34 Users are happy: no difficult in installatinon. Vendors are happy: sell bigger disk 2016-07-07 14:28:45 developers are happy: it "just work" 2016-07-07 14:28:47 not all users are happy, tyvm 2016-07-07 14:28:57 no power-users. 2016-07-07 14:28:59 users. 2016-07-07 14:29:12 -> dumbing down of Unix 2016-07-07 14:29:21 separation between "vendors" and "consumers" 2016-07-07 14:29:39 and proprietarization of knowledge. 2016-07-07 14:50:02 clandmeter: can you hold up on pushing lxc 2.0.3? 2016-07-07 14:51:50 ScrumpyJack: ? 2016-07-07 14:51:53 its alraedy pushed 2016-07-07 14:59:33 i think we were hasty there. for me: lxc-start seg faults with -F switch and lxc-create -t alpine fails 2016-07-07 14:59:38 gtg 2016-07-07 15:04:50 ncopa: any reason you were holding back lxc update? 2016-07-07 16:35:09 ncopa, are you here? 2016-07-07 18:11:37 is there currently someone who knows LLVM well? 2016-07-07 18:16:41 I'm fairly sure someone at Apple does! 2016-07-07 18:18:47 or google 2016-07-07 18:28:58 skarnet: could you please look at https://gist.github.com/japaric/52b8816a4c86f5a4699bcc50ebc3e020, just for a chance that there’s some obvious problem that you will instantly recognize 2016-07-07 18:32:18 hmmm, not sure that's related to the problem, but GregorR's musl-cross is pretty much obsoleted by dalias's musl-cross-make tool, which is maintained with the latest versions of musl 2016-07-07 18:32:30 I'd use that to make a C++ toolchain 2016-07-07 18:33:44 apart from that, what's that apt-get install thing? I don't know any such command :P 2016-07-07 18:34:36 and the rest is rust/llvm stuff I definitely can't help with 2016-07-07 18:34:37 skarnet: good perception, I’ll write him that he uses deprecated version of musl-cross 2016-07-07 18:34:59 skarnet: ah, that’s just some weird command from Ubuntu, they uses it to install packages or something like that :P 2016-07-07 18:35:08 skarnet: just ignore it and imagine apk add instead of it :) 2016-07-07 18:35:15 oh, yeah, never build on Ubuntu, ever 2016-07-07 18:35:22 their coreutils are patched and nonstandard 2016-07-07 18:35:29 skarnet: lucky men, Ubuntu is really crap 2016-07-07 18:35:37 for instance, "su" doesn't do what it's supposed to 2016-07-07 18:36:17 what does it do on Ubuntu? 2016-07-07 18:36:24 yes it is, even crappier than other mainstream distros. When I made my bootstrap scripts, Ubuntu is the distro that gave me the most headaches. 2016-07-07 18:36:54 on Ubuntu, "su" without "-p" still preserves env vars it's not supposed to 2016-07-07 18:37:31 so a script that assumes the coreutils/busybox/suckless behaviour will fail 2016-07-07 18:38:01 you have to actually empty PATH or HOME or whatever that is after performing the su, if you want it to be cleared 2016-07-07 18:38:24 and that's just one of many, many problems with Ubuntu 2016-07-07 18:38:34 I think that nothing works as it should on Ubuntu 2016-07-07 18:42:55 skarnet: where can I find dalias’ musl-cross-make tool? I found just https://github.com/richfelker/musl-cross-make 2016-07-07 18:45:29 jirutka: yup, that's it 2016-07-07 18:45:54 thanks 2016-07-07 20:24:01 anyone knows if "a2enmod" is still part of apache2 ? 2016-07-07 20:24:35 or it should be pkged but not done, add to bugs.a.o ? 2016-07-07 20:26:00 oh ! its debian scripts 2016-07-07 22:15:22 vkris: yeah, a2enmod is a debian strict and totally useless 2016-07-08 08:26:03 okay 2016-07-08 08:26:20 minimal userland bootstrap for both armv7 and aarch64 works: http://sprunge.us/AKVj 2016-07-08 08:26:39 $ du -csh packages-a* 2016-07-08 08:26:39 165.8M packages-aarch64-alpine-linux-musl 2016-07-08 08:26:39 137.8M packages-armv7-alpine-linux-muslgnueabihf 2016-07-08 08:26:39 303.6M total 2016-07-08 08:26:58 still needs kernels 2016-07-08 08:35:09 nice 2016-07-08 08:35:52 need to also remember / figure out how to do the first boot image 2016-07-08 08:36:07 and find out how aarch64 boot sequence works 2016-07-08 08:37:58 im not really understand this box network configuration. 2016-07-08 08:38:19 it gets an ip assingment from uboot or something. 2016-07-08 08:38:27 but it also gets an ip from dhcp 2016-07-08 08:41:25 <^7heo> ncopa: nlplug-findfs leaks /dev/urandom or /dev/random on lvm invocation here 2016-07-08 08:41:32 <^7heo> not sure how easy this is to fix 2016-07-08 08:41:41 missing CLOEXEC ? 2016-07-08 08:41:41 <^7heo> (I have lvm over cryptfs) 2016-07-08 08:41:54 <^7heo> fabled: I dunno, I just read the logs 2016-07-08 08:42:02 <^7heo> It is happening for ages; but I ignored them so far 2016-07-08 10:24:37 lxc 2.0.3 build doesn't work in alpine-grsec. 2016-07-08 11:20:51 i'm thinking how our build stuff should work... 2016-07-08 11:20:56 my vision is something like http://sprunge.us/LefO 2016-07-08 11:21:16 i wonder if there's interest getting that done; or perhaps some existing software that we could use 2016-07-08 11:21:44 i think most of the above has been discussed throught the months, but i tried to collect everything together now 2016-07-08 11:41:03 back in 30mins or so 2016-07-08 12:21:54 gcc6 fails to build firefox-esr: http://sprunge.us/AeBX 2016-07-08 12:23:12 seems like there are a patch: https://bugs.archlinux.org/task/49243 2016-07-08 12:34:16 <^7heo> so gcc6 is making everyone work twice as much this week? 2016-07-08 13:05:07 yeah, I'm having trouble with gcc-6 too. 2016-07-08 13:05:21 Trying to isolate a minimal failure case before reporting here. 2016-07-08 13:05:27 seems it's almost always like that with new gcc 2016-07-08 13:05:28 :/ 2016-07-08 13:05:48 but often it's just a warning and people using -Werror 2016-07-08 13:05:55 but new errors creep in too 2016-07-08 13:05:57 not here 2016-07-08 13:17:00 I have problems to successfully build some patches from patchwork since upgrade either 2016-07-08 13:17:11 from people that know their shit when it comes to packaging 2016-07-08 13:17:28 so yeah, everyone enjoy the new gcc week(s) 2016-07-08 13:18:06 clandmeter: around ? 2016-07-08 13:18:32 suggestion - add new column in table 'files' i.e 'category' 2016-07-08 13:18:32 files => id|file|path|pkgname|pid|category 2016-07-08 13:18:32 category(value) = numeric representation for branch:repo:arch 2016-07-08 13:18:38 fabled: separate tool for creating repo indices/repo management should be on that list 2016-07-08 13:18:52 eg. edge=9900 main=10 x86_64=20 = 99001020 v3.4=340 main=20 x86=10 = 3402010 2016-07-08 13:18:55 this method can also be applied in areas other than pkg db 2016-07-08 13:18:58 ncopa: are you here? 2016-07-08 13:19:07 hi 2016-07-08 13:19:11 eg. edge=9900 main=10 x86_64=20 = 99001020 2016-07-08 13:19:11 eg. v3.4=340 main=20 x86=10 = 3402010 2016-07-08 13:19:15 fabled: I wouldn't mind possibility to sign the package as separate step, without abuild 2016-07-08 13:19:51 jirutka: https://lwn.net/SubscriberLink/692704/7562df1d5c5ac6c8/ 2016-07-08 13:19:57 yes, i'd like to make the signing part of apk-tools. either as implicit or explicit step 2016-07-08 13:20:43 barthalion: Sphinx, really?! omg :/ 2016-07-08 13:20:45 fabled: so with these two things I mentioned I'd be the happiest man on this channel 2016-07-08 13:21:08 jirutka: yeah, but there is some rationale behind this, and as you probably remember, I don't share your hatred to rst 2016-07-08 13:21:16 I mean, I don't care, just another markup language 2016-07-08 13:21:24 barthalion: I’ll read it later… 2016-07-08 13:21:26 sure 2016-07-08 13:21:42 just wanted you to know :P 2016-07-08 13:21:53 barthalion: thanks… I’m sad now… 2016-07-08 13:23:53 that wasn't my intention, sorry 2016-07-08 13:24:02 I was probably as surprised as you reading this in the morning 2016-07-08 13:24:50 nevermind, I should finally get used to the fact that in history the worst solutions quite often wins… 2016-07-08 13:25:40 barthalion: well, to be fair, it’s still better decision than Markdown, *for this purpose*, but… 2016-07-08 13:28:55 ncopa: I fixed pypi URLs in all abuilds, it’s prepared in https://github.com/alpinelinux/aports/pull/148, https://github.com/alpinelinux/aports/pull/149 and https://github.com/alpinelinux/aports/pull/150; it modifies hundreds of abuilds, so I’d rather to ask if it’s okay before merging it 2016-07-08 13:29:55 ncopa: CI failed because few packages are broken (not due to URL change) and there are too many packages in testing, so it exceeded travis limit 2016-07-08 13:29:59 added files search using api.a.o , http://pkgstest.alpinelinux.org/contents.html :) 2016-07-08 13:30:32 vkris: what do you mean with “using api.a.o”? 2016-07-08 13:31:29 its js based and calls jsonapi objects from api.alpinelinux.org 2016-07-08 13:31:48 code - https://github.com/insteps/aports-ui 2016-07-08 13:31:58 vkris: aha 2016-07-08 13:32:05 can you access it ? 2016-07-08 13:33:08 vkris: could you please use ES 2015 instead of legacy JS and adhere to commonly accepted code-style…? 2016-07-08 13:33:26 docs urls pls ? 2016-07-08 13:33:49 vkris: docs for what? 2016-07-08 13:34:14 but remember its testbed for api.a.o testing 2016-07-08 13:34:31 there would be a php version 2016-07-08 13:34:38 js version is not going live 2016-07-08 13:34:46 vkris: so it will not replace the current pkgs.a.o? ok they 2016-07-08 13:35:04 there is also http://pkgstest.alpinelinux.org/packages.html 2016-07-08 13:35:07 vkris: you want to rewrite pkgs.a.o to PHP?! 2016-07-08 13:35:37 open to suggestion ? lua ? 2016-07-08 13:35:51 java ? 2016-07-08 13:35:57 vkris: IIRC the current version is written in Lua 2016-07-08 13:36:12 yes, code is maintained by clandmeter 2016-07-08 13:36:34 https://github.com/clandmeter/aports-turbo 2016-07-08 13:37:46 jirutka: i think it would be nice if you every of those packages also did: abuild cleancache checksum 2016-07-08 13:37:48 vkris: Alpine is about simplicity, security and correctness, PHP is total opposite of these… 2016-07-08 13:37:59 so we get new checksum for them 2016-07-08 13:38:08 ncopa: the checksums are unchanged 2016-07-08 13:38:12 ok 2016-07-08 13:38:17 then pushit 2016-07-08 13:38:24 hmmm... suggestions ? 2016-07-08 13:39:23 ncopa: I was quite afraid that tarballs from the new site will have different checksum, but I was pleasantly surprised that the checksums are the same :) 2016-07-08 13:40:31 <^7heo> moin jirutka 2016-07-08 13:40:35 <^7heo> how were your talks? 2016-07-08 13:40:55 <^7heo> (I'd ask that on #alpine-offtopic but you're not there) 2016-07-08 13:42:01 ^7heo: i'm looking for your nlplug-findfs patch. i cant find it. what did you pus in subject of the email? 2016-07-08 13:42:33 ^7heo: PM 2016-07-08 13:42:37 <^7heo> jirutka: ok 2016-07-08 13:42:41 <^7heo> ncopa: one sec' 2016-07-08 13:43:02 <^7heo> "LUKS header support" 2016-07-08 13:49:28 found it 2016-07-08 13:49:29 thanks 2016-07-08 13:58:19 so: with gcc 5.3, I could use musl's specs file with gcc (if I want to build against the latest musl git instead of the one Alpine provides) 2016-07-08 13:58:38 with gcc-6.1, I'm getting: 2016-07-08 13:58:47 collect2: error: ld returned 1 exit status 2016-07-08 13:58:59 how did you specify the specs file? 2016-07-08 13:59:03 -specs 2016-07-08 13:59:03 collect2: error: ld returned 1 exit status 2016-07-08 13:59:04 with GCC_SPECS? 2016-07-08 13:59:07 ok 2016-07-08 13:59:09 wait a sec 2016-07-08 13:59:22 having trouble pasting lines starting with / 2016-07-08 13:59:24 yay irc 2016-07-08 13:59:51 /usr/lib/gcc/x86_64-alpine-linux-musl/6.1.0/../../../../x86_64-alpine-linux-musl/bin/ld: /usr/lib/gcc/x86_64-alpine-linux-musl/6.1.0/crtbegin.o: relocation R_X86_64_32 against `__TMC_END__' can not be used when making a shared object; recompile with -fPIC 2016-07-08 14:00:01 /usr/lib/gcc/x86_64-alpine-linux-musl/6.1.0/crtbegin.o: error adding symbols: Bad value 2016-07-08 14:00:01 collect2: error: ld returned 1 exit status 2016-07-08 14:00:33 this is with musl-gcc -specs specsfile "$@" 2016-07-08 14:00:43 uh, no 2016-07-08 14:00:52 /usr/bin/gcc -specs specsfile "$@" 2016-07-08 14:03:13 the specs file contains those lines: 2016-07-08 14:03:23 *link: 2016-07-08 14:03:23 -dynamic-linker /lib/ld-musl-x86_64.so.1 -nostdlib %{shared:-shared} %{static:-static} %{rdynamic:-export-dynamic} 2016-07-08 14:04:08 oooh, I think I get it 2016-07-08 14:04:23 hum 2016-07-08 14:04:32 the default specs file doesn't hardcode the full path for crtbegin.o 2016-07-08 14:04:36 so i tried to work on firefox 32bit today 2016-07-08 14:04:43 so it falls back on the distro's crtbegin 2016-07-08 14:05:01 but running firefox now with ssh -Y does not display anything 2016-07-08 14:05:07 i dont know if that was due to gcc6 2016-07-08 14:05:16 or something new is in firefox-46 2016-07-08 14:06:02 firefox-esr build with gcc-5.3 and with FPU_FIX disabled works 2016-07-08 14:06:14 but it also gives the inconsisted math calc 2016-07-08 14:07:20 (getting on with my thoughts) no, that's not it, the specs file can't hardcode the full path for crtbegin.o since it's provided by the compiler 2016-07-08 14:07:55 I can't figure out whether it's a gcc problem, a musl problem or an Alpine problem -_- 2016-07-08 14:13:10 hi 2016-07-08 14:13:34 jirutka, I was also going to send you lwn subscriberlink, but barthalion was faster :) 2016-07-08 14:15:15 well, I'm not in rst-hate camp, so I'm not really against their change of mind. I think that rst extensiiblity is useful thing. 2016-07-08 14:16:17 learning that asciidoc is targetting docbook internally was another point against it 2016-07-08 14:16:21 but ad rem 2016-07-08 14:16:31 regarding apk-related wishlist 2016-07-08 14:16:47 as the subject was touched today 2016-07-08 14:17:31 przemoc: how is AsciiDoc targeting DocBook? o.O 2016-07-08 14:17:42 przemoc: it’s just based on _semantics_ of DocBook, nothing more 2016-07-08 14:17:59 przemoc: and AsciiDoc(tor) is very extensible 2016-07-08 14:18:43 przemoc: have you ever tried to write something (like few pages) in both RST and AsdiiDoc? try it, then tell me… ;) 2016-07-08 14:23:29 I think that some minimal user/group management _must_ be built into apk, but it will require some APKBUILD changes too (enhancements mostly). it will allow then removal of most pre-install/upgrade scripts in packages. I may even create lib (MIT) for sane fiddling with passwd/group for my own purposes, so then it could be used in apk. being able to `apk add -p ROOTFS something` and have properly u 2016-07-08 14:23:35 pdated ROOTFS/etc/{group,passwd} would be super useful. 2016-07-08 14:26:27 if it's a no-go, then at least we should switch from bb's adduser/addgroup to own solution that will respect some rootfs defining environment var, that apk will set prior to invoking scripts. 2016-07-08 14:28:21 I mentioned in the past also that having some default user/group id map would allow having same ids on different machines regardless of package installation order. if we could switch to own solution, then it would be easy to cover also. 2016-07-08 14:30:00 przemoc: what I would like to see is a way to run abuild without fakeroot. Which means a way to map uids/gids into the archive at build time without root privileges. 2016-07-08 14:30:47 yes, I also think that fakeroot is a cheap shortcut that shouldn't be required in modern build system 2016-07-08 14:30:57 doesn't have to be baked into the archive, it can be a separate file with a list of uid/gids and permissions, but I really want to see this 2016-07-08 14:32:14 (it probably needs to be baked into the archive if we want to avoid race conditions at unpack time where the archive creator's uid could access files it's not supposed to own) 2016-07-08 14:34:39 (I became maintainer of metastore some time ago, just to make its first official release (after some fixes), and I had plans to bring text file driven mode, but never had time for that, as I wanted to rearchitect whole app properly in the go. it would allow something like you want to some extent.) 2016-07-08 14:39:25 somehow I don't like .spec files, but their %files section (directive, to be precise) supporting %defattr and %attr are kind of useful and cleaner than explicitly calling chmod or chown on our own during packaging 2016-07-08 14:41:18 we really should migrate to TCB shadow 2016-07-08 14:43:52 does it require PAM? 2016-07-08 14:44:06 no, it's musl feature 2016-07-08 14:44:47 but yes, also doing user add in apk was discussed earlier 2016-07-08 14:44:55 i have it in apk wishlist 2016-07-08 14:46:42 i hope to get it done soonish 2016-07-08 14:46:51 i have bunch of other things pending for apk too 2016-07-08 14:50:45 along with the mentioned lib I plan to write for plain passwd/group stuff I would also write an app using it, obviously, and I plan to provide compat mode mimicking bb's adduser/addgroup syntax and maybe some other tools too (useradd, groupadd?). it would be good and useful to have same code fiddling with users in apk and tool (be it adduser or whatever) adding them in running distro. 2016-07-08 14:53:16 I haven't digged into this tcb stuff before, though, so not sure how it differs from typical passwd/shadow/group files. 2016-07-08 14:53:33 the idea is that each user has it's own shadow file portion 2016-07-08 14:53:38 so passwd does not need setuid 2016-07-08 14:55:28 sounds good 2016-07-08 14:59:47 tcb is great 2016-07-08 15:00:04 if you're implementing something that will replace adduser/addgroup, it's definitely the way to go 2016-07-08 15:01:25 well, supporting old (predominant) scheme too cannot be avoided IMHO 2016-07-08 15:02:39 if you're programming portably, sure. If you're programming _for Alpine_, that's purely a choice of the distribution. 2016-07-08 15:06:09 I always prefer being portable than tieing to particular solution/distro/whatever, unless it makes stuff tenfold harder to make, maintain, etc. after all dedicated tools have their purpose too sometimes. 2016-07-08 15:08:02 as a distro-agnostic author, obviously I like my tools portable, but adduser and such are completely policy-dependent, and it makes sense to develop distro-specific tools for that kind of thing. 2016-07-08 15:13:06 I guess pleasing all distros is straight impossible in such case, but I believe some middle PAM-less plain-text ground can be found 2016-07-08 15:15:15 przemoc: what's the problem with bb adduser? 2016-07-08 15:18:07 the main problem is IMHO lack of lib for user/group management supporting rootfs other than /. having adduser replacement (with saner option naming) will be a simple consequence 2016-07-08 15:18:59 s/IMHO // 2016-07-08 15:19:46 what do you mean, you want to be able to read a database that's somewhere else than /etc ? 2016-07-08 15:19:47 I want to make it modular, so passwd/group/shadow would be one of its modes (and only one for starters) 2016-07-08 15:21:36 yes 2016-07-08 15:22:38 but the posix getpw*() will still have to use the default, rootfs-based, db 2016-07-08 15:24:04 getpw* is okish if you want to deal with user/group db of system you're in (or chroot, whatever) 2016-07-08 15:24:34 having more general alternative shouldn't hurt anyone 2016-07-08 15:25:04 sure, but existing applications will use and link against getpw*, so your implementation needs to provide those APIs 2016-07-08 15:25:36 else, only new applications that are aware of your lib can use it 2016-07-08 15:28:19 yes, but it's fine. beside specialized tools, like package managers, etc. there is no deep need to be able to access user/group db outside of /etc. I may provide getpw* APIs later, but it's not crucial. I won't be fighting with, let's say, musl, to make my getpw* "replacement" stuff dominant, as I'm not really aiming to replace it, just provide some (hopefully nicer and more configurable) alternat 2016-07-08 15:28:25 ive. 2016-07-08 15:29:33 ok, now I understand what you want a bit better, thanks. :) 2016-07-08 15:46:27 ncopa: okay, I’ve merged pypi fix for testing/* and community/* packages; please merge main/* https://github.com/alpinelinux/aports/pull/150.patch 2016-07-08 16:44:47 jirutka: applied and pushed 2016-07-08 16:45:09 barthalion: thanks 2016-07-08 16:45:31 btw some packages are failing on armhf… 2016-07-08 16:46:02 yeah, but I'm busy today 2016-07-08 16:46:08 I'm still not done with patchwork either 2016-07-08 16:46:22 jirutka: btw, http://patchwork.alpinelinux.org/patch/2197/ 2016-07-08 16:46:30 who pushed these packages? 2016-07-08 16:46:53 armhf builders were out of service for a while 2016-07-08 16:46:53 py-cparser and geary 2016-07-08 16:47:21 geary is probably from ScrumpyJack's package move 2016-07-08 16:47:42 yeah, but who pushed the packages that are blocking armhf builders? 2016-07-08 16:47:48 cparser… there was probably just regular update that built on x86 and x86_64 2016-07-08 16:47:58 how does it matter? 2016-07-08 16:48:13 how someone is expected to know build is broken on armhf if nothing builds packages for armhf at the time of push? 2016-07-08 17:57:24 is mailing list still the recommended way to submit packages? 2016-07-08 18:05:31 it's the same as asking people here to merge from pastebin or on github 2016-07-08 18:05:34 up to you 2016-07-09 13:58:57 am I assuming correct in that feeding configure a less specific --build and --host than x86_64-alpine-linux-musl prefered to replacing config.sub with a never one, yes? 2016-07-09 15:08:19 There was also a function update_config_sub or something similar 2016-07-09 15:08:51 On the phone now so can't check 2016-07-09 15:30:26 yeah, found it 2016-07-09 22:26:32 hi, im currently failing abuilding a package from a source-url, which needs to be feed with a referer while fetching... For ARCH/PKGBUILD i could workaround this issue via DLAGENTS 2016-07-09 22:26:35 (DLAGENTS='https::/usr/bin/wget --referer $REFURL -N $URL) in PKGBUILD or via /etc/makepkg.conf 2016-07-09 22:26:37 where can "abuilds fetching" be configured or is there any equivalent in apkbuild or any nice alternative than setting up a localwebserver for fetching? 2016-07-09 23:49:10 hi devs, how can alpinelinux ifself being recompiled (eg. foreign arch)... Any hints about setting up the buildchain, Scripts, $whatever? 2016-07-10 00:13:03 n00b13: look in the thread "Porting Alpine scripts" on the devel mailing list archive - there's some usefull information there. http://lists.alpinelinux.org/alpine-devel/ 2016-07-10 00:15:12 jzono1: awesome - thanx :-) 2016-07-10 11:20:53 if some binary requires relocations against its text segments (TEXTRELs), would it not work on Alpine? 2016-07-10 11:22:51 i compiled a binary on Alpine and subsequently got ldd complaining "Not a valid dynamic program". I straced it back to EACCES issue: https://bpaste.net/show/97168fd8c067. 2016-07-10 11:24:17 Then I did readelf and found (only) one TEXTREL entry: 0x0000000000000016 (TEXTREL) 0x0 2016-07-10 11:24:55 could this be the reason ldd is marking as invalid dynamic program? 2016-07-10 20:37:58 Anything change recently in gettext or libintl for where to get libintl_gettext 2016-07-10 20:41:52 Also Alpine 3.4 should probably have dhcpcd upgraded to at least 6.11.0. In previous versions there's a bug which leaves a reject route in place for your IPv6 deligation. 5th bullet point here: http://roy.marples.name/archives/dhcpcd-discuss/2016/1292.html. 2016-07-10 20:49:26 hi 2016-07-10 20:49:37 can someone bump pkgconf-1 in aports 2016-07-10 21:43:06 kaniini: bump'd 2016-07-10 21:49:54 barthalion: I wonder why Patchwork upstream doesn’t adopt RESTful API from the freedesktop fork instead of reimplementing it? 2016-07-10 21:59:44 thx 2016-07-11 07:10:15 morning climbers. Happy Monday! 2016-07-11 07:17:58 ScrumpyJack: >happy monday 2016-07-11 07:18:15 but but it is an oxymoron. 2016-07-11 11:01:23 [web.lua] Error in RequestHandler, thread: 0x40793320 is dead. 2016-07-11 11:01:25 ooops 2016-07-11 11:01:41 ./db.lua:244: attempt to index local 'stmt' (a nil value) 2016-07-11 11:02:04 http://pkgs.alpinelinux.org/flagged?origin=&branch=&repo=&maintainer=Thomas+Boerger that's where it happens for me 2016-07-11 11:06:34 turbolua is generally unhappy for a few days already 2016-07-11 11:06:42 clandmeter: same happens with tpaste from time to time 2016-07-11 11:07:14 jirutka: because they went freedesktop way of development 2016-07-11 11:07:48 jirutka: also why not ask it the other way – why freedesktop didn't upstream their changes? 2016-07-11 11:07:59 barthalion: understood 2016-07-11 11:08:17 it's up to clandmeter what we use though 2016-07-11 11:08:24 I don't really care, just fooling around 2016-07-11 11:08:30 barthalion: however, the current XML-RPC API of Patchwork is kinda useless 2016-07-11 11:08:39 yeah, I was looking at it yesterday 2016-07-11 11:08:42 can't disagree 2016-07-11 11:09:01 barthalion: but I’m the last one who wants to use anything from freedesktop… :/ 2016-07-11 11:09:02 we could probably just switch to freedesktop fork, it looks more alive 2016-07-11 11:09:13 yeah 2016-07-11 11:09:29 that's a pretty bold gamble 2016-07-11 11:09:38 skarnet: the switch? 2016-07-11 11:09:42 it is 2016-07-11 11:09:59 yes. How long will it take before they start doing freedesktop things with it? 2016-07-11 11:10:16 it's hard to do freedesktop things to django app 2016-07-11 11:10:35 it's also hard to do freedesktop things to init, and they did it 2016-07-11 11:10:35 maybe it would be easier to integrate directly via SMTP than this useless patchwork API 2016-07-11 11:11:05 I'm happy with systemd, don't sign me into this flamewar 2016-07-11 11:11:14 s/init/X/ then 2016-07-11 11:11:14 barthalion: YOU’RE WHAT?! 2016-07-11 11:11:41 the main reason to stick with ozlabs freedesktop is that while its development is slow, it's also steady 2016-07-11 11:12:28 and except crappy API, it works… 2016-07-11 11:13:31 if ain't broke 2016-07-11 11:24:04 mosez: seems as Thomas Boerger is the issue here 2016-07-11 11:24:16 fabled: morning. you about? 2016-07-11 11:24:27 ScrumpyJack, hey 2016-07-11 11:24:37 will check what happens. 2016-07-11 11:24:50 barthalion: i didnt have a single error with tpaste yet 2016-07-11 11:26:56 barthalion: any specific paste that goes wrong? 2016-07-11 11:28:15 ok found one that ncopa reported 2016-07-11 11:29:01 hmm strange, seems to work now after a restart 2016-07-11 11:39:49 <^7heo> clandmeter: are you running that on windows? 2016-07-11 11:39:53 <^7heo> clandmeter: because that would explain it. 2016-07-11 11:40:26 you would think so... 2016-07-11 11:57:49 fabled: did i read that you figured out what the overlay issue is? 2016-07-11 12:10:26 maybe a hard link to fix it? 2016-07-11 12:21:41 ScrumpyJack, i think what i looked at was different issue 2016-07-11 12:27:00 sorry about the typo in update-kernel 2016-07-11 13:05:56 barthalion: armhf is failing again, llvm is broken… 2016-07-11 13:15:36 barthalion: aarch64 and arm(v7) are failing too since today :( 2016-07-11 13:22:17 <^7heo> ACTION goes in French "manifestation" mode 2016-07-11 13:22:31 <^7heo> WE - WANT - MORE - TEST - TING! 2016-07-11 13:22:41 <^7heo> ACTION hides quickly before the CRS show up 2016-07-11 13:23:33 ^7heo: pretty accurate 2016-07-11 13:23:48 <^7heo> skarnet: I know, right? 2016-07-11 13:23:49 ^7heo can now be found BBQing some sausages with his fellow strikers 2016-07-11 13:24:06 <^7heo> yeah sortof. 2016-07-11 13:24:12 <^7heo> I'm in the basement, in the sofa 2016-07-11 13:24:18 <^7heo> listening to some meditation music 2016-07-11 13:24:22 <^7heo> so I guess it qualifies 2016-07-11 13:38:14 jirutka: I kind of hope fabled will take a look at this 2016-07-11 13:38:43 jirutka: mesa is broken too 2016-07-11 13:38:54 and so is geary 2016-07-11 13:39:13 barthalion: kinda hope? you’re the last one who pushed llvm… 2016-07-11 13:39:29 buy me the hardware 2016-07-11 13:39:57 <^7heo> barthalion: can I also break stuff and ask for presents? 2016-07-11 13:40:33 <^7heo> I'm gonna search for something to break but anyway, I would like an HTC vive please. 2016-07-11 13:40:52 barthalion: why should I buy you a hardware? 2016-07-11 13:41:41 So you want me to test the build on my microwave oven? Makes sense 2016-07-11 13:42:06 barthalion: I think that we have a non-written rule: when you push something to the aports repo, you should watch #alpine-commits and when the build of your commits fail, then you must fix it 2016-07-11 13:42:31 <^7heo> barthalion: if the software is designed for your microwave oven, why don't you? 2016-07-11 13:42:48 You won't guess, I sit way longer here than you 2016-07-11 13:43:40 barthalion: or of you don’t have a time to fix it right now, then at least ask someone to do that… but definitely not *hope that someone else will clean the mess* 2016-07-11 13:43:50 There is also a rule that if you have no place to test the build, you don't have to 2016-07-11 13:44:16 So kthxbye? 2016-07-11 13:44:43 barthalion: do you understand that armhf build queue is now stuck and no other package can be built? 2016-07-11 13:45:09 <^7heo> barthalion: no testing is bad enough 2016-07-11 13:45:13 barthalion: and btw why is it configured in this blocking mode? 2016-07-11 13:45:16 <^7heo> no testing + no caring is really annoying. 2016-07-11 13:45:19 It wouldn't unblock anyway 2016-07-11 13:45:32 <^7heo> as jirutka said; if you push, you watch. 2016-07-11 13:45:44 <^7heo> it's not like you're the only one to push 2016-07-11 13:45:46 ^7heo: well, this is not so easy to test, because it’s armhf 2016-07-11 13:45:52 <^7heo> yeah okay 2016-07-11 13:45:56 The list of broken packages is longer than llvm 2016-07-11 13:45:59 <^7heo> but the watching part is still there. 2016-07-11 13:46:23 <^7heo> anyway 2016-07-11 13:46:32 Also I'm so happy to have ^7heo on ignore list 8) 2016-07-11 13:46:40 barthalion: so you think that it will not hurt to add another broken package to the queue? or what? 2016-07-11 13:47:09 You won't get the queue clear without fixed llvm 2016-07-11 13:47:15 <^7heo> jirutka: it's pretty polite of you to think that he thinks. 2016-07-11 13:47:38 And probably webkitgtk too 2016-07-11 13:48:21 barthalion: does anyone beside you even know what packages are broken on armhf, so somone can fix them? 2016-07-11 13:48:57 Yes, you and anyone else on commits channel 2016-07-11 13:49:26 barthalion: I don’t know, I see only failing llvm, it’s not clear from #alpine-commits messages that there are more broken packages on armhf 2016-07-11 13:50:08 Well, nobody fixed geary, you already have complained about it 2016-07-11 13:50:40 ^7heo: please don’t be rude, this will not help 2016-07-11 13:50:47 <^7heo> jirutka: I was testing the ignore. 2016-07-11 13:51:02 barthalion: geary is that go crap or it’s something else? 2016-07-11 13:51:28 Some email client 2016-07-11 13:51:40 aha 2016-07-11 13:52:02 <^7heo> it's some crappy email client written in Vala 2016-07-11 13:52:06 <^7heo> or whatever it is. 2016-07-11 13:52:10 Without hw I can only guess the fix 2016-07-11 13:52:34 understand 2016-07-11 13:52:45 hmm, I should build some ARM cluster for testing 2016-07-11 13:52:54 <^7heo> don't we have a beagleboard for that 2016-07-11 13:52:55 <^7heo> ? 2016-07-11 13:53:04 It builds on x86, I don't know arm well enough to have any suspects 2016-07-11 13:53:25 ^7heo: yes, but we don’t have any testing servers now, just build servers 2016-07-11 13:53:45 <^7heo> so, a good way to work that out would be: 2016-07-11 13:53:46 <^7heo> 1. push 2016-07-11 13:53:49 <^7heo> 2. check 2016-07-11 13:53:54 <^7heo> 3. optionally revert 2016-07-11 13:53:56 ^7heo: I think that we can use QEMU on Travis to test pkgs on arm… or maybe is there any public CI that provides ARM? 2016-07-11 13:53:56 <^7heo> right? 2016-07-11 13:54:12 <^7heo> jirutka: does travis provide ARM testing? 2016-07-11 13:54:14 You will quickly get timeout 2016-07-11 13:54:31 ^7heo: yeah, I hate using build server as a testing server, but we currently doesn’t have any other option for ARM :/ 2016-07-11 13:54:35 we are planning to redo the building system so that getting testing for all build targets comes easy. hope to add cross building support too so arm would be cross built where possible. 2016-07-11 13:54:41 but we are not there yet 2016-07-11 13:54:46 <^7heo> jirutka: yeah but if it fails at step 2... 2016-07-11 13:54:51 <^7heo> jirutka: it's not working well, obviously. 2016-07-11 13:55:21 <^7heo> fabled: to get a faster build? 2016-07-11 13:55:39 yes, and to be able to do testing before pushing out 2016-07-11 13:55:59 <^7heo> I should be able to provide some armhf machines for testing 2016-07-11 13:56:00 <^7heo> if needed 2016-07-11 13:56:11 <^7heo> for now 2016-07-11 13:56:32 <^7heo> the problem is that my network is really crappy 2016-07-11 13:59:31 <^7heo> fabled: would that help? 2016-07-11 14:00:51 not really. we need to fix the building system to support more parallelism 2016-07-11 14:41:50 jirutka: https://github.com/alpinelinux/aports/pull/155#issuecomment-231727340 this one might have different ABI 2016-07-11 14:48:12 barthalion: what we can do with it? 2016-07-11 14:53:01 rebuild all perl-* packages that are not noarch 2016-07-11 14:54:21 because of x264…? 2016-07-11 14:54:45 you probably mean https://github.com/alpinelinux/aports/pull/152, upgrade perl, don’t you? 2016-07-11 14:56:03 Yeah, what ncopa says but w/ x264 2016-07-11 14:57:09 Can you make Travis run checkapk after build? 2016-07-11 15:05:54 but the same applies to perl ofc 2016-07-11 15:17:57 barthalion: not sure about output of this command http://haste.fit.cvut.cz/emoxuja.log 2016-07-11 15:22:15 yeah, doesn't seem to relevant to perl, but it will require a rebuild of dependent packages, it always happen on major releases 2016-07-11 17:31:50 hello. how should I proceed if I want to bootstrap alpine for another arch? 2016-07-11 17:33:39 leitao: look in the devel mailinglists. there's a recent discussion on it there. http://lists.alpinelinux.org/alpine-devel/ (right near the top, "Porting Alpine scripts") 2016-07-11 17:33:45 leitao, http://wiki.alpinelinux.org/wiki/User:Fabled 2016-07-11 17:33:59 good. Thanks! 2016-07-11 17:34:09 we recently built aarch64 userland, and armv7 2016-07-11 17:34:17 but those are still work in progress 2016-07-11 17:34:51 what's the criteria for including a new package in the minimal isos? 2016-07-11 17:36:47 would being able to install to and boot from iscsi be something worth including? 2016-07-11 17:37:23 i think it's mostly that it's preferably in main, and likely need for installation 2016-07-11 17:37:44 iscsi would probably make sense 2016-07-11 18:21:50 clandmeter: i just wanted to search for flagged packages maintained by me :D 2016-07-11 22:46:09 api can now filter flagged data, eg. http://api.alpinelinux.org/packages/flagged?origin=&branch=&repo=&maintainer= 2016-07-11 22:46:29 the database is old though 2016-07-11 22:46:50 web testsite , http://pkgstest.alpinelinux.org/flagged.html 2016-07-12 07:07:08 morning climbers 2016-07-12 07:07:24 o/ 2016-07-12 08:15:51 have anyone tried installing Alpine on an odroid C2 ? 2016-07-12 08:16:01 http://www.hardkernel.com/main/products/prdt_info.php?g_code=G145457216438 2016-07-12 08:26:54 ncopa, could we get new abuild tagged ? 2016-07-12 08:33:54 fabled: for cross compile features? 2016-07-12 08:34:32 that, the arch='all !armhf' thing and the download renaming 2016-07-12 08:34:48 we call it 2.28? 2016-07-12 08:35:10 or we just cherrypick the 6 patches since last release? 2016-07-12 08:35:17 http://git.alpinelinux.org/cgit/abuild/ 2016-07-12 08:35:36 well, up to you. i thought it's simpler to tag than then cherry pick 6 commits 2016-07-12 08:36:03 approx the same 2016-07-12 08:36:32 i wonder if i should start looking at the chroot building; and fakeroot replacement 2016-07-12 08:37:12 might be an idea 2016-07-12 08:37:16 one feature request 2016-07-12 08:37:24 or one thing i will need 2016-07-12 08:37:37 grab the sources for a given install 2016-07-12 08:38:03 so if i have a set of packages 2016-07-12 08:38:16 that i want redistribute and be gpl compliant 2016-07-12 08:38:27 i need to also redistribute the sources 2016-07-12 08:38:41 sounds like scripting to do git checkout for specific version + abuild fetch 2016-07-12 08:39:00 + APKBUILD and patches in aports tree 2016-07-12 08:39:20 we have an abuild srcpkg command 2016-07-12 08:39:25 which i havent used for years 2016-07-12 08:40:18 what i wonder - while talking about abuild changes 2016-07-12 08:40:41 woudl it be an idea to move to debian like source packaging? 2016-07-12 08:40:51 that we create full source packages that abuild uses later? 2016-07-12 08:40:55 for me it serves no purpose 2016-07-12 08:41:12 but i understand where it would be useful 2016-07-12 08:41:30 well you could use the soruce package in chroot instead of having the full git tree there 2016-07-12 08:42:20 bind mounting is cheap 2016-07-12 08:42:25 I don't see many gains of that 2016-07-12 08:42:26 true 2016-07-12 08:42:35 you first make a tarball, then extract it in chroot 2016-07-12 08:42:47 bind mount is faster yes 2016-07-12 08:43:06 i dont say it was a good idea 2016-07-12 08:43:07 :) 2016-07-12 08:43:17 i just wanted to mention it 2016-07-12 08:43:52 yes 2016-07-12 08:44:02 it might make sense for some things 2016-07-12 08:45:39 coredumb: I will most likely buy it soon 2016-07-12 08:46:27 hmm. new kernels. 2016-07-12 08:47:40 <^7heo> does the RANDMMAP also applies to nlplug-findfs? 2016-07-12 08:50:00 ^7heo, yes, RANDMMAP applies to everything unless explicitly turned off with paxmark 2016-07-12 08:51:23 <^7heo> fabled: I meant to ask if PaX was also in the initramfs. 2016-07-12 08:51:36 it's kernel feature, so it applies to initramfs too 2016-07-12 08:55:45 <^7heo> it's different kernels, isn't it? 2016-07-12 08:56:29 <^7heo> so I ask again, are you sure that having a wandboard quad wouldn't help for testing? 2016-07-12 09:01:17 barthalion: oh cool :) 2016-07-12 09:21:40 ncopa, fabled: http://patchwork.alpinelinux.org/patch/1656/ can you take a look at this? 2016-07-12 10:06:45 ^7heo, we have few wandboard quads here. we just don't do testing with them that often. 2016-07-12 10:07:40 barthalion, i think patchworks 1656 is not needed, the bug was fixed in modloop build script 2016-07-12 10:08:01 it refers to bug #5146 and it's resolved with alpine-iso commits 2016-07-12 10:12:54 <^7heo> fabled: where did you order them? 2016-07-12 10:14:07 i think i bought mine from Mouser 2016-07-12 10:14:30 but that was few years ago orso 2016-07-12 10:15:38 <^7heo> that's ok 2016-07-12 10:15:42 <^7heo> I was looking to buy some 2016-07-12 10:16:06 <^7heo> but it's hard to find that specific board. 2016-07-12 10:17:25 <^7heo> it's a bit pricey 2016-07-12 10:17:27 <^7heo> but wth 2016-07-12 10:17:30 <^7heo> thanks a lot fabled 2016-07-12 10:36:58 barthalion: any point on graphic accel status on ARM boards ? 2016-07-12 10:37:39 the few ARM I tested just gave me a lot of frustration in the graphic department 2016-07-12 11:05:30 I am trying to get Bluetooth working on the RPi3. I have followed https://wiki.alpinelinux.org/wiki/Raspberry_Pi_3_-_Setting_Up_Bluetooth and it works, until reboot. After reboot I have to hciattach again. Does anyone have any ideas about how I can add this to the boot process or in some other way make the OS remember it? 2016-07-12 11:08:59 i'd expect bluez to have openrc script that does it on boot if configured right 2016-07-12 11:09:39 I would expect so too. I have seen mention in Raspbian forums about an hci_uart service, but there is nothing like that here 2016-07-12 11:10:40 I know there is a bluetooth script in init.d that starts the service, but without attaching the HCI to UART it doesn't do anything. 2016-07-12 11:11:54 i use bluetooth on my workstation 2016-07-12 11:12:39 i find bluetooth a bit difficult 2016-07-12 11:12:58 my bt keyboard does not work on reboot for some reason 2016-07-12 11:13:03 Yeah it is pretty tricky. Especially BLE. 2016-07-12 11:13:23 bluez5 is very dbus centric too 2016-07-12 11:13:32 But unfortunately at work I have to develop an app that uses BLE on the Pi to talk to mobile phones. 2016-07-12 11:13:45 And Alpine is the best choice for our use case. 2016-07-12 11:15:04 I have AUTO_ENABLE="hci0" in /etc/conf.d/bluetooth 2016-07-12 11:15:10 ncopa, you ok with http://sprunge.us/PUeE ? 2016-07-12 11:15:53 I don't even have a file for /etc/conf.d/bluetooth 2016-07-12 11:16:05 I feel like apk add bluez isn't installing it properly 2016-07-12 11:16:07 fabled: lgtm 2016-07-12 11:16:23 Because the BlueZ site said I should have an /etc/bluetooth dir with main.conf and some others in there 2016-07-12 11:16:25 And I don't 2016-07-12 11:16:52 main.conf? 2016-07-12 11:16:56 i havent seen that 2016-07-12 11:18:08 http://www.linuxfromscratch.org/blfs/view/svn/general/bluez.html 2016-07-12 11:18:16 Under "Configuration Files" subheading 2016-07-12 11:18:56 I even created the uart.conf file and tried to put the hciattach in there but it isn't getting picked up. 2016-07-12 11:19:07 Admittedly I don't understand the RC system all that well. 2016-07-12 11:22:19 interesting 2016-07-12 11:22:20 To be clear the Bluetooth stack works fine. It just won't attach on startup. 2016-07-12 11:22:42 so its some init.d script that is either missing or not doing what it is supposed to 2016-07-12 11:22:54 there is a link to LFS scripts 2016-07-12 11:22:59 i'll have a look what they do 2016-07-12 11:23:10 And the bluetooth script in the init.d folder reports a status of "Ok" on boot 2016-07-12 11:23:16 yes 2016-07-12 11:23:26 but all it does is starting the blutoothd 2016-07-12 11:24:19 it can optionally run hciconfig $adapter up on given adapters specified in /etc/conf.d/bluetooth 2016-07-12 11:24:31 but i think you need hciattach, right? 2016-07-12 11:24:52 Yeah. hciattach has to happen before hciconfig or there are no recognized devices. 2016-07-12 11:26:48 as i understand it, rpi has serial port / emulation for the hci device. and hciattach creates the hci device that is bound to the ttyXXX interface 2016-07-12 11:27:17 @fabled That's my understanding too 2016-07-12 11:27:34 ok, so thats why hciattach needs to execute before hciconfig 2016-07-12 11:27:44 kinda lame that it's not in .dtb and done automatically on module load 2016-07-12 11:27:58 Yeah. You would think it would be. 2016-07-12 11:29:18 heh, interesting 2016-07-12 11:29:34 the lfs init script will run start_hci_dev before start_uart 2016-07-12 11:29:40 but i think we need the opposite, right? 2016-07-12 11:29:59 well 2016-07-12 11:30:05 you can also run virtual COM over bluetooth 2016-07-12 11:30:10 sounds like the above is for that 2016-07-12 11:30:17 That seems right but my understanding of this is pretty shallow 2016-07-12 11:30:21 we need setup_uart_hci 2016-07-12 11:30:25 that runs first 2016-07-12 11:30:40 and rfcomm? 2016-07-12 11:30:49 is that serial device over bt? 2016-07-12 11:31:41 i wonder if we should just add an /etc/init.d/hciattach script 2016-07-12 11:31:44 It looked to me like rfcomm was using TCP or something instead of UART. Like maybe an alternative method. But that was just from scanning some BlueZ stuff 2016-07-12 11:32:21 It is interesting to me that apk add bluez didn't create /etc/conf.d/bluetooth for me. 2016-07-12 11:32:31 nah 2016-07-12 11:32:40 you have to create it manually 2016-07-12 11:32:50 i can easily fix that though 2016-07-12 11:33:05 Oh I didn't realize that 2016-07-12 11:35:08 the uart.conf seems to be LFS specific 2016-07-12 11:35:17 main.conf seems to some from bluez source package 2016-07-12 11:35:26 but its not installed with make install 2016-07-12 11:35:33 lfs doc show how to intsall it manually 2016-07-12 11:35:44 Oh. Well that would explain why it wasn't getting picked up on boot. =p 2016-07-12 11:35:57 coredumb: sorry, no; I'll use it for building 2016-07-12 11:36:31 jkwright: but i thnk we still miss something that can do hciattach at boot 2016-07-12 11:38:18 A tangential question: does the mini-uart behave in Alpine as it does in Raspbian? Is it configured similarly? Don't want to get too sidetracked but I am going to have to use RS232 in this thing also, but I haven't gotten to that part of the setup yet. 2016-07-12 11:41:21 ncopa, yes, rfcomm is virtual COM device over BT 2016-07-12 11:41:32 jkwright: i have no idea what raspian does 2016-07-12 11:41:39 i am looking at gentoo init scripts 2016-07-12 11:41:54 there are no script for hciattach there either 2016-07-12 11:42:02 i suspect it is supposed to be handled by udev 2016-07-12 11:45:52 Where does all that configuration live? 2016-07-12 11:46:22 in /lib/udev/rules.d and/or /etc/udev/rules.d i think 2016-07-12 11:46:28 but we dont use udev by default 2016-07-12 11:47:53 hm 2016-07-12 11:47:54 ok 2016-07-12 11:47:58 hte uart driver 2016-07-12 11:48:10 how does it show up for the kernel? 2016-07-12 11:49:30 How do I find that out? 2016-07-12 11:50:47 does it show up as something in /dev/* ? 2016-07-12 11:50:51 the uart 2016-07-12 11:50:55 it's ttyAMA0 i suppose 2016-07-12 11:51:11 yeah it works with ttyAMA0 in the hciattach so I guess that's it 2016-07-12 11:51:17 aha 2016-07-12 11:51:33 ttyAMA0 is basically ARM's native serial port driver 2016-07-12 11:51:38 then i have a "fix" for you 2016-07-12 11:51:39 so your ttyS0 equivalent 2016-07-12 11:51:51 in your /etc/mdev.conf 2016-07-12 11:51:56 add ttyAMA0 2016-07-12 11:52:06 and make it call hciattach 2016-07-12 11:52:09 I assumed that ttyS0 got attached to the miniuart and ttyAMA0 got attached to the PL011 2016-07-12 11:52:31 how do you call hciattach? 2016-07-12 11:52:43 hciattach /dev/ttyAMA0 bcm43xx 115200 noflow - 2016-07-12 11:54:53 try echo 'ttyAMA0 root:tty 660 @hciattach /dev/$MDEV bcm43xx 115200 noflow -' >> /etc/mdev.conf 2016-07-12 11:55:37 when the ttyAMA0 is detected by kernel, it will execyte the hciattach for you 2016-07-12 11:56:33 Okay I'll do a quick reboot and check that 2016-07-12 11:57:20 That did it! 2016-07-12 11:57:33 Thank you so much! 2016-07-12 11:58:00 I apologize for barging into the dev chat at such an ungodly hour with troubleshooting 2016-07-12 11:59:34 I will probably be back in the next day or two with questions about the miniUART and trying to get RS232 set up. 2016-07-12 12:00:14 where are you from? 2016-07-12 12:00:19 Austin 2016-07-12 12:00:35 both fabled and ncopa live in CET, so don't worry too much about the time here 2016-07-12 12:00:38 go get some sleep ;) 2016-07-12 12:00:52 lol I would but the work day is about to start! 2016-07-12 12:01:25 people say 15 minutes never killed anyone 2016-07-12 12:04:38 ncopa: marking http://patchwork.alpinelinux.org/patch/1012/ as rejected 2016-07-12 12:06:14 kunkku: http://patchwork.alpinelinux.org/patch/1131/ this seems to be assigned to you, any updates? 2016-07-12 12:25:18 umh 2016-07-12 12:25:26 i need to move xapian-* to community 2016-07-12 12:25:29 i think is the best place 2016-07-12 12:29:58 fcolista: +1 2016-07-12 12:30:13 going to move the deps as well on community 2016-07-12 12:33:38 deps ? 2016-07-12 12:33:47 some python deps from testing 2016-07-12 12:33:57 ok 2016-07-12 12:34:30 how pkg in main/ had deps in testing/ ? 2016-07-12 12:34:37 py-argh is on testing -> community 2016-07-12 12:34:37 py-livereload is on testing -> community 2016-07-12 12:34:38 py-watchdog is on testing -> community 2016-07-12 12:34:42 ah 2016-07-12 12:34:44 sorry 2016-07-12 12:34:56 ;) 2016-07-12 12:35:02 'cause with the upgrade of xapian has been introduced a new dep 2016-07-12 12:35:11 but i didn't noticed that it was on testing 2016-07-12 12:35:18 yes saw v4.0 2016-07-12 12:35:26 still, xapian is a package that needs to go on community 2016-07-12 12:35:58 hi 2016-07-12 12:37:02 fabled: I heard (from barthalion) that you work on aarch64 port of Alpine distro. Need help with it? 2016-07-12 12:38:01 fabled: I am Red Hat assignee at Linaro and work on making another installation of aarch64 developer cloud. 2016-07-12 12:38:56 hmm.. v1.4.0 2016-07-12 12:39:24 vkris: v1.4.0? 2016-07-12 12:39:53 correction for earliar typo for xapian v4.0 ;) 2016-07-12 12:39:59 ah 2016-07-12 12:42:55 hrw, yes, we are working on it. we have the bootstrap environment cross compiled. and are basically figuring out how to boot the beast. the problem is i don't have hardware, and it seems to have custom u-boot. 2016-07-12 12:43:17 fabled: u-boot.. fu 2016-07-12 12:44:36 fabled: http://www.linaro.cloud/signup/ if you want uefi bootable VM 2016-07-12 12:45:10 I would just need to talk with people managing it to get it up to speed to provide you vm(s) 2016-07-12 12:46:16 fabled: which Gigabyte board you have? 2016-07-12 12:46:22 MR0 one? 2016-07-12 12:55:11 fabled: if I can fetch/crossbuild basic rootfs then can help too 2016-07-12 12:56:30 barthalion: I commented the previous version of the patch on the ML 2016-07-12 12:56:32 http://lists.alpinelinux.org/alpine-aports/1780.html 2016-07-12 12:56:41 I must have missed the update 2016-07-12 12:57:15 anyway, the apache2 package underwent a major restructuring shortly afterwards 2016-07-12 12:57:39 so the patch should be rebased if there are still relevant changes 2016-07-12 12:59:31 hrw, clandmeter has the hardware i think apm something. basically xgene board. 2016-07-12 13:00:02 fabled: apm mustang probably. boots nice with uefi. 2016-07-12 13:00:11 have one under desk 2016-07-12 13:00:57 MP30AR0 (X-Gene/Storm) 2016-07-12 13:01:47 that's Gigabyte board. with X-Gene cpu 2016-07-12 13:03:21 yes it is 2016-07-12 13:03:36 it should boot with uboot. 2016-07-12 13:03:50 it has an ubuntu image that boots with uboot. 2016-07-12 13:03:56 clandmeter: https://lists.centos.org/pipermail/arm-dev/2016-March/001743.html is instruction how to get uefi on it 2016-07-12 13:04:06 hrw: i know 2016-07-12 13:04:10 then anything boots. debian, centos, fedora, rhelsa 2016-07-12 13:04:40 hrw: we dont want to boot those :) 2016-07-12 13:05:04 clandmeter: sure, but you may want to be bootable on any hardware, right? 2016-07-12 13:05:45 sbsa/sbbr (two standards describing aarch64 hardware and boot requirements) make it easier for distros 2016-07-12 13:05:54 <^7heo> fabled: the point in asking that is to have more testing. I really value travis on gh... And we have nothing equivalent for the ML/IRC 2016-07-12 13:06:38 clandmeter: I have exact same image booting on realhw and vm 2016-07-12 13:07:21 none of our boot media is uefi compat currently 2016-07-12 13:07:38 clandmeter: because on x86(-64) you did not had to 2016-07-12 13:07:43 <^7heo> which is fine because I yet have to find a computer that doesn't support legacy BIOS boot. 2016-07-12 13:07:52 i think ncopa uses gummiboot to build a bootable usb drive. 2016-07-12 13:08:34 ^7heo: around my desk there is less bios bootable machines then other ones 2016-07-12 13:09:35 true, boot media are not uefi compatible, but alpine boots just fine with it 2016-07-12 13:09:51 I have it as rescue system on boot partition, boots great with systemd-boot 2016-07-12 13:10:23 <^7heo> hrw: are you sure there are NOT BIOS compatible?! 2016-07-12 13:10:27 <^7heo> hrw: what kind of machine is that? 2016-07-12 13:12:27 ^7heo: around my desk: x86-64 thinkpad t430s (can boot non-uefi way if forced in bios), x86-64 desktop (as thinkpad), aarch64 apm mustang (uefi only), x86-64 tablet (64-bit uefi only), aarch64 pine64 (u-boot), few arm32 boards (u-boot), chromebooks (vboot+u-boot or vboot+kernel) 2016-07-12 13:13:14 <^7heo> afaik the chromeboot uses coreboot 2016-07-12 13:13:20 ^7heo: depends on model 2016-07-12 13:13:24 <^7heo> ah 2016-07-12 13:13:29 <^7heo> ok 2016-07-12 13:13:36 those are 2012 samsung arm ones. 2016-07-12 13:13:44 <^7heo> but yeah for the tablet, and the aarch64 machines... 2016-07-12 13:13:53 <^7heo> it's a shame tho. 2016-07-12 13:13:58 why? 2016-07-12 13:14:13 <^7heo> because UEFI shouldn't be assumed. 2016-07-12 13:14:34 <^7heo> BIOS isn't THAT hard to implement afaik. 2016-07-12 13:14:41 looking at last few years of aarch64 I prefer to have UEFI/ACPI than u-boot whatever 2016-07-12 13:14:49 ^7heo: bios thing is x86 only 2016-07-12 13:15:22 <^7heo> yeah, ok. I never paid attention too much about the boot loaders on other platforms. 2016-07-12 13:15:22 it is because it was in IBM PC 51xx and stayed for years 2016-07-12 13:15:28 <^7heo> yeah makes sense. 2016-07-12 13:15:43 <^7heo> and I understand why you prefer the UFEI to u-boot 2016-07-12 13:15:50 ^7heo: I work on ARM 32bit for 12 years, aarch64 for 4. 2016-07-12 13:16:15 <^7heo> that explains why you have so many machines of that type. 2016-07-12 13:16:15 did aarch64 bootstrap in openembedded, helped in debian/ubuntu, then in rhel/fedora 2016-07-12 13:16:33 <^7heo> s/type/arch/ 2016-07-12 13:16:51 ^7heo: https://marcin.juszkiewicz.com.pl/ ;D 2016-07-12 13:17:08 <^7heo> but IMHO, the UEFI isn't the right answer to the lacks of the BIOS and to the u-boot. 2016-07-12 13:17:28 ^7heo: it is 2016-07-12 13:17:50 <^7heo> Oh, Szczecin. 2016-07-12 13:17:57 <^7heo> We should have a beer next time I go there. 2016-07-12 13:18:03 ^7heo: hardware support gets easier if you can hide some internals in firmware instead of fighting in kernel 2016-07-12 13:18:12 ^7heo: ok 2016-07-12 13:18:37 <^7heo> hrw: what I'm saying is that it's not the right answer. 2016-07-12 13:18:46 <^7heo> hrw: not that there is no need for an answer. 2016-07-12 13:19:10 ^7heo: with u-boot you basically go for 'let kernel take care of everything' 2016-07-12 13:19:59 ^7heo: which in arm (both 32 and 64bit) world can end with huge amount of differences which are hidden on x86 2016-07-12 13:20:09 <^7heo> yeah I can totally imagine. 2016-07-12 13:20:17 <^7heo> but for example 2016-07-12 13:20:26 <^7heo> coreboot would be much better than the UEFI there, no? 2016-07-12 13:21:21 ^7heo, the amount of CPU power required for building all of Alpine for each commit is something travis does not give you free 2016-07-12 13:21:30 coreboot is also 'let init hw to the point where we can load kernel and let it take care of all' 2016-07-12 13:22:07 ^7heo, but yes, we are moving that direction and that's something we all want. we are just not yet there. 2016-07-12 13:22:29 <^7heo> fabled: please let me know if I can help. 2016-07-12 13:23:29 <^7heo> hrw: I didn't know that. 2016-07-12 13:23:35 <^7heo> I gotta go, bbl. 2016-07-12 13:23:56 ^7heo: coreboot initialize hw and then loads payload which is expected to take care of booting 2016-07-12 13:24:14 ^7heo: it can be filo/grub/kernel/seabios/tetris/hwinfo/memtest 2016-07-12 13:24:52 <^7heo> ah yeah 2016-07-12 13:24:57 <^7heo> what about seabios? 2016-07-12 13:25:01 <^7heo> (bbl for real now) 2016-07-12 13:27:56 ^7heo: seabios is x86 only 2016-07-12 13:28:35 ^7heo: other architectures do not have int13 services 2016-07-12 13:29:27 i use gummiboot yes 2016-07-12 13:31:15 i just updated gummiboot version 2016-07-12 13:31:24 to the last commit before it got eaten up by systemd 2016-07-12 13:43:47 hrw, is it so that the arm64 box/bios/bootloader provides dtb (or equivalent) and those are not part of the linux kernel? 2016-07-12 13:44:48 fabled: on aarch64 uefi firmware provides DTB (or not if device boots with with acpi). DTB can be also loaded by bootloader (u-boot, grub-efi). 2016-07-12 13:45:27 and the vendor is expected to supply the dtb for e.g. u-boot ? 2016-07-12 13:45:29 fabled: on my mustang I use DTB from firmware but there were times when I used one from kernel or own one 2016-07-12 13:45:36 ok 2016-07-12 13:45:45 fabled: when you boot u-boot you usually take kernel one 2016-07-12 14:32:01 <^7heo> hrw: interesting. 2016-07-12 14:32:09 <^7heo> hrw: I will come soon to resupply on soplica 2016-07-12 14:32:19 ^7heo: where you are based? 2016-07-12 14:32:21 <^7heo> then I'd be interested to see some stuff, if you're willing to show. 2016-07-12 14:32:24 <^7heo> hrw: bln 2016-07-12 14:32:47 <^7heo> I also have a friend in Szczecin 2016-07-12 14:32:58 <^7heo> So if I come I'll see him too ;) 2016-07-12 14:33:06 <^7heo> so a long week end is better. 2016-07-12 14:33:44 ^7heo: doable. just need to be synced as I will travel during next months (including Berlin probably) 2016-07-12 14:34:38 <^7heo> hrw: ping me if you come 2016-07-12 14:34:52 <^7heo> I'd be happy to show you 'round if you don't know it already. 2016-07-12 14:35:07 ^7heo: LinuxCon Europe and Embedded Linux Conference Europe. if my talks get accepted 2016-07-12 14:35:11 <^7heo> (but if you live in Szczecin you probably know it already) 2016-07-12 14:35:34 <^7heo> The problem with embedded today 2016-07-12 14:35:45 <^7heo> is that an atom with 4GB of ram is considered embedded. 2016-07-12 14:36:01 <^7heo> so it doesn't mean much anymore IMHO 2016-07-12 14:36:10 ^7heo: you are kind of wrong 2016-07-12 14:36:13 <^7heo> am I? 2016-07-12 14:36:25 embedded does not mean 'limited in cpu/io/memory/storage' 2016-07-12 14:36:46 embedded means embedded - small but still powerful 2016-07-12 14:36:47 <^7heo> sure, yes, but? 2016-07-12 14:36:57 <^7heo> mmmh 2016-07-12 14:37:32 <^7heo> the point with having the consideration "embedded" is that you cannot have the same software as with desktop machines. 2016-07-12 14:37:33 if you can squeeze 4GB ram, dualcore, io, emmc/m2 in 80x40mm pcb and use it in a product than it is embedded 2016-07-12 14:37:47 <^7heo> if you could, there would be no point in considering "embedded" software a separate thing. 2016-07-12 14:37:53 <^7heo> (or hardware for the matter) 2016-07-12 14:38:02 <^7heo> so that's why I say what I said 2016-07-12 14:38:08 ^7heo: what we used to call embedded in past is now occupied by microcontrollers like ARM Cortex M 2016-07-12 14:38:15 <^7heo> yeah 2016-07-12 14:38:25 and there is still a place for embedded distros 2016-07-12 14:38:39 <^7heo> I wonder how much the market share of PIC controllers has shrinked during the last 10 years. 2016-07-12 14:38:54 if you make a product with 10 years of life then you want distro which will provide you support for those 10 years 2016-07-12 14:39:07 with all security fixes but without huge changes 2016-07-12 14:39:10 <^7heo> nah sure, that makes sense. 2016-07-12 14:39:23 with sane tested upgrade schemes 2016-07-12 14:39:32 <^7heo> I'm just wondering, honestly wondering. 2016-07-12 14:39:48 <^7heo> because when I studied electronics, and low level programming, we were using PIC controllers 2016-07-12 14:39:52 <^7heo> looks like it's not really up to date anymore. 2016-07-12 14:40:09 if you update 10 devices in a place where update fetching was 10 nights and nearest road is 50km away you prefer not to go there because update failed 2016-07-12 14:40:29 ^7heo: I had pic 16f84 and z80 during studies 2016-07-12 14:40:37 <^7heo> yeah also z80 2016-07-12 14:40:42 <^7heo> I had a really nice book on it. 2016-07-12 14:40:53 <^7heo> and also PIC 16F84 2016-07-12 14:41:02 <^7heo> I wonder when you studied. 2016-07-12 14:41:25 <^7heo> Looks to me that the market didn't change for decades 2016-07-12 14:41:30 nowadays you take cortex-m3/4/7 and if lucky then you can even run linux on it. but probably would go for one of those rtos ones 2016-07-12 14:41:32 <^7heo> and then suddently exploded when smartphone happened. 2016-07-12 14:41:48 ^7heo: graduated in 2001/2002 2016-07-12 14:41:51 <^7heo> s/smartphone/&s/ 2016-07-12 14:42:00 <^7heo> so roughly half a decade before me. 2016-07-12 14:42:01 <^7heo> ok. 2016-07-12 14:42:24 <^7heo> hrw: did you come to the EHSM? 2016-07-12 14:42:29 ehsm? 2016-07-12 14:42:37 <^7heo> http://ehsm.eu/ 2016-07-12 14:42:52 <^7heo> they made 2 editions 2016-07-12 14:42:55 <^7heo> I only went to the first one. 2016-07-12 14:43:06 ^7heo: nope 2016-07-12 14:45:17 fabled, clandmeter: please ping me when you will have any rootfs for aarch64. I may help testing 2016-07-12 14:51:45 <^7heo> hrw: if you stick around, I'll keep you posted, if they do one more. 2016-07-12 14:53:47 ^7heo: kind of not my area 2016-07-12 14:55:36 <^7heo> technically or geographically? 2016-07-12 15:00:40 both ;D 2016-07-12 15:00:48 ACTION -> meeting 2016-07-12 15:02:11 <^7heo> btw, where is the source of algitbot? 2016-07-12 15:59:02 <^7heo> no idea? 2016-07-12 16:38:00 ^7heo: algitbot is everywhere; in air that you breath, in water that you drink… :) 2016-07-12 16:50:34 <^7heo> meeeh 2016-07-12 16:52:00 every breath you take, every meeeh you make 2016-07-12 16:52:07 algitbot will be watching you 2016-07-12 16:52:15 \o/ 2016-07-12 16:52:51 <^7heo> found it. 2016-07-12 16:53:04 <^7heo> its name isn't algibot. 2016-07-12 16:53:07 <^7heo> When you know that, it's easier. 2016-07-12 16:53:32 <^7heo> skarnet: to keep the right metric for the lyrics, you should have used algitbot'll be watchin' you. 2016-07-12 16:55:08 <^7heo> the issue is: sricbot is merely the client (it could be using ii btw) 2016-07-12 16:55:22 <^7heo> I don't find the bot itself... 2016-07-12 16:56:04 al' be watchin' you 2016-07-12 16:56:45 <^7heo> skarnet: better, indeed. 2016-07-12 16:57:56 <^7heo> !ping 2016-07-12 16:57:58 <^7heo> !PING 2016-07-12 18:06:05 *pong 2016-07-12 18:11:04 long roundtrip... 2016-07-12 18:13:16 that's icmp over irc over tcp over ip, what do you expect 2016-07-12 18:18:06 <^7heo> :D 2016-07-12 18:23:12 at least 2 seconds faster 2016-07-12 18:25:22 XD 2016-07-12 21:07:27 I’ve splitted nagios-plugins into subpackages and upgraded… please someone with rights to push main https://github.com/alpinelinux/aports/pull/157 2016-07-12 21:07:41 ncopa or barthalion? 2016-07-12 21:10:01 uh, what a moments, there’s something wrong with deps 2016-07-12 21:11:51 nah, it’s ok 2016-07-12 23:23:53 clandmeter: pkgs.a.o is still broken :( ./db.lua:244: attempt to index local 'stmt' (a nil value) 2016-07-13 05:31:57 jirutka: I understand why you use eval, but it's ugly, is there more packages like this? 2016-07-13 07:09:48 eval is evil yes 2016-07-13 07:09:59 we use eval in lua-* packages 2016-07-13 07:22:44 morning 2016-07-13 07:29:24 ncopa: yeah, but it slightly different way I could live with 2016-07-13 07:29:35 not eval&echo in depends of subpkg 2016-07-13 07:30:00 ah, he wasn't here anyway 2016-07-13 07:30:03 will comment on gh 2016-07-13 07:32:00 but besides depends, looks good 2016-07-13 07:34:51 i tend to agree 2016-07-13 07:36:32 I'll merge it 2016-07-13 07:39:37 ncopa: are there any parameters passed to install scripts, like old and new pkgver? 2016-07-13 07:39:53 i think so yes 2016-07-13 07:45:36 looking at package.c, no 2016-07-13 08:43:14 ncopa: i think /usr/share/udhcpc/default.script is broken 2016-07-13 08:43:29 and it has your name in it :) 2016-07-13 08:52:48 ok? 2016-07-13 08:52:50 whats broke? 2016-07-13 08:54:18 just looking a dhcpc.c - i just don't think it's behaving as it should. i need to check the rfc as well 2016-07-13 08:55:13 but basically, i'd expect "udhcpc -i $interface -o" not to touch /etc/resolv.conf 2016-07-13 08:56:11 ScrumpyJack: still that's correct, DHCP provides a list of DNS caches to contact 2016-07-13 08:56:34 so an udhcpc script is free to modify /etc/resolv.conf if it also changes the default route 2016-07-13 09:00:38 sending dns caches is optional is it not? 2016-07-13 09:00:54 sure is 2016-07-13 09:02:04 allowing DHCP to override DNS (and NTP...) configuration should be a user-configurable option tbh 2016-07-13 09:02:22 udhcpc/default.script writes and empty /etc/resolv.conf if no dns caches are sent to udhcpc 2016-07-13 09:02:56 that's correct if there's no resolv.conf fallback 2016-07-13 09:03:50 the behaviour should be: if the user has said "don't touch my config", do nothing no matter what DHCP says. Else, overwrite resolv.conf even if it empties it. 2016-07-13 09:05:08 "don't touch my config" is what i'd exect udhcpc -o "Don't request and options" to do right? 2016-07-13 09:05:58 s/and/any 2016-07-13 09:19:31 hm, maybe. If udhcpc is run with an explicit order not to provide DNS cache addresses, then its script shouldn't touch /etc/resolv.conf indeed. 2016-07-13 09:23:28 my dhcp server doesn't send option 6 (Domain Server), my dhcp client is asking not to request any options, and my /etc/resolv.conf gets flattened :) something's not right 2016-07-13 09:27:45 kill it with fire 2016-07-13 09:34:04 ScrumpyJack: you can at least put RESOLV_CONF=no in /etc/udhcpc/udhcpc.conf to have resolv.conf unchanged by default.script. 2016-07-13 09:47:31 sure, but there is no /etc/udhcpc/udhcpc.conf file in busybox-initscripts 2016-07-13 09:48:37 ls 2016-07-13 09:48:38 and i think it would probably be better to change default.script's behaviour 2016-07-13 09:50:53 the resolvconf() function in default.script has a echo -n "$RESOLV_CONF" which occurs even if udhcpc doesn't set $dns or $domain 2016-07-13 09:53:28 there are some variables in there like $IF_PEER_DNS and $NO_DNS that are useless (or maybe left over from something else) 2016-07-13 10:16:22 <^7heo> I know you all consider that we have too much crap in the aports 2016-07-13 10:16:26 <^7heo> s/crap/go/ 2016-07-13 10:16:31 <^7heo> but, what about concourse? 2016-07-13 10:31:42 ^7heo: as long as i dont need to maintain it... 2016-07-13 10:32:19 <^7heo> :P 2016-07-13 10:32:35 <^7heo> It would go without saying that I'd maintain it if I submit. 2016-07-13 10:32:41 <^7heo> but I wonder if anyone has any experience with it. 2016-07-13 10:32:50 <^7heo> and it seems to be a tad complicated for a CI system 2016-07-13 10:33:00 <^7heo> it's not just running tests and displaying fancy stats. 2016-07-13 10:33:10 <^7heo> it's doing what travis does. 2016-07-13 10:33:21 <^7heo> (ie. spawning containers too) 2016-07-13 10:33:28 <^7heo> and I wonder how easy that is to make work. 2016-07-13 10:33:35 kunkku: i saw you pushed apache fixes to 3.3-stable. are the same fixes in 3.4-stable? 2016-07-13 10:34:05 <^7heo> for starters 2016-07-13 10:34:14 <^7heo> concourse doesn't have a freaking Makefile. 2016-07-13 10:34:15 <^7heo> v_v 2016-07-13 10:49:45 ncopa: yes 2016-07-13 10:50:08 cherry-picked from there 2016-07-13 10:53:02 ncopa: you have a bunch of tests in resolvconf() in /usr/share/udhcpc/default.script - can you explain where $IF_PEER_DNS and $NO_DNS came from? Can i clean that up if they are not needed? I want to change resolvconf so that it doesn't flatten /etc/resolv.conf by default 2016-07-13 11:04:33 i think NO_DNS is supposed to be a config option in /etc/udhcpc/udhcpc.conf or similar 2016-07-13 11:04:51 IF_PEER_DNS sounds like it comes from ifup, but i dont remember reall 2016-07-13 11:05:09 /etc/udhcpc/udhcpc.conf doesn't exist and nothing provides it. 2016-07-13 11:08:03 it can be created if needed 2016-07-13 11:08:07 its normally not needed 2016-07-13 11:09:21 but if it doesn't exists, and if udhpc doesn't set $dns and $domain, default.script has a echo -n > /etc/resolv.conf 2016-07-13 11:10:08 also udhcpc -o doesn't see to work, but that's something else 2016-07-13 11:21:14 that sounds like a bug 2016-07-13 11:21:28 btw. i'm replacing cdrkit with xorriso 2016-07-13 11:21:32 in alpine-sdk 2016-07-13 11:21:47 i noticed that cdrkit has `file` as dep 2016-07-13 11:21:57 so alpine-sdk will no longer pull in `file` 2016-07-13 11:46:50 ncopa: nice, xorriso is also uefi compat and our current cdrkit isnt. 2016-07-13 11:46:58 ncopa: so when I need file in abuild, I should add it explicitly to makedepends? 2016-07-13 11:47:19 yes 2016-07-13 11:48:09 yes 2016-07-13 11:50:42 ah, I’ve already added it, so it’s okay 2016-07-13 12:07:21 shouldn't default.script also handle other DHCP options? 2016-07-13 12:25:35 ncopa, re #5058, this is how to fix: http://sprunge.us/BDKX 2016-07-13 12:25:43 i've tested it 2016-07-13 12:26:01 but i'd like your opinion before pushing it 2016-07-13 12:34:06 Hi :) 2016-07-13 12:34:23 I found that alpine python/libc have such issue: http://pastebin.ca/3658053 2016-07-13 12:42:41 ncopa: can you also look at patch 2234 for default.script 2016-07-13 12:50:34 ScrumpyJack: not sure i like it 2016-07-13 12:52:16 ok - can you be more specific? :) 2016-07-13 12:55:08 it does (almost) same thing twice 2016-07-13 12:55:16 as i understand 2016-07-13 12:55:36 if $dns is empty, resolv.conf should be left alone? 2016-07-13 12:56:00 yes 2016-07-13 12:56:09 if $domain is set, then add that, if not set, then dont add it 2016-07-13 12:56:33 don't add domain if dns isn't set. 2016-07-13 12:56:40 so 2016-07-13 12:56:53 why not: if [ -z "$dns" ]; then return; fi 2016-07-13 12:57:02 it's more complicated than that 2016-07-13 12:58:53 as long as udhcpc asks for dns addresses, it should modify /etc/resolv.conf even if those addresses are empty 2016-07-13 12:59:01 unless the user has vetoed it 2016-07-13 13:00:26 ok, so perhaps we should fix udhcpc 2016-07-13 13:02:02 it's not udhcpc, it's the script it calls on new lease ^^ 2016-07-13 13:03:18 udhcpc has a -o option which, according to -help , should not ask for options, yet it still passes those options to the script 2016-07-13 13:04:41 and i'm not sure about the behavoir your describe - what does udhcpc actually request? 2016-07-13 13:05:57 if it asks for everything, and only gets certain options back, i'm not sure it should flatten the options it doesn't get back 2016-07-13 13:06:18 it means the DHCP server doesn't provide the information 2016-07-13 13:06:24 so what are you going to do in that case? 2016-07-13 13:07:22 we can try to provide reasonable defaults, but we can't ignore the fact that the user gave the DHCP server authority 2016-07-13 13:13:21 Ao, i'm roaming for example, i request dhcp option-ntp. if i'm not given it, i should flatten my ntp.conf? how does that help me? 2016-07-13 13:13:29 s/Ao/So 2016-07-13 13:16:16 by extention, if my udhcpc client can't be told to request an IP/mask and route only, i should flatten all the options i'm *not* given back? 2016-07-13 13:19:02 "can't be told" ? 2016-07-13 13:20:59 automatically-generated global files are a huge pain anyway; no user file should ever be flattened. /etc/resolv.conf, /etc/ntp.conf etc. should always be backed up before ever launching a DHCP client or anything of the kind. 2016-07-13 13:21:08 I'm asing you for helpful information, if you don't have it, i'm not going to zap the values i already have. If you want to flatten me resolv.conf, send me a loopback 2016-07-13 13:21:57 geez, my fingers are covered in butter it seems :) 2016-07-13 13:22:17 as me harder 2016-07-13 13:23:04 anyway, the heart of the problem is the impossibility for dns/ntp/... config to read information from several sources with varying priorities 2016-07-13 13:23:33 ideally there would be "default DNS information", and "DHCP-supplied DNS information" which would take priority for the lifetime of the lease 2016-07-13 13:24:20 unfortunately the Unix interfaces don't allow that. The best we could do is regenerate /etc/resolv.conf all the time from a user-provided file and the DHCP info., 2016-07-13 13:24:55 also we should call it /var/etc/resolv.conf (with a symlink in /etc/resolv.conf) since it's mutable and / can be read-only. :P 2016-07-13 13:34:21 <^7heo> ncopa: #5893 2016-07-13 13:35:21 I have probably quite a noob question… I have colored prompt, so terminal does support colors and encodes ANSI sequences, but when I use e.g. git diff, I see escape sequences on screen, not colors… why and how to fix it? 2016-07-13 13:36:26 <^7heo> jirutka: are you sure your $TERM is set to something that says that it supports color? 2016-07-13 13:36:27 skarnet: from the DHCP RFC: "if the client receives no parameters from the server that override the defaults, a client uses those default values" 2016-07-13 13:36:43 <^7heo> jirutka: like, I in my case, st-256color 2016-07-13 13:36:48 ^7heo: xterm-256color 2016-07-13 13:36:53 <^7heo> ok 2016-07-13 13:37:00 <^7heo> do you have the relevenat terminfo? 2016-07-13 13:37:02 <^7heo> relevant* 2016-07-13 13:37:30 <^7heo> jirutka: also, is the output of git diff --color colored? 2016-07-13 13:37:54 ^7heo: it’s not 2016-07-13 13:38:04 <^7heo> okay 2016-07-13 13:38:05 ^7heo: I think that there’s some problem with less (pager) 2016-07-13 13:38:08 <^7heo> yeah 2016-07-13 13:38:10 <^7heo> apk add less 2016-07-13 13:38:54 <^7heo> less needs to support the -r option 2016-07-13 13:39:01 busybox’s less does not support -R option 2016-07-13 13:39:09 <^7heo> exactly. 2016-07-13 13:39:17 less package is GNU less… is there any other option? 2016-07-13 13:39:21 <^7heo> (I think it's a lowercase r but whatever) 2016-07-13 13:39:43 <^7heo> jirutka: there was a thread to support raw input in busybox's less version years ago 2016-07-13 13:39:51 <^7heo> that died because of some trolling AFAIR 2016-07-13 13:39:53 ScrumpyJack: ok, I stand corrected 2016-07-13 13:40:03 <^7heo> you might want to ask ncopa for more information. 2016-07-13 13:40:13 <^7heo> jirutka: long story short, no. 2016-07-13 13:40:24 <^7heo> jirutka: unless you make your own. 2016-07-13 13:40:42 <^7heo> or add a patch to the busybox package to support it. 2016-07-13 13:40:55 <^7heo> (AFAIR there was a working patch for it in the busybox ML) 2016-07-13 13:41:13 <^7heo> but of course we would have to maintain that patch. 2016-07-13 13:41:57 <^7heo> jirutka: http://lists.busybox.net/pipermail/busybox/2014-February/080405.html 2016-07-13 13:42:19 I found that thread 2016-07-13 13:42:31 but how the hell is less related to systemd? 2016-07-13 13:42:47 systemd doesn’t work without colours or what? 2016-07-13 13:43:10 <^7heo> because the request for the -r flag was tied to systemd not clever enough to know if it was talking to a TTY or not. 2016-07-13 13:43:29 <^7heo> AFAIR. 2016-07-13 13:43:42 <^7heo> and therefore dumping sh*tloads of escape sequences in the input of less. 2016-07-13 13:46:00 skarnet: I apologise for that 2016-07-13 13:46:39 bad, bad man who dares to correct people when they're wrong! 2016-07-13 13:48:05 I wonder why GNU less needs ncurses… 2016-07-13 13:48:15 i know, how arrogant right? :) 2016-07-13 13:49:00 <^7heo> jirutka: query 2016-07-13 13:50:32 ncopa: are you willing to accept patches to busybox package to add less -R option? 2016-07-13 13:51:04 <^7heo> jirutka: best would be to push it upstream, but given the fuss it made at the time... 2016-07-13 13:51:14 <^7heo> jirutka: I think it would be best to support it ourselves for now, 2016-07-13 13:51:41 ^7heo: they had also some problems with code size of this change 2016-07-13 13:51:43 <^7heo> jirutka: if ncopa isn't willing to maintain that, you could make a second version of that package, anyway. 2016-07-13 13:51:52 <^7heo> jirutka: yeah I read about it. 2016-07-13 13:51:59 <^7heo> 300b instead of <150b 2016-07-13 13:52:04 <^7heo> s/b/B/ 2016-07-13 13:52:08 <^7heo> s/b/B/g 2016-07-13 13:52:36 ^7heo: I really don’t wanna maintain my personal fork of such basic package as busybox 2016-07-13 13:53:01 <^7heo> well, I understand, but if it's just cp, apply patch, commit, push 2016-07-13 13:53:04 <^7heo> that can be done with a script 2016-07-13 13:53:24 ^7heo: if ncopa say no, then I’ll just install GNU less :/ 2016-07-13 13:53:24 <^7heo> unless there's a merge conflict but that's gonna be the same if ncopa maintains it. 2016-07-13 13:53:45 <^7heo> I'd love to have that patch in our busybox, let alone upstream. 2016-07-13 13:53:47 ^7heo: busybox already have many compile flags, so support colored output can be optional 2016-07-13 13:53:57 <^7heo> jirutka: true. 2016-07-13 13:54:13 <^7heo> but the problem here is maintaining the patch along with the busybox base. 2016-07-13 13:54:22 <^7heo> and that will belong to whoever maintains the package... 2016-07-13 13:54:33 <^7heo> hence my idea of a "copy with patch" 2016-07-13 13:54:58 ^7heo: I understand that 2016-07-13 13:56:16 <^7heo> but yeah, I agree that having busybox and busybox-patched is a bit overkill 2016-07-13 13:56:29 <^7heo> we already have -suid -static and -initscripts 2016-07-13 13:56:33 <^7heo> that should be enough. 2016-07-13 13:56:48 <^7heo> esp. if we need to -patched all of them. 2016-07-13 13:56:54 <^7heo> (minus the initscript maybe) 2016-07-13 13:56:58 <^7heo> anyway, back to work. 2016-07-13 14:00:11 alternatively, isolate the "less" command in busybox, the relevant parts of libbb, and the working patch, and make a separate "less" binary that would support -R. 2016-07-13 14:00:43 skarnet: that sounds great… could you please do that? :) 2016-07-13 14:01:12 if I had the slightest interest in getting colored output in busybox less, I definitely would! :P 2016-07-13 14:02:53 skarnet: I thought so :/ 2016-07-13 14:03:34 btw I’ve added QA to FAQ https://wiki.alpinelinux.org/wiki/Alpine_Linux:FAQ#How_to_enable.2Ffix_colors_for_git.3F 2016-07-13 14:11:59 ncopa: http://sprunge.us/DFaJ 2016-07-13 14:12:36 fixes #5058 2016-07-13 14:12:51 jirutka: apk add less 2016-07-13 14:12:58 to get colored git diff 2016-07-13 14:13:00 if you are ok with that, i would push it 2016-07-13 14:16:09 fcolista: looks correct 2016-07-13 14:22:44 hrw, i have now alpine image that works on qemu (given kernel+initramfs directly as files) 2016-07-13 14:22:51 aarch64 that si 2016-07-13 14:42:42 fabled: awesome! 2016-07-13 14:42:46 fabled: can you share it? 2016-07-13 14:43:43 ncopa: I know about this package, but I’d prefer busybox less with -r/-R option 2016-07-13 14:43:49 ncopa: GNU less is quite bloated 2016-07-13 14:46:26 hrw, i'd still like to clean few things 2016-07-13 14:46:42 but yes later this week or early next week i should have something shareable 2016-07-13 14:50:07 fabled: thanks, no rush 2016-07-13 17:10:21 seems like I can no longer pull from git.a.o. Is it just me or does someone else have issues with it? 2016-07-13 17:12:55 via git protocol, so probably the git daemon has gone down? 2016-07-13 17:50:46 chris|, restarted git-daemon, seems better now 2016-07-13 17:52:06 looks good, thanks 2016-07-13 18:02:00 and that's one of the reasons why supervision is useful. (Just saying.) 2016-07-13 18:03:05 is there some way how to set key repeat (e.g. when I press and holt Alt + →, I want to start skipping words until I release the keys) without installing huge kbd package? 2016-07-13 18:03:40 skarnet: actually, no, there’s a reason why external monitoring of services is useful 2016-07-13 18:04:05 that is true and does not contradict what I wrote 2016-07-13 18:04:17 skarnet: supervisor cannot (should not) check if the service is really functional (e.g. it do what it should do), just if the process is running or not 2016-07-13 18:04:54 teach me more about supervision, senpai 2016-07-13 18:05:52 skarnet: I now that you know service supervisors much much better than me… 2016-07-13 18:06:45 skarnet: what about repeating keys, do you have some suggestion? 2016-07-13 18:07:28 I've done that stuff once, 15ish years ago, and haven't looked back since, so honestly I don't remember and it has probably changed... 2016-07-13 18:08:03 kbd is the current name of the package that handles keyboard mappings, console fonts etc? 2016-07-13 18:09:46 check whether there isn't a suitable command in busybox 2016-07-13 18:10:00 (busybox.net looks down -_-) 2016-07-13 19:23:31 jirutka: you around? 2016-07-13 19:23:43 boingolov: yeah, what’s up? 2016-07-14 03:12:59 crap, heh 2016-07-14 13:50:08 stateless: there is a problem with fortify headers 2016-07-14 13:50:19 http://bugs.alpinelinux.org/issues/5899 2016-07-14 13:50:22 i can reproduce it 2016-07-14 13:52:43 $ echo "#include " > try.c && cc -c try.c 2>&1 | tpaste 2016-07-14 13:52:43 http://tpaste.us/2Dzo 2016-07-14 13:53:08 if i remove fortify-headers it will success 2016-07-14 13:56:44 adding -O2 makes error go away too 2016-07-14 13:57:16 indeed 2016-07-14 13:57:20 thats interesting 2016-07-14 13:57:50 i suppose the test is to verify if the header exist, so it should probably use cpp instead 2016-07-14 13:58:23 #if defined(_FORTIFY_SOURCE) && _FORTIFY_SOURCE > 0 && defined(__OPTIMIZE__) && __OPTIMIZE__ > 0 2016-07-14 13:58:29 must be something to do with that #if 2016-07-14 13:59:49 could gcc bug too 2016-07-14 14:16:22 i think its __extension__ that triggers it 2016-07-14 14:43:16 stateless: I think this fixes it: http://tpaste.us/GBzy 2016-07-14 14:59:43 ncopa, does this workaround need to happen in all the other fortify-headers that use __extension__ too? 2016-07-14 15:00:16 i checked, but it looks like wchar.h is the only candidate 2016-07-14 15:00:22 but it does not happen there 2016-07-14 15:00:32 i suppose it depends on what is in the header 2016-07-14 15:00:46 why does it trigger on headers that include_next limits.h> 2016-07-14 15:00:48 ? 2016-07-14 15:00:58 i dont know 2016-07-14 15:01:17 i think gcc expects ientifier after __extenstion__ 2016-07-14 15:01:28 and #include_next apparently does not qualify as identifier 2016-07-14 15:02:11 when the -O2 is set so we actually pull in fortify headers, then it does not happen 2016-07-14 15:05:12 ncopa, so in your patch if you build the same test.c with -O0 does it include stdlib.h from musl directly? 2016-07-14 15:05:47 i meant limits.h 2016-07-14 15:06:00 it means that limits.h will not be included i mean 2016-07-14 15:06:18 correct 2016-07-14 15:06:23 which is the point 2016-07-14 15:06:53 with -O0 the fortify is not enabled, so we don't need PATH_MAX 2016-07-14 15:07:04 ok 2016-07-14 15:07:14 and per posix it says that stdlib.h may include limits.h so it is not required 2016-07-14 15:07:26 i can apply the patch 2016-07-14 15:07:28 #if defined(_FORTIFY_SOURCE) && _FORTIFY_SOURCE > 0 && defined(__OPTIMIZE__) && __OPTIMIZE__ > 0 2016-07-14 15:07:48 can you verify that wchar.h needs the same fix? 2016-07-14 15:07:48 the __OPTIMIZE__ > 0 there is what enables/disables fortify 2016-07-14 15:07:52 yup 2016-07-14 15:07:53 i tested it 2016-07-14 15:08:01 but it didnt happen with wchar.h 2016-07-14 15:08:08 interesting 2016-07-14 15:08:15 indeed 2016-07-14 15:08:22 i dont have time to dig deeper now 2016-07-14 15:08:26 need to go 2016-07-14 15:08:35 i will apply the patch for now 2016-07-14 15:08:40 thanks 2016-07-14 15:08:44 and make a new release 2016-07-14 15:11:24 http://dl.2f30.org/releases/fortify-headers-0.8.tar.gz 2016-07-14 16:37:39 Happy Holidays if you have any! See you in 3 weeks! :P 2016-07-14 16:39:13 just rub it in, won't you? 2016-07-14 16:40:22 what kind of holidays people have at this time of year? 2016-07-14 16:41:16 some people manage to believe it's summertime 2016-07-14 16:41:30 it's not exactly clear when I look out the window 2016-07-14 16:41:40 hard to do so with that wind and rain outside 2016-07-14 16:42:21 I rather hoped it's kind of "National Day of Gouda Cheese" somewhere 2016-07-14 16:42:35 you have to travel to find that shiny things outside 2016-07-14 16:42:44 more like "National Day of Camembert Cheese" today 2016-07-15 00:35:37 paging all alpine devs 2016-07-15 00:36:16 do any of you have old 586 hardware? especially any K6-based laptop hardware 2016-07-15 01:21:23 https://bugs.alpinelinux.org/issues/5906 2016-07-15 01:21:25 well 2016-07-15 01:21:29 ill just put this here 2016-07-15 07:10:48 ncopa: where are you? 2016-07-15 07:14:23 hmm 2016-07-15 07:14:33 looks like its more of musl libc's fault 2016-07-15 07:14:35 http://sprunge.us/XUMM 2016-07-15 07:16:17 i want to hug fabled, but he isn't here. 2016-07-15 07:19:36 kazblox: does an actual 586 count? http://1.bp.blogspot.com/-BNXR7dZBb7I/VaXDHmHq3FI/AAAAAAAAh7U/sWJysnKz5VE/s1600/IMAG2009.jpg 2016-07-15 07:19:52 kazblox: can try to get an alpine image on it this weekend, if you think it might help your case, but not sure it is needed 2016-07-15 07:19:53 yes 2016-07-15 07:20:22 mobile pentium 100mhz on that baby, boots my custom linux (musl based) in 3.4 seconds :) 2016-07-15 07:20:54 awilfox: just trying to debug out an xf86-video-vesa issue when launching apps like dillo or st 2016-07-15 07:21:04 awilfox: >3.4 seconds 2016-07-15 07:21:05 holy shit 2016-07-15 07:21:20 give me your whole fs image 2016-07-15 07:21:24 kazblox: haha :D 2016-07-15 07:23:10 kazblox: maybe when it is ready, I can link you to an .iso, it is sort of alpine-based distro but with more focus on desktop 2016-07-15 07:23:17 but right now, you're better off with alpine 2016-07-15 07:23:31 yeah 2016-07-15 07:23:56 alpine has good potential, what's sucking is no official neomagic xorg package...... 2016-07-15 09:06:19 damn, there is no maven package? 2016-07-15 09:06:35 ah... it is... but not on arm :( 2016-07-15 09:12:18 ncopa: how is it defined which packages are getting built on edge for arm? 2016-07-15 09:12:55 i wanted to package jitsi-meet, a browser based video conferencing tool :( 2016-07-15 09:13:25 ah and to the arm thing... multiple packages maintained by me are not built for arm which sucks. 2016-07-15 09:13:49 mosez, we try to build all, but there are some packages that did not build so we just disabled those as we did not have to fix it 2016-07-15 09:14:16 we also have good arm news, we just booted Aarch64 on real hw :D 2016-07-15 09:14:35 kudos to fabled of course 2016-07-15 09:15:18 http://pkgs.alpinelinux.org/packages?name=&branch=&repo=&arch=&maintainer=Thomas+Boerger hugo, all python based == arch="all", 2016-07-15 09:15:43 cloudfoundry-cli got also arch=all and is not built on arm 2016-07-15 09:16:02 that's why i'm asking. 2016-07-15 09:16:22 terraform have been disabled but i don;t really know why since amd64 and arm built totally fine for me. 2016-07-15 09:17:02 sassc is the only package from me that have been built on arm 2016-07-15 09:17:06 currently arm edge builder is offline 2016-07-15 09:17:14 so if it's recent push, that might be the cause 2016-07-15 09:17:24 seems it loses it's IP for some reason 2016-07-15 09:17:28 i'll upgrade the box on Monday 2016-07-15 09:17:54 last build date is 8th july 2016-07-15 09:18:41 i really don't want to blame anybody. just asking why it's not built and if we can do something to change it :) 2016-07-15 09:19:07 and for the maven java carp i have to use docker locally for building on x86_64 2016-07-15 09:19:14 s/carp/crap/ 2016-07-15 09:48:25 clandmeter, ncopa: have you seen https://github.com/alpinelinux/alpine-mksite/pull/1 ? 2016-07-15 09:49:49 i think ive seen iut 2016-07-15 09:50:05 I will commit changes next week our www 2016-07-15 09:50:07 ill add it. 2016-07-15 09:50:26 we will include a sponsors page from now on. 2016-07-15 09:51:17 im not so sure i totally agree with that PR 2016-07-15 09:51:50 it makes sense to me 2016-07-15 09:52:27 but it's not my turf to decide 2016-07-15 10:00:55 it makes sense to some extend. 2016-07-15 10:01:58 Please remove all the fun language from every site. Computing is serious business, and nobody wants to be seen as people having fun by decision makers in suits and ties! 2016-07-15 10:02:18 Let's just go all corporate bland! 2016-07-15 10:35:09 :) 2016-07-15 10:36:14 the problem is that when you deal with multicultural audience, you do need be very clear or you will be misunderstood. 2016-07-15 10:36:32 barthalion, clandmeter: i'm with fixing the text on the site 2016-07-15 10:45:55 yeah, some people tends to be “offended” by basically anything… 2016-07-15 10:52:26 could please someone merge https://github.com/alpinelinux/aports/pull/162 (into main)? 2016-07-15 11:17:00 except nobody said about being offended here, but I disgress 2016-07-15 11:32:26 I am offended by the suggested change 2016-07-15 12:53:07 hey friends :) 2016-07-15 13:04:11 hey :-) 2016-07-15 13:06:10 leo-unglaub: hey, long time to see you! 2016-07-15 13:06:44 leo-unglaub: there are some rusty news https://github.com/rust-lang/rust/issues/31322#issuecomment-231160839 2016-07-15 13:08:33 yeeeeyyyy 2016-07-15 13:08:40 failed in the last step? 2016-07-15 13:08:45 well, thats pretty close :) 2016-07-15 13:19:12 I am trying examples from, 2016-07-15 13:19:12 http://uwsgi-docs.readthedocs.io/en/latest/WSGIquickstart.html#deploy-it-on-http-port-9090 2016-07-15 13:19:15 did `apk add uwsgi-python` on AL v3.3 but still could not get it work, any ideas ? 2016-07-15 13:25:11 vkris: use AL v3.4, I’ve alreay fixed it 2016-07-15 13:25:28 ok 2016-07-15 13:25:29 vkris: but IIRC we haven’t ported it back to 3.3 2016-07-15 13:35:43 I think it tries to find 'http_plugin.so' 2016-07-15 13:36:04 http://pkgs.alpinelinux.org/contents?file=http_plugin.so&path=&name=&branch=v3.4&repo=&arch= 2016-07-15 13:36:12 not there 2016-07-15 13:36:40 paste your uwsgi config 2016-07-15 13:37:27 uwsgi --plugin-dir '/usr/lib/uwsgi' --plugin 'python,http' --http :9090 --wsgi-file foobar.py 2016-07-15 13:37:48 why do you need http here? 2016-07-15 13:37:57 use nginx 2016-07-15 13:38:03 have not crated/touched any configs yet 2016-07-15 13:38:17 you mean http-socket ? 2016-07-15 13:38:35 ? 2016-07-15 13:38:45 we don’t have uwsgi-http aport 2016-07-15 13:39:12 uwsgi is usually used behind some http proxy like nginx, 2016-07-15 13:40:00 ok would try with socket configs 2016-07-15 13:40:10 with nginx 2016-07-15 13:40:26 http://uwsgi-docs.readthedocs.io/en/latest/WSGIquickstart.html#putting-behind-a-full-webserver 2016-07-15 13:40:43 hm, wait a moment, it already exposes HTTP… I use just standard http proxy in nginx 2016-07-15 13:42:34 there’s no real difference between using TCP port or unix socket for HTTP in uwsgi 2016-07-15 13:43:03 aha, you mean --socket option in uwsgi, it’s just quite confusing naming 2016-07-15 13:43:36 so how to start a simple app, as here: http://uwsgi-docs.readthedocs.io/en/latest/WSGIquickstart.html#the-first-wsgi-application 2016-07-15 13:43:48 maybe this will help as an example https://github.com/jirutka/change-password#run-with-uwsgi-and-nginx 2016-07-15 13:44:18 just remove http from --plugin 2016-07-15 13:44:49 uwsgi --plugin-dir '/usr/lib/uwsgi' --plugin 'python' --http :9090 --wsgi-file foobar0. 2016-07-15 13:44:52 py 2016-07-15 13:44:54 uwsgi: option is ambiguous: http 2016-07-15 13:45:46 getopt_long() error 2016-07-15 13:48:42 I’ll look at it later, I must refresh my knowledge of uwsgi configuration 2016-07-15 13:52:57 ok thanks, now trying with config.ini + nginx rather than command line 2016-07-15 13:54:20 btw use plugin python (as you already uses), not python34 (my config snippet is for gentoo) 2016-07-15 13:54:40 ok 2016-07-15 14:05:43 I wonder why we don’t build http plugin in uwsgi package 2016-07-15 14:10:02 okay, I’ll put it on my TODO list to add more plugins to uwsgi package 2016-07-15 14:10:45 awilfox: maybe put the patches back into alpine too? 2016-07-15 14:10:59 :) 2016-07-15 14:11:00 instead of fork overload :( 2016-07-15 14:12:57 while at it pls consider adding, tuntap,sqlite3,webdav,syslog,msgpack,logsocket,logpipe 2016-07-15 14:13:28 and some routers(generic ones) 2016-07-15 14:14:52 and php if it does not hurt ;) 2016-07-15 14:15:26 ok in config.ini, socket = 127.0.0.1:3031 works 2016-07-15 14:15:37 but not socket = '/run/uwsgi/main.sock' 2016-07-15 14:30:32 vkris: okay, I’ll add all that you named, except php :P 2016-07-15 14:30:45 vkris: wait a moment, sqlite in uwsgi? o.O 2016-07-15 14:31:32 vkris: you really want to load uwsgi configuration from sqlite database? o.O uh… 2016-07-15 14:31:56 vkris: anyway, does it work for you in wsgi mode with nginx? 2016-07-15 14:33:58 vkris: btw when I wrote that uwsgi already exposes HTTP… I looked at Sentry that uses uwsgi and it exposes HTTP port, but… to be honest, I have no clue how it currently works… because there’s really needed to have http plugin in uwsgi to expose HTTP 2016-07-15 14:34:22 vkris: and in all other cases I uses just wsgi interface with nginx as a proxy 2016-07-15 14:36:35 yes it works, but I need to set plugin dir in cmd line 2016-07-15 14:37:06 seems plugin dir is not known to it 2016-07-15 14:37:22 maybe needs setting during compile 2016-07-15 14:38:09 this works -> uwsgi --plugin-dir '/usr/lib/uwsgi' --plugin 'python' config.ini 2016-07-15 14:38:23 + socket = 127.0.0.1:3031 2016-07-15 14:38:33 + nginx 2016-07-15 14:38:33 jirutka: are you around? 2016-07-15 14:38:42 boingolov: yeah 2016-07-15 14:38:58 have you had a chance to look at this: https://github.com/alpinelinux/aports/pull/137 2016-07-15 14:39:08 vkris: that’s what I’ve fixed recently, it should not be needed to set plugin dir anymore 2016-07-15 14:39:12 I made some changes several days ago that (hopefully) addressed your concerns 2016-07-15 14:39:45 vkris: https://github.com/alpinelinux/aports/commit/900a4a14d0571359072303ba61899518f2b7d699 2016-07-15 14:40:23 pls have a look at why socket = /run/uwsgi/main.sock does not work 2016-07-15 14:40:28 boingolov: uh, yeah, sorry for that, I’m very busy now and this packages is not easy to make it right 2016-07-15 14:40:45 boingolov: I’ll try to finish it during weekend 2016-07-15 14:40:49 yeah, it's an odd duck 2016-07-15 14:41:01 bind(): No such file or directory [core/socket.c line 230] 2016-07-15 14:41:14 boingolov: I’ve been looking at init script, how to properly start and stop it 2016-07-15 14:41:20 and yeah, I got very busy after I initially submitted and didn't touch it for a couple of weeks, but just recently pushed changes 2016-07-15 14:41:52 vkris: does /run/uwsgi exists and is it writable for the users running uwsgi? 2016-07-15 14:42:05 I did update the init script, but the stop command is still pretty nasty 2016-07-15 14:42:31 but that's the only way I could figure to get stdout and stderr redirected to the file in the same manner that the upstream init script works (at least from the official rpm spec file) 2016-07-15 14:42:56 but at least there is no & ;) 2016-07-15 14:44:40 boingolov: I’ve seen it, start() looks ok-ish now 2016-07-15 14:45:34 --stdout and --stderr are only valid for the start command apparently 2016-07-15 14:45:41 not sure why 2016-07-15 14:45:55 but it seems to be a restriction of start-stop-daemon 2016-07-15 14:47:04 boingolov: because it doesn’t make sense for stopping the daemon; it’s already running so it has already redirected stdout/stderr 2016-07-15 14:48:19 boingolov: although it’s possible to change destination of stderr/stdout of already running process, it’s basically hacking… and not really need here 2016-07-15 14:49:15 I'm not sure how much sense it makes honestly, but that's how they do it in their "official" release 2016-07-15 14:49:22 `start-stop-daemon --stop` is not designed for running some random script, but for stopping a process started by start-stop-daemon 2016-07-15 14:49:30 yeah 2016-07-15 14:49:58 boingolov: these scripts in “official” release does not use start-stop-daemon, does they? 2016-07-15 14:50:06 no 2016-07-15 14:50:29 but there are similar facilities available in systemd 2016-07-15 14:50:32 boingolov: and also their scripts are a bloated mess… unfortunately it’s quite typical for most of the software :( 2016-07-15 14:51:12 I'm not a big fan of a lot of the way they package their software, but the software itself is very good (imo) 2016-07-15 14:51:39 oh crap, I must go to catch the train 2016-07-15 14:51:43 later 2016-07-15 14:51:43 too late as usual :( 2016-07-15 14:52:32 no uwsgi.ini, http://pkgs.alpinelinux.org/contents?file=uwsgi.ini&path=&name=&branch=&repo=&arch= 2016-07-15 14:52:39 I think starting services that run under erlang beam is similarly tricky as starting java apps under tomcat 2016-07-15 14:52:42 boingolov: I believe that, RabbitMQ seems nice and it’s written in Erlang, probably the best lang for such software 2016-07-15 14:52:46 I've yet to see an elegant init script for java 2016-07-15 14:53:08 install -D "$srcdir"/uwsgi.ini \ 2016-07-15 14:53:08 "$pkgdir"/etc/uwsgi/uwsgi.ini return 1 2016-07-15 14:54:14 boingolov: https://github.com/alpinelinux/aports/blob/master/community/jetty-runner/jetty-runner.initd, https://github.com/jirutka/spring-boot-openrc/blob/master/spring-boot.initd 2016-07-15 14:54:29 likely not in source 2016-07-15 14:54:44 jetty is a lot simpler than tomcat, for sure 2016-07-15 14:54:59 boingolov: the problem of most of such scripts is that they tries to make it work on every unix in universe, even some ancient that doesn’t exist anymore, and on systems with just crappy SysV init 2016-07-15 14:56:02 boingolov: tomcat, but this script is quite old https://github.com/cvut/gentoo-overlay/blob/master/dev-java/tomcat-scripts/files/runscript.sh-0.4 2016-07-15 14:57:06 cool 2016-07-15 14:57:21 yes worked with socket file, just moved to /tmp/uwsgi.sock 2016-07-15 14:57:49 don't need to bother for permission issue 2016-07-15 14:58:23 atleast I know, what are issues now 2016-07-15 14:58:40 hope he caught his train ;) 2016-07-15 15:24:57 boingolov: uff, this was quite close 2016-07-15 15:25:32 boingolov: okay, I should note that each runscript has also second half, conf file https://github.com/alpinelinux/aports/blob/master/community/jetty-runner/jetty-runner.confd, https://github.com/jirutka/spring-boot-openrc/blob/master/spring-boot.confd 2016-07-15 17:47:51 jirutka: re config file, rabbitmq doesn't ship with one by default, also doesn't really need one by default. Many don't use it, unless certain plugins are configured (eg, shovel) 2016-07-15 17:48:31 some of the configuration is done with some of those lovely shell scripts that ship with it 2016-07-15 17:48:40 other bits are done via web ui 2016-07-15 17:49:20 boingolov: IIRC rabbitmq includes some shell script with user-defined variables… 2016-07-15 17:49:51 do you mean the rabbitmqctl script? 2016-07-15 17:49:55 yes 2016-07-15 17:50:22 yeah, that is actually mangled / generated during the package() in that APKBUILD 2016-07-15 17:50:40 using that sed lovliness (lifted from the SPEC file) 2016-07-15 17:52:07 anyway, I’ve sent you these links just as an example how can init scripts for java apps looks 2016-07-15 17:52:12 I'm not sure that the SPEC file is checked into their repo, are you interested in seeing it? I could gist it 2016-07-15 17:52:29 dunno, what spec file? 2016-07-15 17:52:35 for rabbitmq-server 2016-07-15 17:52:41 they maintain a SPEC file for rpm builds 2016-07-15 17:53:28 yeah, I’ve seen it 2016-07-15 18:16:27 hi 2016-07-15 18:16:40 does alpine 3.4 still use grsec? 2016-07-15 18:17:18 shafire: sure 2016-07-15 18:17:38 good 2016-07-15 18:27:18 hey :) 2016-07-15 18:27:23 jirutka: ping 2016-07-15 18:28:18 leo-unglaub: pong 2016-07-15 18:30:10 sorry, but i had to go before ... 2016-07-15 18:30:13 someone using alpine on any odroid? 2016-07-15 18:30:46 what was the arm build hardware again? I forgot 2016-07-15 19:12:39 does alpine 3.4 still use grsec? 2016-07-15 19:12:41 yes 2016-07-15 19:41:28 I remember: wandboard was it, or? 2016-07-15 19:42:54 hi guys. i just installed alpine on hp thin client and i'm having problems with apk. everytime i want to add a package it wants to download 'linux-firmware'. I don't have space for that. what to do? 2016-07-15 19:49:44 could you guys please help me? apart from that alpine works just fine. It's just that I can't install anything. 2016-07-15 20:08:29 shafire: long time no see 2016-07-15 20:08:45 shafire: yes, wandboards; yes, I have odroid xu4; no, I didn't try to install Alpine on it yet 2016-07-15 20:10:20 extinct_potato: quick idea, no idea if it works 2016-07-15 20:10:29 extinct_potato: apk add apk-tools -t linux-firmware 2016-07-15 20:10:47 will try in a second 2016-07-15 20:11:25 No, it still wants to download linux-firmware 2016-07-15 20:12:07 hm 2016-07-15 20:12:44 building a package is rather hopeless in your situation 2016-07-15 20:12:51 I guess it can be hacked around somehow, will check 2016-07-15 20:12:59 what pulls linux-firmware? 2016-07-15 20:13:52 From what I remember the installer wanted to download it during the installation process, but 'no space left on device' stopped him. 2016-07-15 20:14:01 So it didn't install it. 2016-07-15 20:14:09 yeah, it's kernel dependency 2016-07-15 20:14:20 Maybe that's way apk tries to pull it everytime. 2016-07-15 20:14:38 Why would I need it? 2016-07-15 20:14:46 The system runs just fine. 2016-07-15 20:15:21 I mean, I know why I would need it - for graphics, etc. But I do not intend to run X server on that machine anyway. 2016-07-15 20:15:36 yeah, I get it 2016-07-15 20:16:04 Also my space is quite limited - 256MB ATA flash disk ;/ 2016-07-15 20:16:18 extinct_potato: hm, try to remove linux-grsec (or linux-vanilla) from /etc/apk/world… but to be honest, I’m not sure what it will do 2016-07-15 20:16:48 Okay, give me a second.. 2016-07-15 20:16:49 jirutka: I wonder why adding linux-firmware there doesn't make apk happy 2016-07-15 20:17:19 barthalion: hm, me neither 2016-07-15 20:17:47 I don’t know apk internals yet 2016-07-15 20:18:07 jrutka : it.. worked? yeah it works. 2016-07-15 20:18:12 interesting 2016-07-15 20:18:21 I just installed nano without any problems. 2016-07-15 20:18:22 and do you still have a kernel? :) 2016-07-15 20:18:36 It purged linux-grsec 2016-07-15 20:18:42 so no 2016-07-15 20:18:45 so I am not sure 2016-07-15 20:18:46 uh… 2016-07-15 20:18:55 do you still have kernel files in /boot? 2016-07-15 20:19:15 intramfs-grsec seems to be present 2016-07-15 20:19:50 and vmlinuz-virtgrsec ? 2016-07-15 20:20:00 no.. 2016-07-15 20:20:03 pardon, vmlinuz-grsec 2016-07-15 20:20:05 in your case 2016-07-15 20:20:35 I don't have it either way 2016-07-15 20:20:46 than do not reboot… 2016-07-15 20:20:48 :D 2016-07-15 20:21:01 Yeah :D 2016-07-15 20:21:13 Wait if I copied vmlinuz-grsec from ISO? 2016-07-15 20:21:23 you need modules too 2016-07-15 20:21:32 apk add vmlinuz-grsec ? 2016-07-15 20:21:42 wait, I will try 2016-07-15 20:22:04 looks like we all could use a dive into apk source code 2016-07-15 20:22:21 vmlinuz-grsec (missing : required by world[vmlinuz-grsec] 2016-07-15 20:22:29 linux-grsec 2016-07-15 20:22:33 pardon, apk add linux-grsec 2016-07-15 20:23:10 Shoot, I starts downloading linux-firmware again 2016-07-15 20:25:39 possible ugly workaround: empty package 2016-07-15 20:26:51 jirutka: do you have better idea? 2016-07-15 20:28:25 barthalion: maybe modify linux-grsec package, remove dependency on linux-firmware, or just hack APKINDEX… but I don’t know about any non-hackish solution :/ 2016-07-15 20:28:58 barthalion: my previous idea made it even worse, so I’m afraid to suggest another one now :/ 2016-07-15 20:29:49 removing linux-firmware dependency from kernel packages can be a breaking change for other users 2016-07-15 20:29:59 Empty package seems a nice idea. 2016-07-15 20:30:19 I would have to create my own repo with this package, right? 2016-07-15 20:30:54 if extinct_potato can somehow revert to the previous state, then he can try to backup /boot, /usr/lib/linux-*/, and /lib/modules, then remove linux-grsec package and restore these files 2016-07-15 20:31:06 extinct_potato: not needed, you can do it locally 2016-07-15 20:31:09 and cut off updates, but yeah 2016-07-15 20:31:46 extinct_potato: https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package 2016-07-15 20:32:09 uh, he doesn't have place for linux-firmware 2016-07-15 20:32:16 right, so empty package linux-firmware is a better idea 2016-07-15 20:32:17 I doubt alpine-sdk will fit either 2016-07-15 20:32:35 I could do a dummy installation in VirtualBox. 2016-07-15 20:32:42 okay, then do it on another Alpine system and just copy resulted .apk 2016-07-15 20:32:58 and keys? 2016-07-15 20:33:17 he doesn’t have space for keys? ;) 2016-07-15 20:33:33 right, allow-untrusted 2016-07-15 20:33:35 fair point 2016-07-15 20:33:36 no 2016-07-15 20:33:46 then how do you want to install it? 2016-07-15 20:33:47 just copy the key from other system used to build the pakage 2016-07-15 20:34:01 so that's what I meant before 2016-07-15 20:34:16 extinct_potato: you can use https://github.com/andyshinn/docker-alpine-abuild if you don't have Docker-hatred disease 2016-07-15 20:34:22 this is not the same as allow-untrusted 2016-07-15 20:34:37 I don't mind docker, except I have never used it before. 2016-07-15 20:35:22 But what keys are you talking about? 2016-07-15 20:35:32 Does .apk have to be signed? 2016-07-15 20:35:48 yes 2016-07-15 20:35:49 yes 2016-07-15 20:35:59 it's all quite nicely described in docker-alpine-abuild README 2016-07-15 20:36:02 generate your security key using abuild-keygen 2016-07-15 20:36:29 use this key when building your own package and then copy it to your target system’s /etc/apk/keys 2016-07-15 20:37:34 extinct_potato: https://paste.xinu.at/8PKK/ 2016-07-15 20:37:59 kay, give me a couple of minutes, I need to read the wiki. 2016-07-15 20:38:35 'pkgver' is incorrect 2016-07-15 20:38:47 or is it? 2016-07-15 20:39:02 no, it should be fine 2016-07-15 20:39:27 apk says it is 20160516-r0 2016-07-15 20:39:44 I strongly hope apk does version comparison 2016-07-15 20:39:54 so yours will be newer 2016-07-15 20:40:07 ohh, yeah, I hope so. 2016-07-15 20:40:10 if it does not, it doesn't really matter 2016-07-15 20:40:16 yes it does version comparison 2016-07-15 20:40:23 apk does version comparison :) 2016-07-15 20:47:25 lol 2016-07-15 20:47:37 aww man, that docker thing is going to drive me crazy. 'docker: Cannot connect to the Docker daemon. Is the docker daemon running on this host?.' 2016-07-15 20:47:46 military putsch in turkey 2016-07-15 20:48:41 extinct_potato: fedora? you can go with virtual machine either, it's up to you 2016-07-15 20:48:49 nope, Xubuntu 2016-07-15 20:49:02 yeah, i'll go with virtualbox instead 2016-07-15 20:57:47 or you can just use plain simple chroot 2016-07-15 20:58:53 https://github.com/alpinelinux/aports/blob/master/.travis/install-alpine 2016-07-15 21:00:50 no need to do that. it's already installing in a vm ;) 2016-07-15 21:05:47 http://dl-cdn.alpinelinux.org/alpine/v3.4/main/x86_64/apk-tools-static-2.6.6-r1.apk → 404… 2016-07-15 21:10:05 damn. it takes so long to download the files in alpine installer. 2016-07-15 21:10:13 my internet connection is horrible. 2016-07-15 21:10:28 1mbit/s, 1,5 mbit at it's best. 2016-07-15 21:15:27 well, now it's just weird. Alpine Linux VM occupies 100% of my CPU. 2016-07-15 21:15:30 that’s not an internet connection… that’s a torture connection… 2016-07-15 21:15:57 What the heck, doesn't the kernel implement CPUIDLE? 2016-07-15 21:16:51 well no wonder my hp thinclient is hot as a saucepan. 2016-07-15 21:17:20 yeah, I give up I guess. Anyway, thanks for the support, I guess we both learned something today. 2016-07-15 21:23:03 :( 2016-07-15 21:24:28 <^7heo> jirutka: then I have a torture connection too 2016-07-15 21:24:46 we should do something about the kernel… it’s incredibly large :/ maybe we can detect what modules are actually used and remove the rest 2016-07-15 21:25:20 that's pretty much the bane of general-purpose distros: they have to provide a kernel for all kinds of machines 2016-07-15 21:25:35 <^7heo> jirutka: that's faster and more reliable to use bsd 2016-07-15 21:25:49 I’m used to configure and compile kernel yourself, but it’s not acceptable option for ordinal users :/ 2016-07-15 21:25:55 same here 2016-07-15 21:26:22 all you can do is modularize like hell and only auto-pull in the needed modules 2016-07-15 21:26:39 so you don't use up too much RAM, but you still use a lot of disk 2016-07-15 21:26:46 Alpine kernel is already modularized as hell… look into /lib/modules 2016-07-15 21:27:06 and still the kernel is very large? I'm afraid there's not much you can do about it 2016-07-15 21:27:26 when you install from ISO image, you can detect what modules are loaded and do not install useless modules to the disk 2016-07-15 21:27:47 apart from distributing specially-crafted, trimmed kernels for specific types of machines 2016-07-15 21:27:58 I mean modularized like it uses kernel modules, not modularized in a sense that every modules is packaged as a alpine package :) 2016-07-15 21:28:39 https://pkgs.alpinelinux.org/package/v3.4/main/x86_64/linux-grsec is 138 MiB 2016-07-15 21:28:58 does that include /lib/modules? 2016-07-15 21:29:03 this depend on https://pkgs.alpinelinux.org/package/v3.4/main/x86_64/linux-firmware, another 142 MiB 2016-07-15 21:29:06 this is totally insane 2016-07-15 21:29:20 it's disk 2016-07-15 21:29:29 I don't like it, but at least it's just disk space 2016-07-15 21:29:31 <^7heo> wait wat? 2016-07-15 21:29:31 I have kernels that are not larger than 5 MiB on disk, with no modules 2016-07-15 21:29:41 well, but Alpine is also for embedded devices… 2016-07-15 21:30:16 that user who asked us for help just an hour ago has some device with just 256 MiB of disk space 2016-07-15 21:30:18 tbh, embedded devices shouldn't use any pre-made distro, no matter what it is 2016-07-15 21:30:29 i disagree 2016-07-15 21:30:40 but embedded devices may need custom kernel image 2016-07-15 21:30:51 <^7heo> jirutka: the whole 3.4.1 is 87 M on download 2016-07-15 21:31:00 I agree, as I said, I usually don’t use bloated distribution kernels, but unfortunaly this is not acceptable for most users :( 2016-07-15 21:31:05 <^7heo> I don't get it 2016-07-15 21:31:18 kaniini: you'll end up doing one custom kernel image per existing embedded device 2016-07-15 21:31:19 ^7heo: what yo don’t get? 2016-07-15 21:31:54 <^7heo> how the kernel can be 138MB 2016-07-15 21:32:02 <^7heo> and the iso 87 2016-07-15 21:32:16 I dunno… 2016-07-15 21:32:36 eh, ISO is larger… 2016-07-15 21:32:42 actually, we have more ISOs 2016-07-15 21:32:45 <^7heo> 138 sounds about 20 times too much imho 2016-07-15 21:32:52 there’s one for VMs, that’s small 2016-07-15 21:33:23 <^7heo> I'm talking about the one on the front page 2016-07-15 21:33:24 hm, no, you’re right 2016-07-15 21:33:47 for VMs, you just select virtio_net and disable all the other NIC drivers - easy way to gain space :P 2016-07-15 21:33:51 <^7heo> but again 2016-07-15 21:33:58 <^7heo> 138 sounds about 20 times too much imho 2016-07-15 21:34:20 anyway, why the hell linux-grsec depends on linux-firmware and what the hell is it? 2016-07-15 21:34:37 some drivers need firmware to load 2016-07-15 21:34:46 oh I’ve never needed that 2016-07-15 21:35:07 these are some proprietary BLOBs from nVidia etc? 2016-07-15 21:35:07 neither have I, but you pay attention to the hardware you buy and so do I 2016-07-15 21:35:29 yeah, and Nvidia is far from the worst here - for once 2016-07-15 21:35:42 I'm thinking wifi hardware 2016-07-15 21:35:44 <^7heo> ati is? 2016-07-15 21:35:46 then it should not be as a hard dependency 2016-07-15 21:35:47 <^7heo> ah 2016-07-15 21:35:50 <^7heo> atheros 2016-07-15 21:36:05 atheros is actually cool, they document their specs well 2016-07-15 21:36:16 <^7heo> broadcomm? 2016-07-15 21:36:19 and the open source ath drivers work well 2016-07-15 21:36:48 I don't know. I wouldn't be surprised if Broadcom chips needed firmware. And other brands. 2016-07-15 21:37:04 Tivo. ;) 2016-07-15 21:37:51 <^7heo> wtf is tivo? 2016-07-15 21:38:04 yeah, wtf is that? never heard about it 2016-07-15 21:38:09 >kernel size 2016-07-15 21:38:22 make localmodconfig is the most brilliant invention ever. 2016-07-15 21:38:58 cool! 2016-07-15 21:39:08 I didn’t know about this 2016-07-15 21:39:21 but its ideal for your own hardware only since it only enables the stuff that your kernel finds 2016-07-15 21:39:34 I think that’s the point 2016-07-15 21:39:38 https://en.wikipedia.org/wiki/Tivoization 2016-07-15 21:39:54 ah yes... tivoization 2016-07-15 21:40:27 provide some easy way how to build custom kernel or just remove unused modules, during instalation process 2016-07-15 21:40:55 ah yes... tivoization | where "what's the password" is considered by GNU as nonfree 2016-07-15 21:41:05 /s 2016-07-15 21:41:16 it’s utterly stupid to install thousands of modules that will never be used 2016-07-15 21:41:21 yeah 2016-07-15 21:41:38 tivoization: a story in which nobody, *nobody* does the right thing 2016-07-15 21:41:56 a symptom of the sad state of interactions between free software and industry. 2016-07-15 21:42:06 <^7heo> jirutka: until you plug that replacement wifi board in the middle of nowhere 2016-07-15 21:42:16 ^7heo: hm, right… 2016-07-15 21:42:29 <^7heo> to peer with your phone 2g 2016-07-15 21:42:47 <^7heo> I mean 2016-07-15 21:42:55 maybe it should be optional… if user wants to save disk space, she can try this way… if doesn’t care about it, just use bloated distro kernel 2016-07-15 21:43:02 <^7heo> 99% of the time it's useless 2016-07-15 21:43:14 <^7heo> 1% essential 2016-07-15 21:43:38 <^7heo> I would be happy to have a system compressing all the .ko not needed 2016-07-15 21:43:46 you know whats a good thing? my old i586 accepts more than what the specs limit in RAM 2016-07-15 21:43:53 .ko are already compressed, you wouldn't gain much 2016-07-15 21:43:59 yeah 2016-07-15 21:44:03 <^7heo> and stashing them somewhere where I can find them 2016-07-15 21:44:04 the specs technically say that 160M is the limit but I was able to insert a 256M stick 2016-07-15 21:44:06 there are just too many of them 2016-07-15 21:44:21 and the bios recognized it 2016-07-15 21:44:24 <^7heo> skarnet: I meant as in: not executable 2016-07-15 21:44:39 <^7heo> skarnet: in a tar or something 2016-07-15 21:46:36 ^7heo: since when is TAR a compressing format? ;) 2016-07-15 21:47:26 <^7heo> jirutka: skarnet said it's already compressed 2016-07-15 21:47:29 <^7heo> and 2016-07-15 21:47:45 <^7heo> are you seeimg the news 'bout turkey? 2016-07-15 21:47:52 <^7heo> seeing* 2016-07-15 21:48:04 <^7heo> WTF is wrong today? 2016-07-15 21:48:17 well, but I don’t see how it can help when you just TAR unused modules 2016-07-15 21:48:35 nothing, just the world burns… 2016-07-15 21:49:10 but remember, it has absolutely nothing to do with Islam or religion in general! 2016-07-15 21:50:41 <^7heo> SNAFU isn't that 2016-07-15 21:50:56 <^7heo> this is a new level of shit 2016-07-15 21:51:08 -> offtopic guys 2016-07-15 21:51:17 okay, back to the topic 2016-07-15 21:51:20 <^7heo> yeah 2016-07-15 21:51:47 SNAFU is probably on-topic and a very accurate acronym to describe anything computer-related 2016-07-15 21:51:48 <^7heo> skarnet: jirutka isn't in #alpine-offtopic 2016-07-15 21:51:49 we should discuss something that we actually can change instead 2016-07-16 01:43:51 "The world has so many countries OMG o_o" 2016-07-16 15:08:49 hey :) 2016-07-16 15:08:54 how is everybody? 2016-07-16 15:35:51 HELLO LEO 2016-07-16 16:27:40 vkris: I’ve added some plugins for uwsgi and most importantly, Python 3 … https://github.com/alpinelinux/aports/pull/164 2016-07-16 17:28:48 jirutka_: thanks 2016-07-16 18:55:39 I found abduco-0.5 in aports/testing. I can update it to 0.6 pretty easily, but how do I share my changes? 2016-07-16 19:14:14 lernisto: git 2016-07-16 19:15:11 https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package#Commit_your_work 2016-07-16 20:02:37 hi guys, I am currently not able to build an iso because xorrisofs is missing. 2016-07-16 20:03:03 are there any plans to provide the pkg or did I miss something ? 2016-07-16 20:05:30 xorriso is only in edge .. ok 2016-07-16 20:19:04 back to start: after installing the pkg from edge I ended up with : "Error relocating /usr/lib/libisoburn.so.1: iso_write_opts_set_part_like_isohybrid: symbol not found" 2016-07-18 08:09:04 i know that this is a topic we discussed several times..but since i need python3 packages to make GNS3 work, i come back: is it ok to have py and py3 compiled in the same APKBUILD? Do we have a working template for that? 2016-07-18 08:09:38 Yes, no 2016-07-18 08:09:53 i remember that i had...:) 2016-07-18 08:09:55 But the one you had before is good 2016-07-18 08:10:00 exactly 2016-07-18 08:10:18 barthalion, since you have a good memory 2016-07-18 08:10:36 I don't find it anymore 2016-07-18 08:10:42 do you have a copy? 2016-07-18 08:18:58 upgraded armhf builder to 3.4.1 kernels 2016-07-18 08:19:23 upgrading u-boot next 2016-07-18 08:19:43 hopefully got the udhcp issue fixed that caused it to lose IPs few times 2016-07-18 08:22:53 fcolista: I can try to find it 2016-07-18 08:24:40 fcolista: http://tpaste.us/3lXa 2016-07-18 08:24:58 barthalion, gr8! 2016-07-18 08:25:00 thanks! 2016-07-18 08:25:30 wrt build(), I think you should copy $builddir to ${builddir}-py2 first 2016-07-18 08:25:38 and run setup.py separately 2016-07-18 08:25:56 although it might not affect anything, not sure atm 2016-07-18 09:03:00 barthalion, i'm wondering if we should put a provide= 2016-07-18 09:03:08 since now py-psutil is empty 2016-07-18 09:03:24 libs are provided by py2-psutil actually 2016-07-18 09:04:15 I want to get rid of py- in the long term 2016-07-18 09:04:25 not sure how it should be solved 2016-07-18 09:04:28 ncopa: ^ 2016-07-18 09:04:36 I guess py- should pull py2- 2016-07-18 09:04:45 i think so 2016-07-18 09:05:02 morning 2016-07-18 09:05:05 whats up? 2016-07-18 09:05:10 otherwise, we should change all the packages depending from py-psutils to py2-psutils 2016-07-18 09:05:26 well, yes, we should do it anyway 2016-07-18 09:05:35 I'm concerned about user-installed packages 2016-07-18 09:05:43 ncopa: http://sprunge.us/EGNd 2016-07-18 09:05:52 py-psutils now is empty 2016-07-18 09:06:06 the actual libs are provided by py2-psutils 2016-07-18 09:06:50 or we consider py-psutils as a meta-package which install both py2,3 2016-07-18 09:07:08 or we should get rid of py-psutils 2016-07-18 09:07:12 and left py2 and py3 2016-07-18 09:07:25 i dont think we can get rid of py-* yet 2016-07-18 09:07:40 +1...in the meanwhile, indeed, we should pull py2 2016-07-18 09:07:43 hi. usually you'd go with one transitional release that would make all py- be replaced with py2- and then remove it in next release. the problem is nicely handling /etc/apk/world, not sure if sed 's/^py-/py2-/' is good enough. 2016-07-18 09:08:12 fcolista: either that or we add install_if="pythonX ..." 2016-07-18 09:08:14 przemoc, you're going to break a lot of things 2016-07-18 09:08:58 i think we need to rename python to python2 2016-07-18 09:09:03 and add provides=python 2016-07-18 09:09:18 ncopa: 2016-07-18 09:09:19 install_if="$pkgname=$pkgver-r$pkgrel $python" 2016-07-18 09:09:25 that's already do that 2016-07-18 09:09:40 ok 2016-07-18 09:09:47 ncopa: that, or rewrite apk to properly manage several different versions of the same package. :P 2016-07-18 09:09:56 fcolista: i think thats enough 2016-07-18 09:10:07 so, for instance, if we install certbot 2016-07-18 09:10:14 that in "depends" has py-psutils 2016-07-18 09:10:17 skarnet: like gentoo's "slots" 2016-07-18 09:10:21 py2-psutils is pulled 2016-07-18 09:10:28 right? 2016-07-18 09:10:53 ncopa: not sure what slots are, I'll read up on them 2016-07-18 09:11:09 skarnet: we did talk about it when we created apk 2016-07-18 09:11:10 but 2016-07-18 09:11:28 skarnet: basically this, plus you can choose which version /usr/bin/python (etc) provides 2016-07-18 09:11:37 the same functionality could be achieved by addedin another package, eg "python" vs "python2" 2016-07-18 09:12:05 barthalion: ok, then that's the correct way of managing packages 2016-07-18 09:12:57 fcolista: depends if certutil also puls in "python2" 2016-07-18 09:13:38 fcolista: if certutil has a depends="python2" then will py-psutils pull in py2-psutils 2016-07-18 09:13:52 well, it has not specifically this 2016-07-18 09:14:04 it has a lot pf py pacakges as depends 2016-07-18 09:14:09 python2 package needs to be installed 2016-07-18 09:14:11 which install python2 2016-07-18 09:14:34 but python is not specifically in depends 2016-07-18 09:14:44 if python2 is installed, then will py-psutils pull in py2-psutils 2016-07-18 09:14:49 since is a dependency of others py 2016-07-18 09:14:50 ok 2016-07-18 09:14:59 so this is how will go. 2016-07-18 09:15:02 do we have a package named "python2"? 2016-07-18 09:15:08 nope afaik 2016-07-18 09:15:19 that needs to be fixed first then 2016-07-18 09:15:22 not yet 2016-07-18 09:15:29 well, then we will have different issue 2016-07-18 09:15:37 what to do with 'python' pkg… 2016-07-18 09:15:44 we should fix all deps? 2016-07-18 09:15:53 i think we can do: 2016-07-18 09:15:53 or should be provided by python2? 2016-07-18 09:16:02 1) rename python -> python2 2016-07-18 09:16:14 2) let python2 have a provides="python" 2016-07-18 09:16:41 okay 2016-07-18 09:16:44 3) gradually change the depends to those who explicitly needs python2 2016-07-18 09:16:48 fcolista: that's on me then 2016-07-18 09:16:56 +1 2016-07-18 09:17:18 packages that specifically works only with py3 should be renamed in py3 then 2016-07-18 09:17:24 s/then/also 2016-07-18 09:17:27 we need pay attention to what we do with the python-dev package 2016-07-18 09:17:28 yes 2016-07-18 09:19:27 python-dev – I guess it should be provided by python2-dev 2016-07-18 09:21:06 i think thats the easiest path yes 2016-07-18 09:22:09 i think we cannot let it be provided by python3-dev 2016-07-18 09:22:14 it would break too much 2016-07-18 09:23:28 yeah 2016-07-18 09:24:05 maybe apk could be enhanced with renaming coming from .apk pkg, so there could be new python2-dev pkg created and last python-dev relbump with renaming metadata only, so apk would be fixing /etc/apk/world itself 2016-07-18 09:26:14 providing old pkgs indefinitely is PITA and such renaming problems will arise in future, so it's good to think about it at infrastructural level 2016-07-18 09:26:31 s/pkgs/pkg names/ 2016-07-18 09:26:47 hello 2016-07-18 09:27:04 so something like http://tpaste.us/AQQb will make apk happy? 2016-07-18 09:27:25 hrw: morning 2016-07-18 09:27:39 przemoc: suggestion: hackfix it right now for python to put out the fire, and parallel to it, start thinking about an apk redesign? 2016-07-18 09:28:41 przemoc: my guess is that indefinitely isn't the best word; as fcolista said, we will just drop compatibility providers in next release 2016-07-18 09:29:19 anyway, going back to work 2016-07-18 09:30:02 I'll be at customer site next week so I'll most likely review py-* packages in main and testing during evenings 2016-07-18 09:30:34 skarnet: hackfixes have tendency to remain for (much) longer than originally planned, that's why I'm always reluctant to choose such "easy/quick" path 2016-07-18 09:31:10 barthalion: /etc/apk/world will still remain to be fixed 2016-07-18 09:33:23 przemoc: oh, yeah, you're definitely preaching to the choir here. But it sounds like the Python issue is relatively urgent, whereas the classic package manager technical debt is something that takes a lot of time to pay. 2016-07-18 09:34:50 very relatively 2016-07-18 09:34:57 python3 is already semi-supported 2016-07-18 09:35:03 just our packages don't 2016-07-18 09:35:38 so it's already kind of tech debt, unfortunately 2016-07-18 09:36:35 barthalion: that looks ok 2016-07-18 09:43:11 interesing: i don't have anymore libintl 2016-07-18 09:45:11 interesting: there's no more libintl on main 2016-07-18 09:45:15 http://git.alpinelinux.org/cgit/aports/tree/main 2016-07-18 09:45:18 ?!?!?!!?! 2016-07-18 09:45:52 ah 2016-07-18 09:45:53 si gettext 2016-07-18 09:45:56 *is 2016-07-18 09:59:13 anyone is experiencing issue with : 2016-07-18 09:59:13 ERROR: unsatisfiable constraints: 2016-07-18 09:59:13 so:libintl.so.8 (missing): 2016-07-18 09:59:16 ? 2016-07-18 10:00:28 This happened after having installed gettext-0.19.8 2016-07-18 10:00:30 fcolista, generally means some package needs rebuild 2016-07-18 10:00:36 yes 2016-07-18 10:00:49 but the gettext upgrade does not break abi compat 2016-07-18 10:01:23 commit 6f19294175a24db11575eb89d2daa36f8ecac78f 2016-07-18 10:01:24 Author: Christian Kampka 2016-07-18 10:01:24 Date: Sat Jul 16 19:35:58 2016 +0200 2016-07-18 10:01:24 main/gettext: new upstream version 0.19.8 2016-07-18 10:20:41 ncopa, if py-$package provide some libs, then it happens that the same libs are provided by py2-$package, when a package depending from that py lib is upgrading, this creates a conflict 2016-07-18 10:20:58 or ugprade, or an install. 2016-07-18 10:21:21 i had to del the py-$package first 2016-07-18 10:51:12 ncopa: barthalion: could you please merge https://github.com/alpinelinux/aports/pulls?q=is%3Aopen+is%3Apr+label%3Aready ? 2016-07-18 10:51:35 fcolista: we need replaces= too 2016-07-18 11:08:11 barthalion, aah 2016-07-18 11:08:15 right 2016-07-18 11:08:25 that's what i need to add 2016-07-18 11:08:26 thx 2016-07-18 11:09:50 barthalion, i'm going to add replaces="$pkgname" in _py() function 2016-07-18 11:10:41 in py2 2016-07-18 11:10:47 both provides and replaces imho 2016-07-18 11:11:04 fcolista: ^ 2016-07-18 11:11:12 provides ? 2016-07-18 11:11:32 yes, because py2- provides the previous content of py- pkg 2016-07-18 11:11:49 umh... 2016-07-18 11:11:50 ok 2016-07-18 11:12:00 i thought replaces=$pkgname would be enough 2016-07-18 11:15:55 barthalion, can you please explain me why replaces is not enough? 2016-07-18 11:16:14 having provides and replaces, does not introduce a loop? 2016-07-18 11:16:49 you might be right 2016-07-18 11:16:55 my point is, do it in py2() 2016-07-18 11:16:58 not in _py 2016-07-18 11:17:07 yes 2016-07-18 11:17:09 that's correct 2016-07-18 11:17:21 it should go to _py2 2016-07-18 11:17:23 agree 2016-07-18 14:29:18 barthalion, depends should contains both python and python3, right? 2016-07-18 14:52:29 ncopa, do you agree with that? http://sprunge.us/BVdZ 2016-07-18 14:52:33 it builds fine. 2016-07-18 14:52:46 hey there :) 2016-07-18 14:58:52 hi leo-unglaub 2016-07-18 15:25:58 fcolista: where? 2016-07-18 15:26:09 fcolista: py2 should depend on python for now, py3 on python3 2016-07-18 15:26:22 fcolista: I'll rename python to python2 tomorrow and fix the deps across aports 2016-07-18 15:26:36 fcolista: makedeps should pull both 2016-07-18 15:26:41 yes 2016-07-18 15:26:46 i mean depends= 2016-07-18 15:26:57 not in the py() function 2016-07-18 15:27:04 but in main APKBUILD 2016-07-18 15:27:15 should i put both python and python3 ? 2016-07-18 15:27:16 Or 2016-07-18 15:27:21 nothing I guess? 2016-07-18 15:27:27 depends=python in py2() 2016-07-18 15:27:34 and depends=python3 in py3() ? 2016-07-18 15:27:38 yeah 2016-07-18 15:27:51 k 2016-07-18 15:28:00 thx for confirm 2016-07-18 15:28:06 i need to adjust some packages then 2016-07-18 15:31:55 :q 2016-07-18 15:32:01 sry, wrong window 2016-07-18 15:56:33 fcolista: looks good to me 2016-07-18 15:57:41 k thx 2016-07-18 16:03:15 i'm pretty sure that libintl is broken 2016-07-18 16:03:27 and, in turn, all the dependencies 2016-07-18 16:03:38 it is, by design! 2016-07-18 16:03:47 ACTION sees himself out. 2016-07-18 16:03:54 look: 2016-07-18 16:03:55 so:libintl.so.8 (missing): 2016-07-18 16:03:55 required by: pango-1.40.1-r0[so:libintl.so.8] gtk+2.0-2.24.28-r1[so:libintl.so.8] pango-1.40.1-r0[so:libintl.so.8] 2016-07-18 16:03:55 gdk-pixbuf-2.34.0-r0[so:libintl.so.8] glib-2.48.1-r1[so:libintl.so.8] avahi-libs-0.6.32-r0[so:libintl.so.8] 2016-07-18 16:03:55 gtk+2.0-2.24.28-r1[so:libintl.so.8] avahi-libs-0.6.32-r0[so:libintl.so.8] harfbuzz-1.2.7-r0[so:libintl.so.8] 2016-07-18 16:03:58 glib-2.48.1-r1[so:libintl.so.8] glib-2.48.1-r1[so:libintl.so.8] harfbuzz-1.2.7-r0[so:libintl.so.8] 2016-07-18 16:04:01 atk-2.20.0-r0[so:libintl.so.8] atk-2.20.0-r0[so:libintl.so.8] pango-1.40.1-r0[so:libintl.so.8] 2016-07-18 16:04:04 gtk+2.0-2.24.28-r1[so:libintl.so.8] pango-1.40.1-r0[so:libintl.so.8] 2016-07-18 16:04:06 gtk-update-icon-cache-2.24.28-r1[so:libintl.so.8] glib-2.48.1-r1[so:libintl.so.8] 2016-07-18 16:04:10 gdk-pixbuf-2.34.0-r0[so:libintl.so.8] gtk+2.0-2.24.28-r1[so:libintl.so.8] 2016-07-18 16:04:12 gdk-pixbuf-2.34.0-r0[so:libintl.so.8] pango-1.40.1-r0[so:libintl.so.8] glib-2.48.1-r1[so:libintl.so.8] 2016-07-18 16:04:15 avahi-libs-0.6.32-r0[so:libintl.so.8] glib-2.48.1-r1[so:libintl.so.8] 2016-07-18 16:04:17 bah 2016-07-18 16:04:19 sorry 2016-07-18 16:04:21 it should be sprunge...anyway 2016-07-18 16:04:28 libintl.so.8 is no longer existing after gettext upgrade 2016-07-18 16:04:36 to 0.19.8 version 2016-07-18 16:05:08 those libs are dependend from that .so.8, rather than .so (and having a symlink) 2016-07-18 16:05:30 0.19.8 has libintl.so.9 2016-07-18 16:05:51 i can "workaroun" by making a symlink from libintl.so.9 to .8 2016-07-18 16:06:01 checkapk reports no abi changes. 2016-07-18 16:06:07 no. if abi changed we need to rebuild 2016-07-18 16:06:17 it reports no abi changes. 2016-07-18 16:26:43 fcolista: revert the gettext commit for now 2016-07-18 16:26:52 barthalion, no 2016-07-18 16:27:04 i'm doing bump pkgrel 2016-07-18 16:27:08 im on it 2016-07-18 16:27:13 okay 2016-07-18 16:27:16 or you have other options? 2016-07-18 16:27:24 put info about why you do the bump in the future 2016-07-18 16:27:34 yes, good point 2016-07-18 16:27:57 chris|: you should usually run checkapk after the build; also minor nitpick, we usually stick to 'repo/pkgname: upgrade to pkgver' commit scheme 2016-07-18 16:28:18 (never realized how close commit is to vommit on qwerty… but nvm, catched the typo before hitting enter) 2016-07-18 16:31:26 never try to merge vommits 2016-07-18 16:31:40 XD 2016-07-18 16:34:22 hello, has anyone tried running alpine-xen-3.4.1-x86_64 on AWS? 2016-07-18 17:17:10 fcolista: we don’t have package named python2, just python and python3, so this https://github.com/alpinelinux/aports/compare/2ca6099b98...da604b65d0#diff-3cd40c671d9b297454d7443f8b3ff023R36 is wrong 2016-07-18 17:31:36 fcolista: this all is wrong; for example py-raven, it installs /usr/bin/raven, but this script is inside py-raven package, not py[23]-raven, so there’s just one copy of it… and it contains shebang for python3… 2016-07-18 17:32:12 also when you install directly py[23]-raven (not py-raven), then it does not install py-raven, so you don’t get this script at all 2016-07-18 17:33:30 jirutka, 2016-07-18 17:33:33 yes. You're right 2016-07-18 17:33:37 let me fix 2016-07-18 17:33:49 re: python and python2 2016-07-18 17:33:55 pushing the rename now… 2016-07-18 17:34:03 it would be less broken and also much simpler to just run `python setup.py install` in side a split function, then you don’t need so much boilerplate 2016-07-18 17:34:13 that's true. The strategy was renaming python to python2 2016-07-18 17:34:19 ok...thx barthalion 2016-07-18 17:34:31 yeah, setup.py should be run in split functions 2016-07-18 17:34:39 however, then we will have a problem when someone install both py2 and py3 variant of the same package 2016-07-18 17:35:02 /usr/bin should be imho shipped only with py3 version 2016-07-18 17:35:03 that's true when py contains binary 2016-07-18 17:35:11 +1 2016-07-18 17:35:19 correction: we may, if the package installs something outside of stdlib path, like script into /usr/bin 2016-07-18 17:40:01 barthalion: have you sent https://github.com/alpinelinux/aports/commit/99dd043cd563c7919bb11bd2478a9e0f9a3dd1c0 to the mailing list before pushing to the repo? 2016-07-18 17:40:21 no, and I'm not going to 2016-07-18 17:40:34 I, ncopa and fcolista discussed it here in the morning 2016-07-18 17:40:43 and yet your patch is broken 2016-07-18 17:40:50 broken very much 2016-07-18 17:40:58 see my comments on GH 2016-07-18 17:41:03 really, I will ask you for review if I need one 2016-07-18 17:41:16 so you know that it’s broken? 2016-07-18 17:41:18 or what? 2016-07-18 17:41:24 and I know that it's fixed 2016-07-18 17:41:34 don't assume people don't know what they're doing 2016-07-18 17:41:49 are you kidding me?! 2016-07-18 17:41:59 have you read comments? https://github.com/alpinelinux/aports/commit/99dd043cd563c7919bb11bd2478a9e0f9a3dd1c0 2016-07-18 17:42:05 again, I don't care 2016-07-18 17:42:24 so you don’t care pushing broken stuff to the repo?! 2016-07-18 17:42:45 no, I don't care about your whining, it's been fixed in less than a minute since it failed on build infra 2016-07-18 17:43:24 is it so hard to test it locally before pushing to the repo? 2016-07-18 17:43:32 it’s in the main branch 2016-07-18 17:43:34 you are going to lecture me again? 2016-07-18 17:44:13 if I need to… 2016-07-18 17:44:17 (y) 2016-07-18 17:44:23 fcolista: py-paramiko pulls python3, is this on purpose? 2016-07-18 17:45:13 barthalion, umh. I think that this is due to depends= i was talking beofre 2016-07-18 17:45:26 depends= shoudl go in the py() functions 2016-07-18 17:45:30 hm, ok 2016-07-18 17:45:32 rather than in main APKBUILD 2016-07-18 17:46:16 what else is broken? I can't really dedicate this more than 20 minutes today and another 20 tomorrow 2016-07-18 17:46:32 uh, and that broken gettext 2016-07-18 17:46:53 yes. gettext brokes several stuff 2016-07-18 17:47:01 gettext changed so-version right? 2016-07-18 17:47:02 ok, py-ipaddr pulls python2 2016-07-18 17:47:16 yes 2016-07-18 17:47:24 I'll fix it 2016-07-18 17:47:25 libintl.so.8 to libintl.so.9 ncopa 2016-07-18 17:48:06 do we bother revert it meanwhile? 2016-07-18 17:48:13 fcolista started fixing it 2016-07-18 17:48:17 ok 2016-07-18 17:48:27 i bumped several pkgrel 2016-07-18 17:48:36 do you have a complete list? 2016-07-18 17:48:41 I'm making one 2016-07-18 17:48:46 ok 2016-07-18 17:48:58 good. you have it under control then :) 2016-07-18 17:49:22 barthalion: do you know that if default_prepare fails, it does not fail the build, because you’ve missed `|| return 1`? 2016-07-18 17:49:53 jirutka: awesome news, will fix it after gettext 2016-07-18 17:50:11 ncopa, barthalion : http://sprunge.us/iKeP 2016-07-18 17:50:12 i wonder why gettext didntn upgrade to 0.20 2016-07-18 17:50:12 it’d be better to fix it before pushing into repository… 2016-07-18 17:50:40 what is missing is weechat and gtk-update-icon-cache 2016-07-18 17:50:57 the other was already bumped 2016-07-18 17:51:02 *others 2016-07-18 17:51:27 fcolista: did you fix community as well? 2016-07-18 17:51:32 and testing? 2016-07-18 17:51:43 what you mean? 2016-07-18 17:51:48 there are packages that pull gettext-dev 2016-07-18 17:52:08 barthalion, not yet 2016-07-18 17:52:26 i've fixed "apk search -r libintl.so " so far 2016-07-18 17:52:27 barthalion: i'll do the pyhon2's || return 1 2016-07-18 17:52:46 fcolista: yeah, I wish apk search could return global result 2016-07-18 17:52:53 ncopa: thx 2016-07-18 17:52:59 does it not? 2016-07-18 17:53:06 it gives me empty output here 2016-07-18 17:53:14 apk search -r --exact so:libintl.so.8 2016-07-18 17:53:25 you need to have the repos in your /etc/apk/repositories 2016-07-18 17:53:34 i've all 2016-07-18 17:53:39 that's why is working here then 2016-07-18 17:53:43 ah, I missed testing 2016-07-18 17:53:52 so no fixes in community then? 2016-07-18 17:54:03 seems there's no need 2016-07-18 17:54:14 and none in testing 2016-07-18 17:54:25 which is a lie 2016-07-18 17:54:45 neither rpm or spacefm can be installed 2016-07-18 17:54:56 ditto with gtk-vnc 2016-07-18 17:55:24 apk search -q --origin -r --exact so:libintl.so.8 2016-07-18 17:55:41 it returns nothing 2016-07-18 17:55:42 here 2016-07-18 17:55:56 yes, same here 2016-07-18 17:56:58 I'll start with community 2016-07-18 17:57:04 http://tpaste.us/2KNq 2016-07-18 17:57:13 thats community 2016-07-18 17:57:28 ncopa: thing is, how did you get that list? 2016-07-18 17:57:37 testing: http://tpaste.us/Ao1R 2016-07-18 17:57:48 cd ~/aports/community 2016-07-18 17:57:55 and grep 2016-07-18 17:58:06 ncdev-edge-x86_64:~/aports/community$ apk search -q --origin -r --exact so:libintl.so.8 | xargs ap builddirs | cut -d/ -f5,6 | tpaste 2016-07-18 17:58:47 apk search output is still empty for me :( 2016-07-18 17:58:48 i think its weird that your apk search --exact so:libintl.so.8 don't work 2016-07-18 17:59:32 it works for so.9 2016-07-18 18:01:14 hum 2016-07-18 18:01:53 omg 2016-07-18 18:01:59 I can reproduce. sudo apk search -U --repositories-file /dev/null -X http://fr.alpinelinux.org/alpine/edge/community --exact so:libintl.so.8 2016-07-18 18:02:05 fcolista: dealing with main first 2016-07-18 18:02:12 at-spi-now, then gtk3 2016-07-18 18:02:13 ok. barthalion, are you working on main? 2016-07-18 18:02:21 yes 2016-07-18 18:02:22 How do we want to divide the task? 2016-07-18 18:02:35 i need to wait for you first 2016-07-18 18:02:44 'cause community has deps in main 2016-07-18 18:02:44 I don't have the list for main 2016-07-18 18:03:45 http://sprunge.us/ASPB 2016-07-18 18:03:49 that's too rude ^ ? 2016-07-18 18:03:58 grep -r gettext-dev */APKBUILD on main 2016-07-18 18:04:04 rude? no 2016-07-18 18:04:07 incomplete for sure 2016-07-18 18:04:28 i need to attend work mtg now :-/ 2016-07-18 18:04:37 ncopa: we can handle this 2016-07-18 18:04:39 ncopa, how can we get the main list ? 2016-07-18 18:04:41 ncopa: no worries 2016-07-18 18:04:47 list for main i mean 2016-07-18 18:04:57 since apk search does not work here 2016-07-18 18:05:24 this is a start: http://tpaste.us/Ajjq 2016-07-18 18:05:39 ok cool 2016-07-18 18:05:39 thx 2016-07-18 18:06:02 so at-spi-* should be done 2016-07-18 18:07:25 and now we have gtk3 2016-07-18 18:07:29 that should help 2016-07-18 18:07:41 fcolista: so I'll go from the bottom of the main list 2016-07-18 18:07:51 ok, i'll to from first 2016-07-18 18:07:58 main/glib 2016-07-18 18:07:58 main/cairo 2016-07-18 18:07:58 main/gobject-introspection 2016-07-18 18:08:06 main/atk 2016-07-18 18:08:06 main/harfbuzz 2016-07-18 18:08:06 main/pango 2016-07-18 18:08:13 main/dbus-glib 2016-07-18 18:08:13 main/py-dbus 2016-07-18 18:08:19 main/avahi 2016-07-18 18:08:20 main/gdk-pixbuf 2016-07-18 18:08:20 main/gtk+2.0 2016-07-18 18:08:22 those are done 2016-07-18 18:09:13 gtk3 is still building on builders 2016-07-18 18:09:47 heh 2016-07-18 18:10:06 off we go 2016-07-18 18:42:54 ncopa: docker run -it --rm alpine:edge apk search -U --origin -r --exact so:libintl.so.8 2016-07-18 18:43:02 ncopa: does this return anything for you? 2016-07-18 18:49:34 barthalion: no 2016-07-18 18:49:49 i suspect there is a dep issue 2016-07-18 18:50:37 dep issue? 2016-07-18 18:50:52 I don't think I see why 2016-07-18 18:51:15 i suspect the gettext deps were not built in order 2016-07-18 18:51:20 so apk cannot resolve things 2016-07-18 18:51:24 but i dont know 2016-07-18 18:51:46 barthalion: try this: docker run -it --rm alpine:edge apk -U dot --errors 2016-07-18 18:52:32 okay, it returns a lot 2016-07-18 18:52:44 it also returns circular deps 2016-07-18 18:53:25 indeed 2016-07-18 18:53:48 http://i3.kym-cdn.com/photos/images/facebook/000/117/814/are-you-wizard.jpg 2016-07-18 18:54:06 :D 2016-07-18 18:55:08 but they need to be fixed in dep order 2016-07-18 18:55:29 I guess circular dep should be fixed either 2016-07-18 18:55:43 not exactly how yet 2016-07-18 18:56:10 not exactly sure 2016-07-18 19:00:12 lets deal with those later 2016-07-18 19:00:29 docker run -it --rm alpine:edge apk -U dot --errors | sed -E -n '/so:libintl.so.8/s/.*"([^ ]+)" ->.*\;/\1/p' | sort -u 2016-07-18 19:00:36 nice tip to run docker btw :) 2016-07-18 19:01:25 well, all tips to you, isn't it? :P 2016-07-18 19:02:06 I'll not cut in into fcolista work for a while 2016-07-18 19:02:13 https://paste.xinu.at/RKHJt/ but this is so fancy 2016-07-18 19:02:35 cool 2016-07-18 19:02:57 how did you do that? 2016-07-18 19:03:05 graphviz 2016-07-18 19:03:23 how's generated? 2016-07-18 19:04:17 apk -U dot --errors 2016-07-18 19:04:25 dot -Tsvg file.dot > file.svg 2016-07-18 19:06:34 fcolista: I'm off til tomorrow, I'll continue tomorrow morning if you leave something for me 2016-07-18 19:06:53 if not, I'll try to fix this: https://paste.xinu.at/RKHJt/ 2016-07-18 19:07:33 fcolista: i think i can fix the rest of main 2016-07-18 19:08:08 ncopa, thx. 2016-07-18 19:08:13 i'm still on it though 2016-07-18 19:08:20 still have some time to spent on it 2016-07-18 19:08:22 i can script it 2016-07-18 19:09:09 how can you set the right sequence of the packages? 2016-07-18 19:09:14 I was thinkingto do the same 2016-07-18 19:09:16 ap builddirs ... 2016-07-18 19:09:21 with apkgrel 2016-07-18 19:09:22 what is ap? 2016-07-18 19:09:26 ap ? 2016-07-18 19:09:30 lua-aports 2016-07-18 19:09:33 oh 2016-07-18 19:10:05 hum 2016-07-18 19:10:08 i think we have problem 2016-07-18 19:10:42 https://dpaste.de/fBNm 2016-07-18 19:11:04 "Secure Connection Failed" here 2016-07-18 19:11:34 uh-oh 2016-07-18 19:11:35 ok 2016-07-18 19:11:41 ERROR: unsatisfiable constraints: 2016-07-18 19:11:41 libintl-0.19.8-r0: 2016-07-18 19:11:41 conflicts: libintl-0.19.7-r1 2016-07-18 19:11:58 i think it fails resolve order 2016-07-18 19:13:42 ERROR: python2-2.7.12-r0: trying to overwrite usr/lib/python2.7/audiodev.py owned by python-2.7.12-r0. 2016-07-18 19:13:45 we need replaces 2016-07-18 19:15:02 oops 2016-07-18 19:15:08 on it 2016-07-18 19:15:52 ncopa: provides&replaces? 2016-07-18 19:16:00 yes 2016-07-18 19:16:11 or all subpkgs? 2016-07-18 19:16:17 s/or/for/ 2016-07-18 19:16:25 good question 2016-07-18 19:16:32 yes 2016-07-18 19:16:38 for all subpkgs 2016-07-18 19:16:45 i think it will automatically do that though 2016-07-18 19:16:58 but might be good to be explicit in case that changes in abuild 2016-07-18 19:17:12 fcolista, i am running rebuild script now 2016-07-18 19:17:27 it will rebuild a whole lot of packages 2016-07-18 19:17:29 aw 2016-07-18 19:17:37 i'll stop then 2016-07-18 19:17:42 just pushed xfce4... 2016-07-18 19:17:45 gcc6 failures 2016-07-18 19:18:03 we should have revert it 2016-07-18 19:18:22 it's not like the first time we sit in the evening and fix everything 2016-07-18 19:18:35 reverting woudl been better 2016-07-18 19:20:53 we're still on time to do that 2016-07-18 19:21:02 since we also need to fix community and testing.. 2016-07-18 19:21:31 i am annoyed on gettext 2016-07-18 19:21:39 why do they change ABI in a minor release 2016-07-18 19:21:43 yeah 2016-07-18 19:21:45 that's crazy 2016-07-18 19:22:44 ARGH 2016-07-18 19:22:46 revert! 2016-07-18 19:22:48 revert! 2016-07-18 19:22:59 we need revert it all 2016-07-18 19:23:03 https://lists.gnu.org/archive/html/info-gnu/2016-06/msg00006.html 2016-07-18 19:23:35 no wai 2016-07-18 19:23:45 :| 2016-07-18 19:23:52 why don't drop gettext completely 2016-07-18 19:24:02 i woudl if i could 2016-07-18 19:24:05 aaaarrrgggghhhhh 2016-07-18 19:24:21 there are still files like "v3_0.tar.gz" http://distfiles.alpinelinux.org/distfiles/v3.4/ 2016-07-18 19:24:56 bah 2016-07-18 19:25:00 date: Sat, 11 Jun 2016 22:55:11 +0900 2016-07-18 19:25:01 main/lua-soap 2016-07-18 19:25:11 it's more than one month ago 2016-07-18 19:25:23 why was shipped the 0.19.8 and not 0.19.8.1 then? 2016-07-18 19:25:29 vkris: my uwsgi patch is merged, so now you can install uwsgi-http :) https://pkgs.alpinelinux.org/package/edge/main/x86_64/uwsgi-http 2016-07-18 19:25:33 since it was pushed 2 days ago?!?! 2016-07-18 19:25:42 jirutka: thanks 2016-07-18 19:25:45 vkris: all any others from… uh… 73 modules 2016-07-18 19:25:48 jirutka, re: python-raven 2016-07-18 19:25:50 plugins 2016-07-18 19:26:11 what do you suggest? Just move the bin in py3 function? 2016-07-18 19:26:24 since actually raven script is only for py3 2016-07-18 19:26:30 i'm upgrading gettext to 0.19.8.1 2016-07-18 19:26:35 fcolista: then it’s simple, move it to py3 2016-07-18 19:26:37 then we take it from there 2016-07-18 19:26:48 ncopa: good sides: we know about apk-dot and lua-aports now 2016-07-18 19:26:53 fcolista: it will be more problematic for packages that provides bin scripts for both python versions… 2016-07-18 19:27:01 right 2016-07-18 19:27:16 is something to think about in advance, i agree. 2016-07-18 19:27:17 I checked and any plugins that are experimental/deprecated or depends othere than main/ canbe avoided 2016-07-18 19:27:37 manual deprecates few of them 2016-07-18 19:27:39 fcolista: and you can just run setup.py install in split function, like this https://github.com/alpinelinux/aports/blob/0cb416a6176d97b8817fe2c8ae069f01d62dda96/testing/py-pyldap/APKBUILD 2016-07-18 19:28:35 barthalion: you didn’t know about ap before? that’s what I’ve used to sort packages in https://github.com/alpinelinux/aports/blob/master/.travis/build-pkgs#L30-L31 2016-07-18 19:28:56 vkris: what plugins? uwsgi? 2016-07-18 19:29:03 jirutka: 2016-07-18 19:29:04 $python setup.py install --prefix=/usr --root="$subpkgdir" 2016-07-18 19:29:20 how this would solve the usr/bin issue? 2016-07-18 19:29:32 vkris: I’ve ommited experimental plugins, but uwsgi plugins has very bad documentation, so there’s a chance that I’ve missed something 2016-07-18 19:29:34 it won't, you need to do it manually 2016-07-18 19:29:41 ah. 2016-07-18 19:29:42 ok. 2016-07-18 19:30:32 fcolista: the only problem is that you may end up with two scripts with the same path in two subpackages, so then when you install both py2 and py3, you’ll have a problem… 2016-07-18 19:30:53 right. 2016-07-18 19:31:06 you have a conflice. 2016-07-18 19:31:08 *conflict. 2016-07-18 19:31:15 fcolista: we have few options 2016-07-18 19:31:25 i think in such case we can manage with symlink 2016-07-18 19:31:37 with symlink? no, removal or rename 2016-07-18 19:31:42 raven to raven2 2016-07-18 19:31:58 then py3 version stays with original name 2016-07-18 19:31:59 umh 2016-07-18 19:32:11 fcolista: probably the most simply is to add version suffix to bins, e.g. raven2 and raven3… and install a symlink to one of these… 2016-07-18 19:32:13 raven2 and raven3 2016-07-18 19:32:16 with raven as symlink 2016-07-18 19:32:20 ? 2016-07-18 19:32:33 yes...that's what i was wondering too 2016-07-18 19:32:42 I think we should encourage users to use py3 2016-07-18 19:32:45 thus no rename for it 2016-07-18 19:33:00 another option is Gentoo approach… use a wrapper script 2016-07-18 19:33:15 agree, py3 should be default 2016-07-18 19:33:46 of course 2016-07-18 19:34:49 jirutka: pam ? 2016-07-18 19:35:01 vkris: what about it? 2016-07-18 19:35:05 we have pam ? 2016-07-18 19:35:19 vkris: yes, there’s a pam package, but not installed by default 2016-07-18 19:35:29 ok 2016-07-18 19:36:24 vkris: so it may be useful for someone… but to be honest, I was in doubts if I should include it or no… 2016-07-18 19:37:43 vkris: do you know about some list of uwsgi plugins with brief description and state (stable / experimental)? I found mentions about experimental state only in some sources 2016-07-18 19:38:19 some are mentioned in sources and some in docs 2016-07-18 19:39:32 vkris: did you find some experimental or deprecated plugins between subpackages? 2016-07-18 19:39:44 like http://uwsgi-docs.readthedocs.io/en/latest/WebServers.html 2016-07-18 19:40:07 not checked but will do 2016-07-18 19:40:09 vkris: I know about these 2016-07-18 19:40:21 vkris: okay, if you find something, please let me know 2016-07-18 19:43:15 fcolista: please don’t mix tabs and spaces 2016-07-18 19:43:26 ? 2016-07-18 19:43:33 where have you seen that? 2016-07-18 19:43:57 fcolista: https://github.com/alpinelinux/aports/blob/19da09f03af5bcb48888e4747bfe507957b1d487/testing/py-raven/APKBUILD#L47-L50 2016-07-18 19:44:19 fcolista: also tabs should be used in apkbuilds 2016-07-18 19:44:26 jirutka, i know 2016-07-18 19:44:38 it was a copy/paste by mistake probalby 2016-07-18 19:45:43 fcolista: there’s another case https://github.com/alpinelinux/aports/compare/9eb1fe9fbb...2c8afec95a#diff-d1dd3a861f6829f906f2866b8a21451aR35 2016-07-18 19:48:07 something weird between mate terminal and terminator 2016-07-18 19:48:19 i've default tabstop configured in vim with 4 spaces. 2016-07-18 19:48:36 bah 2016-07-18 19:48:46 tomorrow i'll check 2016-07-18 19:56:40 ncopa, what's the way to disable a build? Just set arch="" ? 2016-07-18 19:56:48 anyone revisited imagemagick 7.x issues 2016-07-18 19:56:56 fcolista: yes 2016-07-18 19:57:20 vkris: we're fighting gettext atm 2016-07-18 19:57:33 ok 2016-07-18 19:57:46 barthalion, ncopa, what's the next step? 2016-07-18 19:58:11 I go to bed, to be honest 2016-07-18 19:58:32 we need to rebump again pkg? 2016-07-18 19:58:38 Or rollback the changes we've done? 2016-07-18 19:58:55 what's the time there, barthalion ? 2016-07-18 19:59:19 Oh, it's early, we both live in CET IIRC 2016-07-18 19:59:25 I'm just tired 2016-07-18 19:59:56 Not sure which ncopa prefers 2016-07-18 20:01:49 i'm bumping them as we speak 2016-07-18 20:01:53 or my script is doing it 2016-07-18 20:02:09 i can push what i got so far 2016-07-18 20:02:34 gr8 2016-07-18 20:04:44 What a disaster 2016-07-18 20:06:21 next fun thing will be to fix go sec issue and build everything that uses http cgi 2016-07-18 20:07:02 https://httpoxy.org/ 2016-07-18 20:07:06 oh well 2016-07-18 20:25:18 we need to extract the sources of all go apps to figure out what is affected 2016-07-18 21:05:03 \o/ 2016-07-18 21:05:11 gotta gns3 running on alpine!! 2016-07-18 21:05:17 server and gui! 2016-07-18 21:05:31 now i can go to sleep satisfied 2016-07-18 21:42:25 http://live555.com/liveMedia/public/ does not maintain previous releases (main/live-media) 2016-07-18 21:43:10 new release is live.2016.06.26 2016-07-18 23:02:21 vkris: that’s really “nice” from them… >_< so we must create a snapshot and store it in distfiles 2016-07-19 06:01:23 py-sphinx is broke 2016-07-19 06:04:41 huh 2016-07-19 06:04:51 it's missing sphinx-build for no obvious reason 2016-07-19 06:05:34 /usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: 'entry_points' 2016-07-19 06:05:34 warnings.warn(msg) 2016-07-19 06:05:34 /usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: 'extras_require' 2016-07-19 06:05:34 warnings.warn(msg) 2016-07-19 06:05:34 /usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: 'include_package_data' 2016-07-19 06:05:36 warnings.warn(msg) 2016-07-19 06:05:38 /usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: 'zip_safe' 2016-07-19 06:05:40 warnings.warn(msg) 2016-07-19 06:05:42 /usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: 'install_requires' 2016-07-19 06:05:45 warnings.warn(msg) 2016-07-19 06:05:47 hhat's probably it 2016-07-19 06:18:19 ncopa, i got a message saying that py-psutils is broken. I think that is due to the fact that py2 or py3 are not pulled automatically. Make sense having that ? http://sprunge.us/gOEO 2016-07-19 06:23:06 fabled, i think that setup.py should be patched 2016-07-19 06:23:36 fcolista, oh? 2016-07-19 06:23:45 oh. No. sorry. I didn't notice that it has "from setupools" 2016-07-19 06:23:49 py-sphinx 2016-07-19 06:23:53 the problem is that it does not install sphinx-build command 2016-07-19 06:24:03 the warning you get is due to distutils 2016-07-19 06:24:36 setup.py tries to use distutils rather than setuptools, which actually supports install_requires etc 2016-07-19 06:24:39 but distutils not 2016-07-19 06:24:54 i didn't notice that setup.py at very beginning has setuptools. 2016-07-19 06:24:56 Nevermind. 2016-07-19 06:24:57 setup is from setuptools 2016-07-19 06:25:00 yes. 2016-07-19 06:25:30 Didn't notice that at the very beginning..nevermind. Sorry for the noise 2016-07-19 06:25:34 it's weird 2016-07-19 06:25:46 even trying to build the older version now is missing it 2016-07-19 06:25:50 sounds like some dependency broke 2016-07-19 06:26:53 umh. 2016-07-19 06:27:20 py dependencies i touched yesterday it's py-six 2016-07-19 06:27:44 might be that the culprit. 2016-07-19 06:27:56 main/py-setuptools: new upstream version 24.0.2 2016-07-19 06:28:02 -pkgver=20.8.0 2016-07-19 06:28:02 +pkgver=24.0.2 2016-07-19 06:33:47 yes 2016-07-19 06:33:48 that's it 2016-07-19 06:33:54 py-setuptools 24.0.2 is broke 2016-07-19 06:34:00 all works on 20.8.x 2016-07-19 06:34:11 UH 2016-07-19 06:34:13 uh 2016-07-19 06:34:14 or maybe it needs more flags? 2016-07-19 06:34:42 there's 24.0.3 available fyi 2016-07-19 06:35:05 wanna try with that? 2016-07-19 06:35:24 ok. a sec. 2016-07-19 06:36:02 nope 2016-07-19 06:37:06 https://github.com/pypa/setuptools/blob/master/CHANGES.rst 2016-07-19 06:37:09 that's the changelog 2016-07-19 06:37:43 i don't see any obiouvs reason 2016-07-19 06:37:49 diff on build logs : http://sprunge.us/eTAD 2016-07-19 06:37:51 maybe the v21.1.0 2016-07-19 06:39:10 or #261: Exclude directories when resolving globs in package_data. 2016-07-19 06:39:42 v21.2.1 2016-07-19 06:39:50 hum 2016-07-19 06:39:51 umh 2016-07-19 06:40:05 maybe i diff the sources 2016-07-19 06:44:49 i don't think, though, that the UserWarning you get are related 2016-07-19 06:45:14 umh 2016-07-19 06:45:19 actually yes 2016-07-19 06:45:26 python setup.py --requires 2016-07-19 06:45:26 warnings.warn(msg) 2016-07-19 06:45:26 warnings.warn(msg) 2016-07-19 06:45:32 warnings.warn(msg) 2016-07-19 06:45:46 warnings.warn(msg) 2016-07-19 06:45:48 warnings.warn(msg) 2016-07-19 06:45:50 python setup.py --requires 2016-07-19 06:45:52 maybe some other lib needs update too 2016-07-19 06:45:52 warnings.warn(msg) 2016-07-19 06:45:54 warnings.warn(msg) 2016-07-19 06:45:56 warnings.warn(msg) 2016-07-19 06:45:58 warnings.warn(msg) 2016-07-19 06:46:00 warnings.warn(msg) 2016-07-19 06:46:56 seems that for "requires" options it uses distutils rahter than setuptools 2016-07-19 06:47:04 hmmh 2016-07-19 06:47:07 distutils does not support that options 2016-07-19 06:47:11 setuptools does 2016-07-19 06:47:59 from http://stackoverflow.com/questions/8295644/pypi-userwarning-unknown-distribution-option-install-requires 2016-07-19 06:48:16 yes 2016-07-19 06:48:20 ok 2016-07-19 06:48:23 distutils issue 2016-07-19 06:48:32 moving the imports for distutils before setuptools fixes it 2016-07-19 06:48:45 you've patched setup.py then 2016-07-19 06:49:03 ? 2016-07-19 06:49:21 no 2016-07-19 06:49:29 i think something changed in what they export 2016-07-19 06:49:36 and the order changes which pkg gets preferred 2016-07-19 06:49:40 http://sprunge.us/iCVA 2016-07-19 06:50:02 oh 2016-07-19 06:50:18 # -*- coding: utf-8 -*- 2016-07-19 06:50:18 from setuptools import setup, find_packages 2016-07-19 06:50:18 import os 2016-07-19 06:50:18 import sys 2016-07-19 06:50:18 from distutils import log 2016-07-19 06:50:19 import sphinx 2016-07-19 06:50:24 this is my setup.py 2016-07-19 06:50:36 huh 2016-07-19 06:50:39 it's already after setuptools 2016-07-19 06:51:16 sorry, patch is reversed 2016-07-19 06:52:03 http://sprunge.us/XZRE 2016-07-19 06:52:14 umh 2016-07-19 06:52:25 aoh 2016-07-19 06:52:26 wait 2016-07-19 06:52:40 no 2016-07-19 06:52:56 never mind that 2016-07-19 06:53:00 http://pastebin.com/rZ6Zc7pV 2016-07-19 06:53:15 umh 2016-07-19 06:53:17 i had old, working py-setuptools installed 2016-07-19 06:53:34 sigh 2016-07-19 06:53:38 distutils just import log, though 2016-07-19 06:54:01 seems that py-setuptools is just boke 2016-07-19 06:54:56 20.8.0 was working 2016-07-19 06:54:59 i bisect where it broke 2016-07-19 07:01:50 seems it breaks in 20.8.1 2016-07-19 07:01:51 http://sprunge.us/OQHb 2016-07-19 07:02:36 yes 2016-07-19 07:03:03 maybe should be passsed in an alternative way? 2016-07-19 07:04:47 reverting that commit fixes it 2016-07-19 07:05:07 should be sent to the upstream then 2016-07-19 07:07:21 probably yes 2016-07-19 07:07:27 i wonder why no one has complained 2016-07-19 07:07:39 'cause is a warning 2016-07-19 07:07:44 but the package breaks 2016-07-19 07:07:47 and nobody paid attention 2016-07-19 07:08:10 it's the bin file that breaks 2016-07-19 07:08:38 i think most of the packages we are using are relying on python libs 2016-07-19 07:08:49 *i supppose* 2016-07-19 07:20:48 filed https://github.com/pypa/setuptools/issues/659 2016-07-19 07:22:15 gr8 2016-07-19 07:32:22 morning ncopa 2016-07-19 07:32:31 i got a message saying that py-psutils is broken. I think that is due to the fact that py2 or py3 are not pulled automatically. Make sense having that ? http://sprunge.us/gOEO 2016-07-19 07:32:39 fcolista, should we just add the revert so we get llvm built (which depends on py-sphinx that is currently broke) 2016-07-19 07:33:05 fabled, yes, i think so. 2016-07-19 07:33:48 would you create the revert patch and apply it? 2016-07-19 07:33:54 on it 2016-07-19 07:34:05 and upgrade py-setuptools to the latest version, while yor are there 2016-07-19 08:18:38 fcolista: wouldnt that introduce a circular dep with the install_if? 2016-07-19 08:19:14 dunno. My question is: if python is not installed? 2016-07-19 08:19:38 then py-psutils ships only itself, and not py2 or py3 2016-07-19 08:19:45 and py-psutils is actually empty 2016-07-19 08:20:10 makes sense what i'm saying or i'm missing something? 2016-07-19 08:25:47 I thought we agreed that py-pkgname pulls py2 2016-07-19 08:25:49 not py3 2016-07-19 08:26:07 and somewhere down the road we just drop all py- metapackages 2016-07-19 08:26:23 yes 2016-07-19 08:26:40 ok, just checking if we're on the same page 2016-07-19 08:26:51 yes, we are. 2016-07-19 08:26:56 Now, the point is: 2016-07-19 08:27:09 apk add py-psutils by itself does not pull python 2016-07-19 08:27:29 and py-psutils actually is empty 2016-07-19 08:27:31 but it pulls py2-psutils? 2016-07-19 08:27:35 no 2016-07-19 08:27:38 why? 2016-07-19 08:27:47 if python or python2 is not installed, it does not 2016-07-19 08:27:55 because python is in "install_if" 2016-07-19 08:28:05 it should do that unconditionally imho 2016-07-19 08:28:13 install python2 if needed 2016-07-19 08:28:28 for compatibility reasons 2016-07-19 08:28:59 py-pkgname should be seen as alias to py2-pkgname on higher lever 2016-07-19 08:29:00 if it is doen unconditionally, then we need to put "python" in depends= of main APKBUILD 2016-07-19 08:29:11 level even 2016-07-19 08:29:38 not sure what ncopa's stance is 2016-07-19 08:29:43 if we follow lua or not 2016-07-19 08:33:46 for what it's worth, it doesn't look like lua-* pulls any lua by default 2016-07-19 08:34:36 umh 2016-07-19 08:34:38 I guess it makes sense 2016-07-19 08:34:47 then if I install lua5.1, it pulls lua5.1-something 2016-07-19 08:35:04 i think is true also the other way aroung 2016-07-19 08:35:06 *round 2016-07-19 08:35:08 i mean 2016-07-19 08:35:21 yeah 2016-07-19 08:35:23 if i install lua5.1-something, i would expect that lua5.1 got installed 2016-07-19 08:35:30 so we should probably follow this for consistency 2016-07-19 08:35:40 since otherwise lua5.1-something would not work 2016-07-19 08:36:16 with transition from py/py2 to py3, when ppl installs py-something, result is that package is empty 2016-07-19 08:36:17 so 2016-07-19 08:36:31 so I can imagine it's confusing, but ok 2016-07-19 08:36:31 1) we need to inform ppl that they should use py2 or py3 2016-07-19 08:36:37 because then they install python2 2016-07-19 08:36:43 apk pulls py2-something 2016-07-19 08:37:01 yeah, but we will put that on alpine-devel and then release notes 2016-07-19 08:37:58 but it means packages shouldn't depend on py-pkgname unless they are compatible with both pythons 2016-07-19 08:38:20 this is another layer 2016-07-19 08:38:31 py-something will ship both py2 and py3 2016-07-19 08:38:46 fcolista: why would you install a python module without installing python? 2016-07-19 08:39:04 ncopa: that's the case with lua now 2016-07-19 08:39:08 ncopa: i would expect that if i install py-module, py is installed 2016-07-19 08:39:15 not the contrary 2016-07-19 08:39:20 apk add lua-lgi pulls nothing 2016-07-19 08:39:29 and i think thats ok 2016-07-19 08:39:32 that's not correct imho. 2016-07-19 08:39:38 i think it is ok 2016-07-19 08:39:47 ok, you're the chief :) 2016-07-19 08:39:51 because you will have to specify *which* lua you want 2016-07-19 08:39:51 heh 2016-07-19 08:39:55 exactly 2016-07-19 08:40:01 lua 5.1 != lua 5.2 2016-07-19 08:40:08 same with python2 and python3 2016-07-19 08:40:09 so py-pkgname should be empty after all 2016-07-19 08:40:17 then pull py2 or py2 2016-07-19 08:40:20 it is empty, actually. 2016-07-19 08:40:20 py3* 2016-07-19 08:40:35 if you make an application using python 2016-07-19 08:40:47 then you need to specify if it is a python2 or python3 app 2016-07-19 08:41:12 theoretically there might be a python version independent package 2016-07-19 08:41:15 i think is matter of "historical" reason. So far, when you install a py-package, python is installed. Now it's no longer like that. 2016-07-19 08:41:18 if you go for python3, and you use the psutils module 2016-07-19 08:41:22 so it should depend on empty py-* packages 2016-07-19 08:41:39 then you need explicitly pull in py3-psutils as dep 2016-07-19 08:41:47 that's fair point, but we have release notes for a reason 2016-07-19 08:41:53 and upgrade path is clear 2016-07-19 08:42:08 +1 2016-07-19 08:42:15 so in the long run you should not really depend on py-psutils, you should depend on either py2-* or py3-* 2016-07-19 08:42:19 but not py-* 2016-07-19 08:42:24 right. 2016-07-19 08:42:33 if user already has python2 installed, py-* will pull py2-* on upgrade to 3.5 2016-07-19 08:42:38 fcolista: yes, it does not behave as it used to do 2016-07-19 08:42:38 Actually, the "issue" is in the transitional phase. 2016-07-19 08:42:44 but e also used to only support python2 2016-07-19 08:42:56 right. 2016-07-19 08:43:16 fcolista, huh, the setuptools issue is weirder 2016-07-19 08:44:55 why so fabled ? 2016-07-19 08:45:07 it seems to not be reliably fixed with the revert 2016-07-19 08:45:18 uh 2016-07-19 08:45:35 i wonder if it's some musl issue 2016-07-19 08:48:02 fabled, i'm wodnering then if other musl-based distro has the same issue 2016-07-19 08:48:17 that's what void does: 2016-07-19 08:48:18 http://sprunge.us/OjiH 2016-07-19 08:48:48 no patch 2016-07-19 08:48:53 dunno if it helps, though 2016-07-19 08:52:37 what is the failure case? 2016-07-19 08:52:51 sphinx packaging fails 2016-07-19 08:53:00 it misses lots of files 2016-07-19 08:53:02 what version of setuptools? 2016-07-19 08:53:19 tried various 2016-07-19 08:53:22 /usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: 'entry_points' 2016-07-19 08:53:22 warnings.warn(msg) 2016-07-19 08:53:27 that's the first error 2016-07-19 08:53:31 when things go wrong 2016-07-19 08:53:37 is this only on 2.7, or is it on 3.x as well? 2016-07-19 08:53:41 edge 2016-07-19 08:53:49 python 2.7 / 3.x 2016-07-19 08:54:09 2.7.x 2016-07-19 08:54:59 oh. 2016-07-19 08:55:13 we are only shipping 3.x so I can't really toss this at a builder. 2016-07-19 08:55:48 python3 looks working 2016-07-19 08:59:16 this is happening with other py2 packages actually 2016-07-19 09:00:17 is py-setuptools broke? 2016-07-19 09:00:52 i dunno 2016-07-19 09:00:55 could be python too 2016-07-19 09:01:18 i tried various py-setuptools versions and it mostly did not work, i thought i found the faulty commit but it turned out to be fluke 2016-07-19 09:01:50 ok. I'll hold my py-djanog update a bit then 2016-07-19 09:02:01 weird 2016-07-19 09:02:02 food 2016-07-19 09:02:11 ncopa, barthalion: does it make sense having py-package for new py aports? 2016-07-19 09:02:36 depends if you want support both python2 and python3 2016-07-19 09:02:44 i think for the new one we should ship two separated packages 2016-07-19 09:02:58 but that also adds overhead 2016-07-19 09:03:03 maintenance overhead 2016-07-19 09:03:04 let's say yes: we will have py-package 2016-07-19 09:03:12 you'd need bump both when you upgrade 2016-07-19 09:03:13 that we will never use 2016-07-19 09:04:14 when we will drop py2, we should rewrite the APKBUILD, though 2016-07-19 09:04:43 for new packages we should probably only do py3-* 2016-07-19 09:04:47 however 2016-07-19 09:05:01 at the time we drop py2 we likely have to deal with py4 2016-07-19 09:05:28 umh.. 2016-07-19 11:13:16 is py-setuptools ok now? 2016-07-19 11:21:37 seems not, ncopa 2016-07-19 11:24:53 fcolista: please read https://github.com/alpinelinux/aports/commit/62e2e52002986d8e8f88e0683be0756ee801906e#commitcomment-18296948 2016-07-19 11:26:00 jirutka, oh 2016-07-19 11:26:04 good to know 2016-07-19 11:26:13 i was not aware of files.pythonhosted.org 2016-07-19 11:26:17 thx for pointing it out 2016-07-19 11:26:33 me neither, it’s quite confusing what they did 2016-07-19 11:27:35 i think i've some packages with pypi.python.org 2016-07-19 11:27:42 I’ve also discussed it with one friend of mine who works on Fedora and they’re also already moving to files.pythonhosted.org 2016-07-19 11:27:58 why are tehy not set the correct download link rather than this crap? 2016-07-19 11:28:29 fcolista: because pypi.python.org is basically dead, but pypi.org is not finished yet 2016-07-19 11:29:21 fcolista: and if you’re asking whey they have broken links before even launching new site, then I have no polite answer :) 2016-07-19 11:29:43 fcolista: correction: s/pypi.org/pypi.io/ 2016-07-19 11:31:04 maybe answer is in this awfully long thread https://bitbucket.org/pypa/pypi/issues/438/backwards-compatible-un-hashed-package, but I didn’t read it all 2016-07-19 11:32:49 btw I just discovered out that there are still few alpine packages with wrong URL; that’s my mistake, I assumed that source URL is always quoted, so my regex didn’t catch unquoted URLs 2016-07-19 11:39:22 jirutka, there's no possibility to browser files.pythonhosted.org 2016-07-19 11:39:24 what a crap 2016-07-19 11:39:46 yeah 2016-07-19 11:40:11 it’s just a CDN, it should not be browsable 2016-07-19 11:40:28 so we might update a download link, and the link is broken 2016-07-19 11:40:36 and we can't see why 2016-07-19 11:40:50 or if the files is available or not 2016-07-19 11:41:21 since change only the url does not assure that the file is actually downloaded from upstream url 2016-07-19 11:41:32 rather, it is picked up from the cache 2016-07-19 11:41:38 when the file is not available, you get 404 2016-07-19 11:41:44 really? 2016-07-19 11:41:46 yes 2016-07-19 11:41:46 :) 2016-07-19 11:41:58 that’s how HTTP works… 2016-07-19 11:41:58 this http protocol is clever! 2016-07-19 11:43:38 HTTP is very cleverly designed 2016-07-19 11:44:36 the problem is, as always, in people… like PHP kids that doesn’t know anything but GET and maybe POST, don’t care about HTTP statuses etc. 2016-07-19 11:44:51 did you get that i'm kidding, right? 2016-07-19 11:45:07 actually, I don’t, I’m quite confused now 2016-07-19 11:45:44 that http returns 404 when a file is not available...c'mon guy ;) 2016-07-19 11:45:55 what else do you expect? 2016-07-19 11:46:05 ACTION smells sarcasm 2016-07-19 11:46:15 ACTION is not sure 2016-07-19 11:46:18 that’s how it should work, if file is there, then 200 and file content, if not, then 404… what else do you want? 2016-07-19 11:46:44 nevermind jirutka 2016-07-19 11:46:56 heh 2016-07-19 11:47:22 and actully, the links we use doesn’t return 200, it returns redirect to an actual file with hash in the url 2016-07-19 11:47:30 *don’t 2016-07-19 11:50:49 it’s explained in https://bitbucket.org/pypa/pypi/issues/438/backwards-compatible-un-hashed-package, this solution is actually good and reasonable, the problem is just how they broke existing links on pypi.python.org 2016-07-19 11:51:27 fcolista: i prefer the smell of doppio 2016-07-19 11:51:38 clandmeter, hehe.. 2016-07-19 11:51:41 doppio? 2016-07-19 11:51:42 ACTION too 2016-07-19 11:53:41 doppio: A derogatory name for a Starbucks employee or Starbucks junky. Coined from how they make you order a double espresso. WTF? 2016-07-19 11:54:21 ACTION is going to pickup one 2016-07-19 11:54:52 ACTION offers a doppio to jirutka  2016-07-19 11:55:15 fcolista: pardon, but is it so hard to just run abuild checksum before pushing totally wrong URL to the repository?! 2016-07-19 11:56:12 jirutka, no, it's not hard. As i was saying before, when package has the same version, is not downloaded, but took from the cache. 2016-07-19 11:56:44 fcolista: yes, that’s what abuild do, not pypi 2016-07-19 11:57:06 are we talking about abuild checksum, right? 2016-07-19 11:57:15 hm, yeah, so abuild checksum can’t help in this case 2016-07-19 11:57:24 right, that's the point. 2016-07-19 11:57:25 So 2016-07-19 11:57:29 what we should do 2016-07-19 11:57:34 maybe abuild fetch? 2016-07-19 11:57:48 (and this is what i was trying to explain before, before you mentioned http codes) 2016-07-19 11:58:18 but this is not pypi’s fault 2016-07-19 11:58:21 is doing apkbuild cleancache 2016-07-19 11:58:24 it has nothing to do with it 2016-07-19 11:58:30 then abuild checksum 2016-07-19 11:58:32 then push 2016-07-19 11:58:38 also the URL is very clearly explained in https://github.com/alpinelinux/aports/pull/147#issuecomment-230739905 2016-07-19 11:58:47 but nevermind, I shoud leave the restaurant and go to the office 2016-07-19 11:59:05 the pythonhosted fault (but this is my opinion), is not having a browseable tree 2016-07-19 11:59:13 if you had 2016-07-19 11:59:23 you might avoid the abuild cleancache 2016-07-19 11:59:25 ... 2016-07-19 11:59:25 you can just curl the URL and you will see 2016-07-19 11:59:29 it's only that 2016-07-19 11:59:31 how can browsable tree help? 2016-07-19 11:59:50 browsable tree is only for humans who opens the url in browser 2016-07-19 11:59:57 it can’t help to abuild 2016-07-19 12:01:32 ACTION is not able to help jirutka to understand what he's saying 2016-07-19 12:01:47 I will look at it later… 2016-07-19 12:02:34 py-setuptools breaks python2.7 packages...new python upgrades got broken 2016-07-19 12:02:47 python2 package upgrades 2016-07-19 12:39:34 fcolista, any insight on the py-setuptools issue? 2016-07-19 12:42:59 fabled, not yet. 2016-07-19 12:43:21 so far, other python2.7 packages fail with this py-setuptools 2016-07-19 12:43:55 so, i'm wondering if py-packages needs to support new py-setuptools 2016-07-19 12:44:11 or py-setuptools has some sort of "legacy mode" 2016-07-19 12:47:14 should we just revert py-setuptools to last known working version (20.8.0) ? 2016-07-19 12:48:03 i'm tempted to do that...but i'm pretty sure that someone that is not aware of this issue will upgrade py-setuptools again. 2016-07-19 12:48:10 add comment 2016-07-19 12:48:19 not to upgrade until the issue can be verified 2016-07-19 12:48:48 yes 2016-07-19 12:48:52 sounds good to me 2016-07-19 12:49:05 dunno what's the ncopa's opionion though 2016-07-19 13:09:43 ncopa: aports currently broken? 2016-07-19 13:10:17 ncopa: please merge https://github.com/alpinelinux/aports/pull/168 2016-07-19 13:10:37 did we just rename python? 2016-07-19 13:10:47 ncopa: my regexp missed few packages before, so this patch fixes rest of py-* packages in main 2016-07-19 13:11:05 clandmeter: yes, barthalion renamed it yesterday to python2 2016-07-19 13:11:22 what about pkgs that depend on it? 2016-07-19 13:11:50 clandmeter: python2 provides="python", so it should work, theoretically… 2016-07-19 13:11:58 eyah right 2016-07-19 13:12:00 or replaces=python? 2016-07-19 13:12:02 don’t remember now 2016-07-19 13:12:15 it doesnt work here 2016-07-19 13:12:28 clandmeter: uh, actually both :) https://github.com/alpinelinux/aports/blob/master/main/python2/APKBUILD#L10-L11 2016-07-19 13:12:41 not if python is not build yet 2016-07-19 13:13:01 and believe me, its not :) 2016-07-19 13:13:26 clandmeter: I believe you, I’m actually no surprised that python is now broken… 2016-07-19 13:13:46 maybe ill just checkout before the change. it will give me less headache. 2016-07-19 13:14:04 clandmeter: have you run apk update…? 2016-07-19 13:14:07 wasnt there also gettext madness? 2016-07-19 13:14:19 jirutka: my world is empty 2016-07-19 13:14:28 well alomst :) 2016-07-19 13:14:32 its aarch64 2016-07-19 13:14:33 clandmeter: yes, this was another issue of yesterday 2016-07-19 13:14:51 im trying to build alpine-sdk 2016-07-19 13:15:14 ok, ill look into git history and checkout before the madness 2016-07-19 13:15:25 clandmeter: you’re right, it doesn’t work for me either 2016-07-19 13:16:03 its edge for a reason, just inconveniant right now. 2016-07-19 13:16:05 clandmeter: please tell barthalion, he apparently didn’t test it properly and I don’t wanna clean his mess… 2016-07-19 13:16:47 clandmeter: I dissagree, edge *should not* mean that it’s broken in this way… 2016-07-19 13:17:11 you are free to dissagree 2016-07-19 13:17:13 clandmeter: IMO it’s okay if there are some ABI incompatibilities, that’s from principle, but not when someone doesn’t test patches before pushing 2016-07-19 13:17:54 there are 2 things for sure, nobody's perferct, and everybody has too little time. 2016-07-19 13:18:21 i guess http://git.alpinelinux.org/cgit/aports/commit/?id=b2afb194948f37def6aede9e402fc06c9c13d188 should be safe? 2016-07-19 13:18:26 there is one thing for sure, any of these facts can’t justfiy lack of testing 2016-07-19 13:18:45 looks like it. ill use that hash 2016-07-19 13:18:55 ah shit 2016-07-19 13:18:57 i dont have git 2016-07-19 13:19:20 ill need to check it out on another box 2016-07-19 13:19:36 I must do some work now, I hope that barthalion will fix it… 2016-07-19 13:20:09 jirutka, what's the broken thing you're referring to? 2016-07-19 13:20:17 we already have discussion with fabled about this few months ago and I think that the result was quite clear, we need to add some functionality to abuild before this step with python 2016-07-19 13:20:31 and here we go, the exact problem we knew about few months ago is here 2016-07-19 13:20:53 fcolista: clean work, e.g. apk add py-setproctitle… it doesn’t pull python 2016-07-19 13:21:21 it should not 2016-07-19 13:21:23 *clean world 2016-07-19 13:21:33 should not?! 2016-07-19 13:21:37 we've discussed it today 2016-07-19 13:21:41 no, it should not. 2016-07-19 13:22:00 is going to be written in the next release notes 2016-07-19 13:22:03 this is definitely not expected behaviour… if some package depends on other, it should pull it, that’s the whole spirit of dependency management 2016-07-19 13:22:08 uh, okay… 2016-07-19 13:22:14 we don't do that with lua 2016-07-19 13:22:27 lua5.x-package does not ship lua5.x 2016-07-19 13:22:32 so our dependency management is somehow half-functional, great… 2016-07-19 13:23:12 no, is not 2016-07-19 13:23:20 so if user needs some package X, that has transitive dependency on some python package, it will just not work out of box 2016-07-19 13:23:30 you need to install python first 2016-07-19 13:23:37 the python version you want 2016-07-19 13:23:42 and user must investigate what the hell happend, because (s)he may not know that it somehow depends on python 2016-07-19 13:23:59 and then the pyX package to install 2016-07-19 13:24:10 how the hell should user know that some package has transitive dependency on python? 2016-07-19 13:24:27 jirutka, i don't think is that hard for the alpine user base figure out that for py2-package needs to install python2 2016-07-19 13:24:28 it’s obvious with py-* package, but what about non-py packages? 2016-07-19 13:24:38 py-* will be dropped in the future 2016-07-19 13:24:38 you don’t understand my point 2016-07-19 13:24:52 and py-* does not contain anything 2016-07-19 13:24:57 it' not a meta package. 2016-07-19 13:25:09 I know 2016-07-19 13:25:33 the problem is that there are dependencies not written in python, that just use some python stuff… so it depends on py-something… 2016-07-19 13:25:38 or am I wrong? 2016-07-19 13:26:07 the py-dependency should be renamed in py2-depenency or py3-dependency 2016-07-19 13:26:34 basically, the py-dependency should not exists anymore 2016-07-19 13:27:38 so what if some non-python package needs some python package, but don’t care about exact variant (py2 or py3)? 2016-07-19 13:28:00 what do you mean you don't case about the exact variant? 2016-07-19 13:28:04 *care 2016-07-19 13:28:28 you need just a script in /usr/bin… 2016-07-19 13:28:35 don’t care if it runs on python2 or python3 2016-07-19 13:28:41 when you create the APKBUILD, it's your responsability to figure out that. 2016-07-19 13:28:46 you should 2016-07-19 13:28:51 why? 2016-07-19 13:29:17 'cause otherwise won't work. You need to know if is py2 or py3 2016-07-19 13:29:28 seems one of my 2 assumptions was incorrect. 2016-07-19 13:29:30 for example, if your program needs /usr/bin/pygmentize 2016-07-19 13:30:01 you really don’t care if it’s pygments for python2 or python3… but with the current solution, you must set one of these 2016-07-19 13:30:20 pygmentize can be py2 or py3, cause you have #!/usr/bin/pythonX 2016-07-19 13:30:27 if you use python3 variant and user has already python2 installed, you will force him python3 2016-07-19 13:30:48 or vice versa 2016-07-19 13:31:04 py3 is retro-compatible with py2? 2016-07-19 13:31:10 omg 2016-07-19 13:31:44 interesting, textinfo continius even if it issues a fatal error.. 2016-07-19 13:31:47 imagine that your application, not written in Python, just calls /usr/bin/pygmentize 2016-07-19 13:32:04 your application doesn’t care if it runs on python2 or python3, it just needs to call /usr/bin/pygmentize and get result 2016-07-19 13:32:40 but yet, when you create an alpine package for it, you must decide if it should depend on py2-pygments or py3-pygments… 2016-07-19 13:33:26 maybe you choose py3-pygments… and maybe user already has python2 installed… then this package will force him python3, even when pymentize is available even as python2 variant 2016-07-19 13:33:41 yes. 2016-07-19 13:34:16 that's because we are going to drop, in the long term, py2 2016-07-19 13:34:27 not sure how "long" is this "long" 2016-07-19 13:35:22 fabled, i think we should revert the py-setuptools upgrade 2016-07-19 13:35:29 that’s great, but unfortunately, Python 3 is here since 2008 and still there are a lot of modules that doesn’t work on python3 :( 2016-07-19 13:36:04 python 2.7 will be supported till 2020 and unfortunately there’s a great chance that it will be even longer, when some fucking big company start complains that their legacy shit doesn’t work on Python 3 2016-07-19 13:36:54 that said, I would be happy with dropping py2-* packages… but I’m afraid that a lot of users would not :( 2016-07-19 13:38:35 but well, if your plan is to update all packages to use python3 by default and keep python2 just for legacy stuff, then it’s fine 2016-07-19 13:38:59 that's the direction. 2016-07-19 13:39:05 okay, then I have no complains :) 2016-07-19 13:39:17 I’m just worry how will users accept it 2016-07-19 13:39:32 but I consider it a good direction 2016-07-19 13:51:58 damn, cd main/git && abuild -R takes ages :) 2016-07-19 13:52:22 would it be crazy if install_if= supports || <= OR 2016-07-19 13:52:22 eg. install_if=(python=3.2||2.7) 2016-07-19 13:53:20 or already there ! 2016-07-19 13:53:38 vkris: how this can help? 2016-07-19 13:54:08 vkris: the problem is that we don’t have a mechanism to install one of the variants by default 2016-07-19 13:54:34 if a python- can use any python i.e 2.x || 3.x then it does not pull the other if one is already installed 2016-07-19 13:55:30 vkris: now, that’s no how it works 2016-07-19 13:55:50 \o/ 2016-07-19 13:55:55 just thought should say it out 2016-07-19 13:57:35 clandmeter: fcolista already explained it; we want to follow what ncopa did with multiple lua versions 2016-07-19 13:57:37 vkris: to be more clear, the problem is when user don’t have python2 or python3 installed yet; then install_if="python…" can’t help 2016-07-19 13:58:06 barthalion: sure, but currently its broken 2016-07-19 13:58:26 in this it pick one that is default supported by AL 2016-07-19 13:58:30 if you bootstrap, it wants to pull python which does not exist when pythonX is not build. 2016-07-19 13:58:33 clandmeter: and by broken you mean that python2 isn't automatically installed? 2016-07-19 13:58:34 and that is v3.x 2016-07-19 13:58:39 vkris: we just don’t have a mechanism how to tell ”if there are multiple variants, just install one of them, or install X by default” 2016-07-19 13:59:12 yes, then that mechanism is needed 2016-07-19 13:59:39 or a term like "preferred" 2016-07-19 13:59:52 vkris: yes, that’s what we need even for java, to make it work with multiple versions seamlessly 2016-07-19 14:00:53 hmm.. ok then its not that crazy, just theoritical issues 2016-07-19 14:01:28 vkris: I wouldn’t call it a theoretical issue, it’s very practical issue… 2016-07-19 14:02:20 :) 2016-07-19 14:10:58 quite nice that Alpine Linux is now also here: 2016-07-19 14:10:59 https://gns3.com/support/docs/linux-installation 2016-07-19 14:12:04 :) 2016-07-19 14:13:36 hey 2016-07-19 14:13:43 whats the status of python? 2016-07-19 14:13:47 what is the current problem? 2016-07-19 14:14:06 py-setuptools needs to be rolled back. Packages with python2 are not built correctly 2016-07-19 14:15:19 ncopa: http://www.irclogger.com/.alpine-devel/2016-07-19#1468935107-1468935206 and http://www.irclogger.com/.alpine-devel/2016-07-19#1468935256-1468935545 2016-07-19 14:16:20 ncopa: please merge https://github.com/alpinelinux/aports/pull/168 2016-07-19 14:23:13 that could be eg. install_if=(python=3.2*||python=2.7) 2016-07-19 14:23:25 where * == preferred 2016-07-19 14:23:31 vkris: well, try it yourself :) 2016-07-19 14:23:43 :) 2016-07-19 14:24:30 vkris: really, just create your repo and try how it works, it the best way how to learn it 2016-07-19 14:24:46 jirutka: thats does not work per today either 2016-07-19 14:24:56 vkris: ncopa ? 2016-07-19 14:25:02 pardon, ncopa: ? 2016-07-19 14:25:10 i mean apk add pygmentize would pull in python2 explicitly 2016-07-19 14:25:31 ncopa: yes, because we didn’t have python3 variant 2016-07-19 14:25:52 also then /usr/bin/pygmentize binary would have #!/usr/bin/python 2016-07-19 14:26:17 ncopa: that’s another problem, we’ve been discussing it yesterday 2016-07-19 14:26:19 which would need to point to either 2016-07-19 14:27:08 making that work would require that we implemented some sort of "update-alternatives" 2016-07-19 14:28:01 the install_if hack gets us fairly close though 2016-07-19 14:28:15 apk add py-somedep 2016-07-19 14:28:38 is like saying, i dont care if its python2 or python3, any will do 2016-07-19 14:28:48 vkris: to test these things, it should be sufficient to just follow https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package and add ~/packages/xxx to your /etc/apk/repositories 2016-07-19 14:28:53 if you happen to have python2 installed it will pull in py2-somedep 2016-07-19 14:29:13 and if you have python3 it will also pull in py3-somedep 2016-07-19 14:29:32 ncopa: that’s obvious, but the problem is when you don’t have neither python2 or python3 installed 2016-07-19 14:29:48 ncopa: then you will end up with malfunction package because python will be missing 2016-07-19 14:30:10 ncopa: or we must force specific py[23] package variant as a dependency 2016-07-19 14:30:29 something needs to make that decision 2016-07-19 14:30:55 we could do provides=python on both python2 and python3 2016-07-19 14:31:01 and let apk decide which to pick 2016-07-19 14:31:20 or have some sort of "update-alternatives" or "eselect" 2016-07-19 14:31:24 ncopa: then you can’t use python2 and python3 simultaneously, can you? 2016-07-19 14:31:40 ncopa: with provides=python 2016-07-19 14:31:49 dont know 2016-07-19 14:31:58 ncopa: we’ve already discussed this stuff few months ago with fabled 2016-07-19 14:32:08 with openjdk? 2016-07-19 14:32:17 ncopa: it seems that it’s necessary to document it, because it’s not easy and people forgets quickly 2016-07-19 14:32:18 yes 2016-07-19 14:32:29 but python is eaxctly the same case 2016-07-19 14:32:40 did we come to some conclusion of it? 2016-07-19 14:33:09 i think we lean towards not letting apk decide that 2016-07-19 14:33:17 ncopa: yes, that we need to implement some mechanism how to choose “default” 2016-07-19 14:33:59 til we have that in place, i think we need to do explicit depends 2016-07-19 14:34:11 if #!/usr/bin/python is provided by python2 2016-07-19 14:34:24 and pygmentize uses that line 2016-07-19 14:34:36 it will have an explicit depends on python2 2016-07-19 14:35:00 ncopa: it should always be provided by python2 per https://www.python.org/dev/peps/pep-0394/ 2016-07-19 14:35:06 if we want provide a python3 pygmentize we'd need another pygmentize package with #!/usr/bin/python3 2016-07-19 14:35:50 ncopa: not necessarily, there are multiple options how to solve it, take a look at gentoo for example 2016-07-19 14:36:02 ncopa: another option is to just use symlinks 2016-07-19 14:36:04 <@ncopa> til we have that in place, i think we need to do explicit depends 2016-07-19 14:36:31 there are options how to solve it 2016-07-19 14:36:41 yes 2016-07-19 14:36:59 once it is solved, on a general level, we can adapt our apkbuilds and figure out how to do dependency resolving 2016-07-19 14:37:36 til then i see no other option but having explicit depends 2016-07-19 14:38:35 as i understand, solving it will require some change in apk? 2016-07-19 14:39:11 we have also the problem with different python implementations 2016-07-19 14:39:24 we have the same problem with lua (5.1) and luajit 2016-07-19 14:39:29 ncopa: yes, this problem is very general, as I said before 2016-07-19 14:41:05 ncopa: therefore I really don’t like this unrestrained approach of making ad-hoc changes before solving all consequences and documenting it somewhere… now we’re in the state that some things are broken from user’s point of view and that’s not good IMO 2016-07-19 14:41:56 i dont think its ideal either 2016-07-19 14:41:58 but 2016-07-19 14:42:07 we have talked about python3 for years 2016-07-19 14:43:00 at some point we need to "just shoot the engineer" and move forward 2016-07-19 14:43:40 which is why i'm ok'ish with breaking things in edge once in a while 2016-07-19 14:43:48 even if we try avoid that 2016-07-19 14:44:00 ncopa: yes, I’m also glad that we’re finally making it happen, but I’m afraid that it may cause more damage than pros; I was already planning to solve it, because without python3 I can’t enforce Alpine for BigClown platform 2016-07-19 14:44:25 in any case, it needs to be fixed before v3.5 2016-07-19 14:44:32 with an upgrade path 2016-07-19 14:45:19 jirutka: do you have better solution at hand? 2016-07-19 14:47:42 and yes, we will probably need to keep python2 around for a while 2016-07-19 14:47:43 ncopa: currently I don’t have, I need to find some spare time to document the current state, challenges and options how to solve it… or at least that used to by me plan 2016-07-19 14:48:03 right 2016-07-19 14:48:11 it also involves lua 2016-07-19 14:48:18 and openjdk 2016-07-19 14:48:24 and maybe even ruby 2016-07-19 14:48:24 *nod* 2016-07-19 14:48:28 heh 2016-07-19 14:48:38 hopefully not ruby 2016-07-19 14:48:54 but potentially yes 2016-07-19 14:48:58 well, we have MRI and JRuby 2016-07-19 14:49:25 but yeah, ruby is not so urgent 2016-07-19 14:49:47 I think that JRuby is not so widespread 2016-07-19 14:50:03 personally i think the way we do lua packages has worked relatively good 2016-07-19 14:50:29 we'll see if that approach can handle python scale 2016-07-19 14:51:07 yeah 2016-07-19 14:51:17 so many work and so little time :( 2016-07-19 14:51:24 :) 2016-07-19 14:51:28 yes 2016-07-19 14:51:48 I need to find same way how to get money from all the stuff on open-source projects I do :) 2016-07-19 14:51:48 some of those tasks needs some dedicated effort 2016-07-19 14:52:21 i mean, it would basically require that someone working on them fulltime 2016-07-19 14:52:32 same with the abuild/APKBUILD redesign 2016-07-19 14:52:36 this would be ideal 2016-07-19 14:52:53 i might be able to work on some of it 2016-07-19 14:53:12 i can have one project like that, at the time 2016-07-19 14:53:16 Don't worry, with or without it, jirutka will criticize it 8) 2016-07-19 14:53:17 but multiple, no 2016-07-19 14:53:44 someone will always find something that could be better 2016-07-19 14:53:47 or improved 2016-07-19 14:54:01 ncopa: I can’t even count how many projects I’m currently involved :( 2016-07-19 14:54:45 dalias tweeted about an interesting paper on OSS funding 2016-07-19 14:55:36 https://twitter.com/RichFelker/status/754896760691130368 2016-07-19 14:55:41 ncopa: I hope that I’ll eventaully convince my co-workers that Alpine is far better than Raspberrian for your platform and when the company get bigger, I’d be able to work on Alpine in my job 2016-07-19 14:56:15 :) 2016-07-19 14:57:43 the paper says that people who manage to work on OSS projects fulltime uses words like "lucky" about it 2016-07-19 14:58:32 yeah 2016-07-19 15:01:56 are we ok with this: 2016-07-19 15:02:01 apk add lua-somemodule 2016-07-19 15:02:11 result in non-functional 2016-07-19 15:02:25 for the reason that you haven't selected which lua you want use 2016-07-19 15:02:48 to "solve" that, you need to also install a lua variant: apk add lua5.3 2016-07-19 15:03:17 yes, that’s the exact problem we now have even with python, and my opinion is that it’s not okay, b/c it may not be always clear that some package needs lua/python/whatever, in case of transitive dependencies 2016-07-19 15:03:41 ok, so we are not ok with it... 2016-07-19 15:03:51 well jirutka is not ok with it 2016-07-19 15:04:42 so, the package needing it will have to pick one 2016-07-19 15:04:43 it may be ok-ish in the case of python packages, but if user install some non-python package that just uses some program written in python, then it’s totally not clear that he must also install python, package manager should do that for him 2016-07-19 15:04:59 that is differnt issue imo 2016-07-19 15:05:18 some program written in python 2016-07-19 15:05:33 but if Alpine direction is to use python 3 as default, so declare dependencies on py3- packages, not py-, then it may not be problem 2016-07-19 15:05:51 that is the proposed solution 2016-07-19 15:05:55 to that problem 2016-07-19 15:06:17 when we ship a python app, we need to pick a python version 2016-07-19 15:06:42 similar that when we build gtk app we need pick either gtk2 or gtk3 2016-07-19 15:06:46 and stick to it 2016-07-19 15:07:01 in some special cases we provide support for both 2016-07-19 15:07:34 like vte (gtk2) and vte3 (gtk3) 2016-07-19 15:07:46 i think we can handle the python stuff similar 2016-07-19 15:09:03 if a python app only depends on py-somemodule and expect py-somemodule pull in python, then the python app needs be fixed, not py-somemodule 2016-07-19 15:09:11 thats my take on it 2016-07-19 15:09:20 jirutka: are you ok with that? 2016-07-19 15:10:18 or more, can you live with it? 2016-07-19 15:11:22 ncopa: well, if we provide py3 variant for all the python modules that support python3, so python2 will be needed just for legacy stuff, then I think that it’s okay; otherwise user may be often forced to have both python2 and python3 installed, that’s IMO not okay 2016-07-19 15:12:15 understand 2016-07-19 15:12:34 i also think that having both gtk2 and gtk3 installed is not ok 2016-07-19 15:12:43 but there is no way around it 2016-07-19 15:13:09 i dont know how many apps is python2 only 2016-07-19 15:13:25 but i suspect there will be some that will never upgrade to python3 2016-07-19 15:15:26 ncopa: I think that I should make my position more clear; this is not problem for _me_, I see it as a problem for ordinary Alpine users :) 2016-07-19 15:15:56 right 2016-07-19 15:20:29 ncopa: Python 3 is here for 8 years and still, there are a lot of modules that don’t support it, Python community is extremely conservative :( so we can’t drop python2 in a short term 2016-07-19 15:21:10 thats what i feared 2016-07-19 15:21:17 ncopa: me too 2016-07-19 15:21:43 so we want make maintenance easy 2016-07-19 15:22:03 that is, ship both python variants from a single apkbuild 2016-07-19 15:28:52 ncopa: however, it’s a fact that Python 3 is a feature, so I think that if we decide to provide py3 subpackage for all the python package that supports it, use py3-* in dependencies (if the module supports python3) and just say that we consider python3 as default and python2 is here just for legacy stuff, that it should be acceptable for users; I’m just afraid of situation where too many users will need both python versions (b/c we 2016-07-19 15:28:52 don’t update our packages) or the current state, where there are py-* in dependencies, so if user don’t have python[23] installed, it will not be pulled as dependency and (s)he will end up with broken application 2016-07-19 15:29:47 then i'd consider that a bug 2016-07-19 15:29:55 actually 2016-07-19 15:30:38 when migrating a py-module, it might be an idea to grep the aports tree for potensial breakages 2016-07-19 16:08:22 why do we have py2-* and py3-* subpackages now? Wouldn't it be better to only add py3-* subpackages and make py-* subpackages contain the python2 files? My system now pulls in python3 by default even though I don't use any software which requires python3 2016-07-19 16:09:04 for instance ansible depends on py-paramiko but now the dependency has to be updated to py2-paramakio is it really worth it to rename all those dependencies? 2016-07-19 16:12:21 ncopa: When designing the apk package format, have you considered using a different compression algorithms? I know gzip is still the de facto standard but there are plenty of compressors available outperforming gzip in (almost) all aspects. 2016-07-19 16:12:49 fabled: btw: youtube-dl does also seem to be affected by https://github.com/pypa/setuptools/issues/659 the youtube-dl binary is no longer installed to /usr/bin, however, sadly your patch doesn't fix that 2016-07-19 16:14:09 maybe it would be a good idea to revert py-setuptools to 20.8.0? 2016-07-19 16:14:25 I've been playing around with a couple of alternatives and I think replacing gzip as the default is definitely worth it. 2016-07-19 16:17:27 I'm still working on a reliable testing script that properly recompresses .apk files without messing with it's metadata and/or content structure, but so far there has been no reason for me to stick with gzip. 2016-07-19 16:20:00 kl3: you might want to take a look at #4984 2016-07-19 16:21:36 Hello, are there any cross-compiling example packages that take source from git and on a x86 system compile the alpine package for armhf? 2016-07-19 16:32:31 skazz, we currently native compile things; cross-compile is supported only to the extent of bootstrapping native compiler. we are working on improving the situation. 2016-07-19 16:33:33 kl3, you cannot currently recompress .apk binaries properly using standard tools. we are planning on fixing that too. 2016-07-19 16:34:07 kl3, the thing is that the .apk is currently concatenation of three .gz streams, and those need to be separate gz blocks. 2016-07-19 16:34:08 fabled: Oh, so all the armhf packages are compiled on a armhf device too then? or you saying the apkbuild has to include everything to setup the cross-compiling and perform it? 2016-07-19 16:34:21 what about stronger RSA/DSA/ECDSA signatures 2016-07-19 16:34:46 RSA is supported, and iirc it's bitlength agnostic. 2016-07-19 16:34:49 If the latter is true, any packages that come to mind that do it? I just want one to base off, all the ones I looked at so far tend to be just downloaded pre-compiled. 2016-07-19 16:34:50 ECDSA is on the list 2016-07-19 16:35:04 skazz, yes, armhf is native built on armhf device 2016-07-19 16:35:51 fabled: Oh ew, yeah, that is quite furstrating... must take hours even on an odroid ux4 (of which I've yet to boot alpine on) 2016-07-19 16:36:46 skazz, it's slower yes, but not insanely slow. 2016-07-19 16:36:57 some packages just cannot be cross-built 2016-07-19 16:37:21 several can. hopefully we get the building system flexible enough to do cross compile using fast box where possible. 2016-07-19 16:37:41 but autoconfigury is tricky to start, and horrible at times when cross-compiling. 2016-07-19 16:40:54 fabled: So when you guys build the current packages, are you using a raspberry pi, odroid, something else or a VM emulating armhf on x86? Any guide on setting it up? I guess its just the general one on the wiki... 2016-07-19 16:44:29 fabled: I know, I can already split .apk files into their gzip streams but filtering through abuild-tar is somewhat tricky. 2016-07-19 16:46:10 nmeum: Thanks, just added my 2 cents to that ticket. 2016-07-19 16:54:29 wireshark maintains all version/archives here, 2016-07-19 16:54:29 https://www.wireshark.org/download/src/all-versions/ 2016-07-19 16:54:29 this url should preferably used in APKBUILD 2016-07-19 17:07:35 kl3: we did evaluate different compress algos 2016-07-19 17:08:56 the reason why we landed on gzip was that it was good on general 2016-07-19 17:09:02 decompression speed 2016-07-19 17:09:08 compression ratio 2016-07-19 17:09:13 compression speed 2016-07-19 17:09:49 it was not best on any of those, but it was not bad on any either 2016-07-19 17:32:27 xz wasn't available yet 2016-07-19 17:32:30 lol 2016-07-19 17:44:14 <^7heo> ncopa: https://github.com/alpinelinux/aports/pull/118/files/0c6da3ceb2141e2e6c510429c5a3dbadba957385?short_path=04c6e90#diff-04c6e90faac2675aa89e2176d2eec7d8 2016-07-19 17:44:20 <^7heo> ncopa: would you agree with that? 2016-07-19 17:45:38 do we really need a README in the aports repository? 2016-07-19 17:46:21 nmeum: why not? 2016-07-19 17:46:23 I like xz -1 as a nice improvement over gzip -9. similar compression/decompression time, better compression ratio, acceptable decompression memory (~2M) 2016-07-19 17:49:39 IMHO there would be more value in README in abuild describing APKBUILD and upgraded as the code adds new features 2016-07-19 17:50:37 przemoc: this should be primary on https://wiki.alpinelinux.org/ 2016-07-19 17:50:52 when you keep doc in separate place (like wiki) it's sentenced to be stale 2016-07-19 17:51:12 przemoc: that’s true, but this is a repository of abuilds… 2016-07-19 17:51:21 przemoc: I don’t think that we should move all the documentation here ;) 2016-07-19 17:51:33 I'm talking only about APKBUILD documentation 2016-07-19 17:51:47 przemoc: however, there should be some starting point for contributors, at least with links to right places 2016-07-19 17:52:12 I'm not saying there shouldn't be some package creation guide (there is) 2016-07-19 17:52:17 przemoc: then maybe it should be in https://github.com/alpinelinux/abuild ;) 2016-07-19 17:52:30 yeah, documentation about APKBUILDs belongs into abuild man pages imho 2016-07-19 17:52:35 sadly abuild doesn't have any man pages currently 2016-07-19 17:52:35 przemoc: because there are only abuilds in aports, not abuild software 2016-07-19 17:52:45 just that complete APKBUILD reference should live there, where tool working on it lives 2016-07-19 17:53:14 and that is abuild repo 2016-07-19 17:54:02 przemoc: yes, abuild repo, no aports repo; but the point of the README we’re discussing now is to help contributions to aports, not abuild 2016-07-19 17:54:04 cgit has nice feature that README is shown in about tab, so it would be easy to point to that 2016-07-19 17:57:32 BTW one pet peeve of mine is READMe with .md extension that GitHub popularized. I know it's to mark it as markdown file, but README used to be written in markdown-like formatting for ages. I still prefer simple README, even if it has markdown formatting. 2016-07-19 17:58:08 przemoc: GH does not render README (without .md), it just shows it in plain text 2016-07-19 17:58:14 exactly 2016-07-19 17:58:25 that's why I written they popularized this ill-formed name 2016-07-19 17:58:26 przemoc: also Markdown is not the only supported format on GitHub, it also supports AsciiDoc and some others 2016-07-19 17:58:39 przemoc: why ill-formed? 2016-07-19 17:59:05 it could be easily set up in project settings, whether README should be rendered as something or not 2016-07-19 17:59:08 przemoc: how you can detect without any filename extension or other metedata what the heck is that? 2016-07-19 17:59:26 przemoc: isn’t that more complicated than simple file extension? 2016-07-19 18:00:46 unless your project make circus in README putting lot of badges and other graphics, even not rendered README is perfectly readable 2016-07-19 18:00:46 przemoc: however, this is imho bikeshedding, we should rather discuss _content_ of the file, not how it should be named etc. 2016-07-19 18:01:20 sure, I just wrote that I dislike what GH promoted regarding README naming 2016-07-19 18:01:59 przemoc: they did not, filename extensions are more older than GitHub 2016-07-19 18:03:16 people started naming README with .md just because it could be rendered with markdown. long time ago there was request to allow define whether README should be treated as some markdown, etc., but it was rejected 2016-07-19 18:03:30 rendered with markdown within GitHub 2016-07-19 18:03:39 przemoc: why Markdown and not some other? 2016-07-19 18:03:47 przemoc: why should they do such decision? 2016-07-19 18:04:17 przemoc: it should be your decision, so you must provide some metadata, filename extension is the most simple, easy and widely used solution 2016-07-19 18:05:33 przemoc: there are also people how don’t want to have their README rendered… what about them? and what if you have README, but don’t use Markdown inside it? 2016-07-19 18:05:56 the point is it should be configurable 2016-07-19 18:06:02 przemoc: how? 2016-07-19 18:07:12 in repo settings 2016-07-19 18:07:19 przemoc: in GUI? 2016-07-19 18:07:50 przemoc: this would bring much higher complexity 2016-07-19 18:07:54 why markdown? well, markdown followed natural formatting in many aspects, that's why it became popular. in GitHub era, people started simply renaming README to README.md for the sake of rendering in GitHub. 2016-07-19 18:08:24 przemoc: and it would work just in GitHub, not for users’ text editors etc. and why? it doesn’t bring any benefit 2016-07-19 18:08:47 przemoc: not every “natural formatting” is a valid Markdown… 2016-07-19 18:09:27 ok, no point in dwelling on it any further. let's agree to disagree on the preserving legacy of calling README file simply README 2016-07-19 18:10:25 ^7heo: i will check that later. other issue at hand now 2016-07-19 18:10:31 przemoc: please think about it, you’re just arguing for complexity with no real reason ;) 2016-07-19 18:10:41 przemoc: and pardon me, I must do some work now 2016-07-19 18:10:56 przemoc: * for more complexity 2016-07-19 18:10:57 what's the correct way to package a python software nowadays? Does it have to be split into two subpackages py2-$pkgname and py3-$pkgname? 2016-07-19 18:11:27 nmeum: yes, look e.g. at https://github.com/alpinelinux/aports/blob/master/testing/py-setproctitle/APKBUILD for example 2016-07-19 18:11:50 nmeum: but we still don’t know what to do in case when python module also installs some files into e.g. /usr/bin 2016-07-19 18:12:41 but that implies that we have to update alot of APKBUILDs since most of them depend on py-$pkgname which doesn't contain any files then, right? 2016-07-19 18:13:07 nmeum: well, basically, yeah, but it would partially work even know 2016-07-19 18:13:47 but wouldn't it be a better solution to simply add py3-$pkgname subpackages and keep the old py-$pkgname subpackages intact? 2016-07-19 18:13:51 nmeum: if you already have python2 or python3 installed, then when you apk add py-foo, then it will automatically install py2-foo or py3-foo 2016-07-19 18:14:07 nmeum: if you don’t have any python installed, then you have a problem… that what we have discussed today 2016-07-19 18:14:32 I have python2 installed, I upgraded today and python3 was installed even though I don't have any software which needs it 2016-07-19 18:14:47 nmeum: hm, that’s weird, it should not do that 2016-07-19 18:15:05 that happend because py-paramiko strictly depends on py-crypto py-ecdsa py3-crypto py3-ecdsa 2016-07-19 18:15:09 which looks like a mistake to me 2016-07-19 18:15:17 currently we have opposite problem, that it doesn’t install python when it logically should, but not that it install python you don’t need 2016-07-19 18:15:28 aha, that’s the reason 2016-07-19 18:15:38 <^7heo> ncopa: thanks, and understood. 2016-07-19 18:15:47 well, in long term, we’re moving to python3 as default 2016-07-19 18:15:58 <^7heo> hopefully. 2016-07-19 18:16:00 jirutka: so the correct way currently would be to have an install_if rule in each python package? 2016-07-19 18:16:17 nmeum: actually, currently it’s a big mess, so hard to say… 2016-07-19 18:16:27 nmeum: yes, thats the idea 2016-07-19 18:16:30 and the current plan 2016-07-19 18:16:31 yeah, it seems to be a big mess indeed 2016-07-19 18:16:32 nmeum: but few packages has been already updated in this style 2016-07-19 18:17:07 nmeum: it will take some time before it settles and we solve all the bad consequences 2016-07-19 18:17:23 jirutka: could you name an example package which follows the „new correct style” so I can update the packages which prevent me from removing python3 again? ;) 2016-07-19 18:17:40 nmeum: already did, https://github.com/alpinelinux/aports/blob/master/testing/py-setproctitle/APKBUILD 2016-07-19 18:17:49 ah, didn't see that 2016-07-19 18:17:50 thanks 2016-07-19 18:18:20 nmeum: but once again, if the python module install something outside python directory, then there will be a problem of conflicting files 2016-07-19 18:19:02 nmeum: I should also note that moving these “common” files to py-foo is NOT a solution, not for scripts installed into /usr/bin, becase they have different shebang 2016-07-19 18:19:04 fabled: i thinks omething is broken with provides 2016-07-19 18:19:52 $ docker run --rm -it alpine:edge apk add -U gcc | tpaste 2016-07-19 18:19:52 http://tpaste.us/2kz6 2016-07-19 18:21:49 can be reproduced with apk add -U pkgconfig too 2016-07-19 18:22:02 $ docker run --rm -it alpine:edge apk add -U pkgconfig | tpaste 2016-07-19 18:22:02 http://tpaste.us/AOM8 2016-07-19 18:22:05 nmeum: btw when you declare a dependency on some python module, then use specific subpackage, e.g. py3-foo, not py-foo (or py2-foo if that package doesn’t support python3) 2016-07-19 18:22:36 sure 2016-07-19 18:23:16 nmeum: however, the current packages that uses py-foo should partially work (e.g. when you already have python2 or python3 installed), but it should not be used for new packages and we have to update the current ones 2016-07-19 18:24:55 nmeum: btw I don’t know if you already know about that, use https://files.pythonhosted.org for source, not pypi.python.org, like in https://github.com/alpinelinux/aports/commit/f9d9a8122ada529e8653fe21f122f079897d8c79, you can find more info in https://github.com/alpinelinux/aports/pull/147#issuecomment-230739905 2016-07-19 18:25:38 nmeum: (all existing packages are already updated to files.pythonhosted.org) 2016-07-19 18:26:09 yeah, I saw that commit 2016-07-19 18:26:26 great :) 2016-07-19 19:19:38 thinking of alt , http://www.phoronix.com/scan.php?page=news_item&px=Apple-Opens-LZFSE 2016-07-19 19:34:54 FSE is another Yann Collet's work (mostly known from LZ4), which is implementation of Duda's ASN concept 2016-07-19 21:17:28 is there any reasonable documentation for openrc services? 2016-07-19 21:41:12 openrc-doc? 2016-07-20 05:47:54 i'm looking at the py-setuptools issue, and i got a hunch now 2016-07-20 06:03:09 ok. i know what goes wrong, and can reproduce the py-setuptools bug now 2016-07-20 08:38:59 hi, i discovered tteras'bootstrap scripts :-) So i setup a new x86_64 buildserver and createcross-toolchain.sh worked flawlessly for aarch64, but crossbuild-alpine-bootstrap.sh fails early while building busybox... Any ideas? https://pastee.org/q2ce9 2016-07-20 08:39:41 hi guest-VcEFUS 2016-07-20 08:39:58 we are working on aarch64 as we speak. 2016-07-20 08:40:05 guest-VcEFUS, it worked for me... :) 2016-07-20 08:40:23 someone else mentioned the same on the mailing list (or perhaps it was you?) 2016-07-20 08:42:00 guest-VcEFUS, somehow it looks like abuild is not in cross-build mode 2016-07-20 08:42:05 is CBUILD set? 2016-07-20 08:42:19 it wasnt me :-( but it also happens with armv7 even with x86 :-) i just downloaded tteras'stuff and exec 2016-07-20 08:42:20 i think you need to set that by hand in /etc/abuild.conf 2016-07-20 08:42:35 it's probably something missing in /etc/abuild.conf 2016-07-20 08:43:01 we are also planning to support cross builds better in future 2016-07-20 08:43:17 as a builtin feature of the build system without requiring external scripts 2016-07-20 08:45:20 abuild.conf is pretty vanilla, https://pastee.org/3cbn9 2016-07-20 08:47:39 what to set in CBUILD? 2016-07-20 08:49:45 fabled: is http://dev.alpinelinux.org/~tteras/bootstrap/abuild-crossbuild-aarch64.conf not enough? 2016-07-20 08:59:01 set CBUILD=x86_64-alpine-linux-musl 2016-07-20 08:59:12 it should be the triplet for your build box 2016-07-20 08:59:16 CHOST defaults to it too 2016-07-20 09:20:01 CBUILD is set in /etc/abuild.conf and it was still failing..? but http://bit.ly/29XPCpP made my build go further ;-) 2016-07-20 09:21:33 ncopa: around? 2016-07-20 09:28:51 ah i already see the issue 2016-07-20 09:29:03 fabled: i think your cross support for util-linux is faulty 2016-07-20 09:31:46 fabled: makedepends should be defined after you verify bootstrap. 2016-07-20 09:37:39 but now binutils fail to build - where are the up2date scripts available? or can u paste the current crossbuild*sh somewhere? 2016-07-20 09:45:40 clandmeter: hi 2016-07-20 10:04:31 ncopa: hi, already solved. 2016-07-20 10:06:00 fabled: I got an error while upgrading py-markupsafe 'ERROR: Failed to create usr/lib/python2.7/site-packages/MarkupSafe-0.23-py2.7.egg-info/top_level.txt: Not a directory' any idea what might be causing that? 2016-07-20 10:06:29 (asking you because you rebuild the package) 2016-07-20 10:07:34 hm, removing and reinstalling the package fixed that…strange 2016-07-20 10:19:17 nmeum, oh, yes, it's result of the recent py-setuptools breakage 2016-07-20 10:19:28 it caused that directory to be a file 2016-07-20 10:19:44 messed up lot of things 2016-07-20 10:19:53 ahhhh, that makes sense 2016-07-20 10:20:07 guest-VcEFUS, the diff you sent is wrong approach 2016-07-20 10:20:24 abuild will install the dependencies properly when it detects cross build mode; somehow it's not 2016-07-20 10:26:20 fabled: but im not the guy who created the diff/patch ;-) but i will reset the env and retry... 2016-07-20 10:32:44 ncopa: did you see my patches for refactoring the abuild snapshot function on the alpine-devel ML? 2016-07-20 10:33:56 nmeum: not yet 2016-07-20 10:41:19 clandmeter: a feature request for patchwork 2016-07-20 10:41:48 it is not possible to see on the page what patchwork id the patch has when using safari 2016-07-20 10:42:33 so you cannot just look at webpage and know the id for `pwclient git-am $id` 2016-07-20 10:43:05 http://imgur.com/a/v4sjO 2016-07-20 10:44:24 maybe fix safari? 2016-07-20 10:45:10 i guess if you select the address bar it will show the full uri? 2016-07-20 10:45:21 yes 2016-07-20 10:45:37 other then that, we can only create a issue at pw project. 2016-07-20 10:45:44 ok 2016-07-20 10:45:53 i dont have any experiance with python 2016-07-20 10:46:03 im already happy i could make it work. 2016-07-20 10:46:13 it sounds simple to fix 2016-07-20 10:46:17 :) 2016-07-20 10:46:20 i'm happy too 2016-07-20 10:46:58 it does, but it sounds easier to ask upstream 2016-07-20 10:47:15 yes, it should be done upstream 2016-07-20 10:47:24 and i dont like to patch it and support it 2016-07-20 10:47:33 +1 2016-07-20 10:48:37 ncopa: was it available before the ui changes? 2016-07-20 10:53:19 ncopa: https://github.com/getpatchwork/patchwork/issues/48 2016-07-20 10:54:17 dunno 2016-07-20 10:57:37 thanks! 2016-07-20 11:08:31 fabled: some progress in here: https://pastee.org/5jmqg - any ideas whats wrong with mpfr3 ? 2016-07-20 11:10:17 guest-VcEFUS, please don't use the patched scripts. the patches are doing wrong things. you might make progress but end up in bigger problems. 2016-07-20 11:18:45 fabled: switched to back to plain ~tteras-scripts and rebuilding... thanx 2016-07-20 11:19:11 just make sure CBUILD is set in abuild.conf 2016-07-20 11:19:53 i recently updated the script too... added few PKG_* entries in the .conf files 2016-07-20 11:25:16 fabled: since i run this inside docker and rebuilding the image allthetime this should be an issue... 2016-07-20 13:43:09 awesome, if i take golang:1.7-alpine to build a go based tool everything is fine, if i take an alpine:edge base image and install the go tools and build the same tool with the same commands it fails oO 2016-07-20 13:43:43 ...while cross compiling with gox. 2016-07-20 13:44:43 https://gist.github.com/tboerger/6bc6da62ec20643070c0bdede284b0d4 but that doesn;t happen with the official docker images where they compile go on their own. 2016-07-20 13:45:00 maybe https://github.com/docker-library/golang/blob/9f666dc2f4f51df564613f787d28b3a2353243e0/1.7/alpine/no-pic.patch and http://git.alpinelinux.org/cgit/aports/tree/community/go/default-buildmode-pie.patch are related to that? 2016-07-20 13:45:50 looks more like cross-compile related 2016-07-20 13:46:27 but why does it work with the selfcompiled go and not with the packaged go? 2016-07-20 13:47:18 you can try -buildmode pie on your selfcompiled go 2016-07-20 13:47:27 if that does not work, it's go bug that is triggered by pie mode 2016-07-20 13:51:19 yep, with -buildmode pie it also fails on the selfcompiled go from the official docker image. 2016-07-20 13:51:45 gcc is still building? 2016-07-20 13:52:05 build.a.o says armhf is still on llvm 2016-07-20 13:52:10 hardly possible, it should fail by now 2016-07-20 13:52:15 fabled: can you kick it? 2016-07-20 13:53:11 mosez, so it's upstream go bug triggered in pie mode 2016-07-20 13:53:19 barthalion, ? 2016-07-20 13:54:37 fabled: looks like that, yes 2016-07-20 13:54:42 fabled: are edge armhf builders all right? 2016-07-20 13:54:58 fabled: https://github.com/docker-library/golang/blob/9f666dc2f4f51df564613f787d28b3a2353243e0/1.7/alpine/no-pic.patch#L9 2016-07-20 13:55:00 building llvm 2016-07-20 13:55:26 fabled: should we also add this patch to the go package? 2016-07-20 13:55:31 fabled: http://build.alpinelinux.org/buildlogs/build-edge-armhf/main/llvm/llvm-3.8.1-r0.log 2016-07-20 13:55:44 barthalion, that's old, the log gets rsynced when it's done 2016-07-20 13:55:51 I see, thanks 2016-07-20 13:56:02 but i'm not sure if it built gcc 2016-07-20 13:56:07 so it'll probably fail 2016-07-20 13:56:47 mosez, the no-pic was a hack for another issue 2016-07-20 13:58:51 fabled: but does alpine set some other defaults? if i set the buildmode differently it builds. but that shouldn't be necessary... 2016-07-20 13:59:21 mosez, the only change we do is for buildmode to be pie 2016-07-20 13:59:34 by default 2016-07-20 13:59:42 that can be still overridden 2016-07-20 13:59:47 we want pie due to security reasons 2016-07-20 13:59:52 e.g. aslr works better then 2016-07-20 14:00:17 hum... and i have no idea why my code fails with pie :( 2016-07-20 14:01:48 fabled: finally after removing and rebuilding the docker image, it looks much better now, maybe some docker caching.foo was bugging me?! im currently here: https://pastee.org/decbw - any ideas? 2016-07-20 14:02:14 apk add gcc-gnat 2016-07-20 14:02:18 that's implicit dependency 2016-07-20 14:02:22 i should add it to the script 2016-07-20 14:04:35 fabled: gcc-gnat is installed on $host or inside the buildroot? 2016-07-20 14:04:52 on $host 2016-07-20 14:05:17 ada needs ada to build 2016-07-20 14:05:31 and depending on self in makedepends is not possible 2016-07-20 14:05:39 so all builders have implicit build-base 2016-07-20 14:05:41 oh 2016-07-20 14:05:48 we should add gcc-gnat to build-base 2016-07-20 14:06:24 gcc-gnat is already installed on $host? still the same error? 2016-07-20 14:07:29 hum 2016-07-20 14:09:15 guest-VcEFUS, so 'gnat' command works in the host? 2016-07-20 14:10:01 fabled: yap 2016-07-20 15:00:17 fabled: alpine:/srv$ gnat|head -1 2016-07-20 15:00:17 GNAT 6.1.0 2016-07-20 15:00:17 Any ideas? 2016-07-20 15:01:25 is gcc-gnat-aarch64-alpine-linux-musl also installed on host ? 2016-07-20 15:01:35 i suppose yes 2016-07-20 15:04:21 alpine:/srv$ sudo apk add gcc-gnat-aarch64-alpine-linux-musl gcc-gnat 2016-07-20 15:04:21 OK: 1231 MiB in 156 packages 2016-07-20 15:05:21 fabled: also added libgnat to script, but still the same :-( 2016-07-20 15:06:32 can you dump config.log ? 2016-07-20 15:15:11 fabled: hmm, strange - is not in aports/main/gcc after failed build? 2016-07-20 15:15:30 it should be somewhere in src/build.. 2016-07-20 15:15:36 try find -name config.log 2016-07-20 15:18:45 shame on me ^^ https://pastee.org/s8acd 2016-07-20 15:19:54 so it's some funky isl issue 2016-07-20 15:20:05 configure:6065: aarch64-alpine-linux-musl-gcc -o conftest --sysroot=/home/thohal/sysroot-aarch64-alpine-linux-musl/ -Os -fomit-frame-pointer -pipe -fPIC --sysroot=/home/thohal/sysroot-aarch64-alpine-linux-musl/ -L/home/thohal/sysroot-aarch64-alpine-linux-musl//lib -lisl -lmpc -lmpfr -lgmp conftest.c -lisl -lgmp >&5 2016-07-20 15:20:05 conftest.c:10:26: fatal error: isl/schedule.h: No such file or directory 2016-07-20 15:20:05 #include 2016-07-20 15:20:21 oh 2016-07-20 15:21:34 ok, the issue is 2016-07-20 15:21:34 acx_cv_cc_gcc_supports_ada=no 2016-07-20 15:21:36 dunno why 2016-07-20 15:25:48 fabled: i saw sth with "blabla isl 0.16/0.15 and 0.14" while 0.17 is installed? 2016-07-20 15:25:57 unrelated issue 2016-07-20 15:27:45 maybe should fi that thou 2016-07-20 15:27:55 should just downgrade to 0.16 2016-07-20 15:28:22 there's 0.17.1 too 2016-07-20 15:30:28 checking for isl 0.16, 0.15, or deprecated 0.14... yes 2016-07-20 15:30:28 checking for isl 0.16 or 0.15... yes 2016-07-20 15:32:19 fabled: u seem experienced with this issues, so what would you suggest :-) ? 2016-07-20 15:38:20 bah. isl-dev makedepend is missing 2016-07-20 15:38:41 but it should not cause the other issue 2016-07-20 15:41:02 im currently rm'ed the docker image again (for this strange caching-foo) and rebuilding with latest aka 0.17 again.. if it fails i would downgrade to 0.16? 2016-07-20 15:41:37 pushed fix 2016-07-20 15:42:16 oh 2016-07-20 15:46:06 fabled: what happened? git pull shows new gcc and isl 2016-07-20 15:49:11 fabled: isl is 0.17.1 now and i would give it a try or should i wait for sth else? 2016-07-20 15:51:32 wait, there's an issue still 2016-07-20 15:51:40 the isl dl patch isn't working as expected :/ 2016-07-20 15:51:46 maybe i'll just remove it 2016-07-20 15:52:39 fabled: testing before commiting improves quality ^^ SCNR 2016-07-20 15:52:45 :) 2016-07-20 16:58:05 fabled: was isl kicked from aports? 2016-07-20 16:59:58 no 2016-07-20 17:00:03 how so? 2016-07-20 17:01:05 fabled: after git pull isl is away? 2016-07-20 17:02:33 should not b 2016-07-20 17:14:40 fabled: hmm, maybe i should leave for a beer or 2... so rm'ed my env again, rm'ed and rerunning with current git.. i played around in the meanwhile - downgraded to isl-0.(14.1|16.1|17|17.1) in $host and 16.1/17/17.1 in APKBUILD and still failing... could you solve the isl-thang? 2016-07-20 17:14:56 isl is solved 2016-07-20 17:15:11 i also solved the other aarch64 bug we had in our abuild 2016-07-20 17:15:17 but the gnat issue you have sounds weird 2016-07-20 17:16:35 fabled: im on a clean new env... and retrying the whole damn thing again and will report soon ;-) 2016-07-20 17:17:05 i updated the bootstrap scripts 2016-07-20 17:17:10 minor changes only 2016-07-20 17:20:23 fabled: thanx for the hint - next build is scheduled with your pimped script.. any many thanx for all your efforts and patience! :-D 2016-07-21 11:10:59 any guide if non-free/intel-ucode is needed, or it updated in bios ? 2016-07-21 11:11:32 newer version are available, https://downloadmirror.intel.com/26156/eng/micr 2016-07-21 11:11:35 ocode-20160714.tgz 2016-07-21 11:13:07 it say for file to be in, /etc/firmware 2016-07-21 11:26:55 vkris: might be you need put it in /lib/firmware 2016-07-21 11:38:34 would it be good idea, if before release of versioned iso a `abuild fetch` is run over non-free/ so it get cached in distfiles ? 2016-07-21 11:41:57 or they would come under category of being "re-distributed", not allowed 2016-07-21 11:46:11 vkris: That heavily depends on your system. Some machines, that is to say it's mainboard's boot firmware, already apply microcode updates before loading the BIOS/(U)EFI. 2016-07-21 11:47:22 Loading microcode through the kernel at boot time is just an alternative, so check out your vendor's firmware for upates. 2016-07-21 11:49:42 ah, ok thanks 2016-07-21 12:44:36 hello 2016-07-21 12:44:44 fabled: anything to test? 2016-07-21 12:45:08 hrw, we've been wanting to make a native build. but gcc bootstrap fails. any ideas? 2016-07-21 12:45:24 fabled: point me to logs? 2016-07-21 12:45:43 http://tpaste.us/GVMe is the failure. self-check fails. 2016-07-21 12:46:23 i also filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71951 but i'm not sure if this is related or separate issue 2016-07-21 12:46:53 long time since I had to bootstrap 2016-07-21 12:47:23 clandmeter also tried latest gcc-6-stable snapshot but it failed native build too 2016-07-21 12:47:30 not sure if there's someproblem in the cross compiler 2016-07-21 13:44:00 <^7heo> would someone care to do an example with alpine? 2016-07-21 13:44:01 <^7heo> http://stackoverflow.com/documentation/linux/379/compiling-the-linux-kernel#t=201607211343319023859 2016-07-21 13:44:08 <^7heo> that would be ace. 2016-07-21 13:51:12 can testing/autossh moved to unmaintained/ pls, upstream not available, and current version not in distfiles 2016-07-21 16:56:07 hey friends 2016-07-21 16:56:10 how is everyone? 2016-07-21 16:59:29 hot 2016-07-21 17:00:00 hehe, i can imagine 2016-07-21 18:22:27 leo-unglaub: fucking hot, to be more specific 2016-07-21 18:23:11 >10°C -- oh noes cold cold cold 2016-07-21 18:23:18 >20°C -- could be better 2016-07-21 18:23:29 >25-30°C fucking hot wanna die plox kill me 2016-07-21 18:23:31 :_: 2016-07-21 18:24:06 LOL 2016-07-21 19:02:15 even better, it automagically got build , http://nl.alpinelinux.org/alpine/edge/testing/x86_64/autossh-1.4e-r0.apk 2016-07-21 19:12:19 ah, the site accessible again (http://www.harding.motd.ca/autossh/) 2016-07-21 19:27:23 anyone knows how this dissapeared, http://git.alpinelinux.org/cgit/aports/tree/testing/at 2016-07-21 19:27:37 no trace in git logs 2016-07-21 19:28:49 ok its in community now 2016-07-21 19:31:37 and upstream src is missing, http://http.debian.net/debian/pool/main/a/at/ (3.1.18) 2016-07-21 19:37:01 so is distfiles, but build version is present in nl.a.o 2016-07-21 19:37:15 so in* 2016-07-21 19:38:26 did somebody outsource AL builders ! 2016-07-21 21:52:14 vkris: ports are like the wild west :-D 2016-07-21 22:17:08 vkris: outsource? why? 2016-07-21 22:42:34 I can understand upstream file not-available, but how does it dissapear from distfiles after its build 2016-07-21 22:43:20 vkris: uh, it definitely should not 2016-07-21 22:43:48 vkris: if you have some time, you can look at https://github.com/koji-project/koji, how to use it for building Alpine packages… ;) I have an opportunity to use some ARM cluster for building Alpine packages, but only with koji (the currently use it for Fedora packages) 2016-07-21 23:24:05 jirutka: an (unofficial)alpine-buildsystem is on the way.. and its sexier thanx koji (=_=) 2016-07-21 23:24:48 guest-VcEFUS_: koji is just a way to free ARM cluster ;) 2016-07-21 23:25:21 guest-VcEFUS_: I’m not suggesting to run koji on Alpine machines, not at all :) 2016-07-21 23:25:27 qemu-$arch_static too :-D 2016-07-21 23:26:54 btw where’s repository of alpine-buildsystem? 2016-07-21 23:27:04 and our $koji-fork will be public and free 2016-07-21 23:29:00 is there any - looks more like ' while true, do find | xargs | abuild -R... :-) 2016-07-21 23:29:42 how is that sexier than koji? 2016-07-21 23:33:48 provides more $bling :-D 2016-07-21 23:35:05 ? 2016-07-21 23:36:40 wait and gimma 1-2 days for polishing... and alpine itself provides abuild/buildlab... http://git.alpinelinux.org/cgit/abuild/tree/buildlab.in 2016-07-21 23:37:59 that’s basically my script for Travis and private repo… 2016-07-21 23:38:21 how does it solve queue, distribution to multiple building machines etc? 2016-07-21 23:40:08 that's what im working on... jenkins+docker+qemu... 2016-07-21 23:40:25 uh, jenkins… 2016-07-21 23:41:08 jenkins was already there for my debian-stuff, so... 2016-07-21 23:41:36 its just a wrapper around exchangable :-D 2016-07-21 23:41:42 I also have one instance of Jenkins, but I totally hate it and replace it with GitLab CI very soon 2016-07-21 23:41:56 it’s imho totally unnecessary for this use case 2016-07-21 23:42:06 uh, ruby :-D 2016-07-21 23:42:39 and? however, GitLab CI would be even bigger overkill for Alpine 2016-07-21 23:44:23 what about drone? 2016-07-21 23:44:31 Go = no go 2016-07-21 23:45:20 to be honest, I currently don’t know about simple lightweight CI (or just task scheduler) suitable for this particular use case… I’m just quite sure that Jenkins is not the best option 2016-07-22 00:04:45 jirutka: finishing with jenkins first, so u and $world can have a look into.. 2016-07-22 02:25:31 hi, is there a process to move package from testing to comunity or main? 2016-07-22 03:45:22 is there any policy, maintainer guide whatever something for the eyes available? 2016-07-22 03:55:52 guest-VcEFUS, the only https://wiki.alpinelinux.org/wiki/Package_Maintainers 2016-07-22 04:01:21 jirutka: ok, jenkins is already stripped out and $magic is in $bash &$ dockerfile... 2016-07-22 04:01:27 thanx 2016-07-22 08:37:14 fabled, i've this struct: 2016-07-22 08:37:15 typedef struct udpipMessage 2016-07-22 08:37:15 { 2016-07-22 08:37:15 struct packed_ether_header ethhdr; 2016-07-22 08:37:15 char udpipmsg[IPPACKET_SIZE]; 2016-07-22 08:37:15 char pad_for_tokenring_header[sizeof(struct trh_hdr) + sizeof(struct trllc)]; 2016-07-22 08:37:19 } __attribute__((packed)) udpipMessage; 2016-07-22 08:37:41 but when i compile this .h 2016-07-22 08:37:44 i got: 2016-07-22 08:37:45 In file included from arp.c:28:0: 2016-07-22 08:37:45 ../include/client.h:193:40: error: invalid application of 'sizeof' to incomplete type 'struct trh_hdr' 2016-07-22 08:37:45 char pad_for_tokenring_header[sizeof(struct trh_hdr) + sizeof(struct trllc)]; 2016-07-22 08:37:45 ^~~~~~ 2016-07-22 08:37:46 ../include/client.h:193:65: error: invalid application of 'sizeof' to incomplete type 'struct trllc' 2016-07-22 08:37:50 char pad_for_tokenring_header[sizeof(struct trh_hdr) + sizeof(struct trllc)]; 2016-07-22 08:38:13 it's missing #include for the file which is expected to supply trh_hdr 2016-07-22 08:38:42 uhm 2016-07-22 08:38:51 i think i'm missing linux-headers 2016-07-22 08:38:56 likely yes 2016-07-22 08:39:30 it's a cryptic error 2016-07-22 08:40:11 fabled: i think we need gcc-6.1.1 2016-07-22 08:40:20 ncopa, ? 2016-07-22 08:40:27 i just pushed it a moment a go 2016-07-22 08:40:30 i getting this error when buliding u-boot: http://lists.denx.de/pipermail/u-boot/2016-July/259876.html 2016-07-22 08:40:34 yes 2016-07-22 08:40:34 oh! 2016-07-22 08:40:37 ha! 2016-07-22 08:40:40 great! 2016-07-22 08:40:42 it's building on edge armhf :) 2016-07-22 08:40:49 thats why it was slow :) 2016-07-22 08:40:58 wonderful :) 2016-07-22 08:44:36 fcolista, looks like that's supposed to come from netinet/if_tr.h 2016-07-22 08:44:49 token ring stuff 2016-07-22 08:44:54 i think musl does not ship it 2016-07-22 08:45:14 gentoo provides a patch for that: 2016-07-22 08:45:16 #sed -i "s%%%" include/client.h 2016-07-22 08:45:16 #sed -i "s%%%" include/client.h 2016-07-22 08:45:23 but still won't work without it 2016-07-22 08:45:34 i think it's old stuff 2016-07-22 08:45:35 yes 2016-07-22 08:45:44 seems linux-headers no longer ships it either 2016-07-22 08:45:48 right 2016-07-22 08:45:54 so it's changing to use glibc version 2016-07-22 08:46:00 but musl does not ship it 2016-07-22 08:46:10 probably just better to disable it if possible 2016-07-22 08:46:38 how? 2016-07-22 08:46:46 dunno 2016-07-22 08:46:49 k 2016-07-22 08:46:50 :) 2016-07-22 08:54:04 i think we have most issues fixed for 3.4.2 release 2016-07-22 08:54:18 i think i should just tag it before we get more incoming issues 2016-07-22 11:52:17 are there anything we are missing for the 3.4.2 release? 2016-07-22 11:52:26 otherwise i'm tagging new release 2016-07-22 12:00:01 ncopa: when is 3.5 due? im too lazy to search. 2016-07-22 12:38:59 i'm working on as first step to migrate the scripts better with abuild... moving more of the common parts to abuild, and making the cross bootstrap scripts simpler 2016-07-22 12:40:27 the only problem is 2016-07-22 12:40:45 abuild needs to know each subpkgs arch on global space; previously it was enough to know it only inside the split function 2016-07-22 12:41:00 clandmeter: 1 nov 2016 2016-07-22 12:42:55 grazie mille 2016-07-22 12:51:32 <^7heo> ncopa: did you get the time to look at my patch? 2016-07-22 12:52:30 which of them? 2016-07-22 12:52:37 the nlplug-findfs? or readme 2016-07-22 12:54:13 <^7heo> former. 2016-07-22 12:56:46 i looked at it 2016-07-22 12:56:48 and it builds 2016-07-22 12:56:55 but i have not had time to test that it actually works 2016-07-22 12:56:56 sorry 2016-07-22 12:57:07 <^7heo> ok 2016-07-22 12:57:27 <^7heo> and about nlplug-findfs 2016-07-22 12:58:04 <^7heo> the version I have on my computer is warning me: File descriptor 6 (/dev/random) leaked on lvm invocation. Parent PID 682: nlplug-findfs 2016-07-22 12:58:12 <^7heo> and File descriptor 8 (/dev/urandom) leaked on lvm invocation. Parent PID 682: nlplug-findfs 2016-07-22 13:00:24 hum 2016-07-22 13:00:33 maybe we need close libcryptsetup 2016-07-22 13:03:35 someone isn't using close-on-exec on their fds 2016-07-22 13:03:45 bad, bad programmer! no cookie! 2016-07-22 13:18:05 <^7heo> :P 2016-07-22 18:27:56 skarnet: dont get me started on bad programmers ... i am up now for two days fixing bad code written by someone else 2016-07-22 18:28:04 and i am on aggrrrooo level over 9000 2016-07-22 18:32:10 <^7heo> leo-unglaub: and still didn't answer my email. I hope I didn't offend you. 2016-07-22 18:32:30 <^7heo> (maybe not the best timing to bump you about that, I agree) 2016-07-22 18:32:47 ? 2016-07-22 18:32:50 what email? 2016-07-22 18:33:52 <^7heo> I sent you an email ages ago about meeting in Bln should you ever come. 2016-07-22 18:34:00 <^7heo> not sure if it was on here or suckless. 2016-07-22 18:34:06 <^7heo> but nevermind. 2016-07-22 18:34:13 <^7heo> I just wanted to drink a beer with a fellow dev' 2016-07-22 18:34:26 ah, i remember ... there was something yes .. 2016-07-22 18:34:40 <^7heo> ;) 2016-07-22 18:34:43 i think it was in my failed attempt to get a ~/bin by default 2016-07-22 18:34:48 <^7heo> yes that. 2016-07-22 18:34:55 <^7heo> Your memory isn't corrupt. 2016-07-22 18:35:02 as much as i would love an alpine linux meering .. i was the last time around 10 years ago in berlin 2016-07-22 18:35:07 so i am not that frequent there 2016-07-22 18:35:10 <^7heo> ok 2016-07-22 18:35:17 <^7heo> Well, should you come again, drop me a mail/line. 2016-07-22 18:35:24 <^7heo> (mail works best if I don't answer here tho) 2016-07-22 18:36:40 hey everybody :) was wondering what it might take to get kernel 4.5.x series running on ARM, as that has support for the vivante gfx in my cubox. It's been a long time since I built a kernel from source... figure things may have changed since the 1.2.x releases... 2016-07-22 18:40:03 damm, smuxi freezed and no 2016-07-22 18:40:53 sry all my chatlogs r gone now :-( which irc-client are u folks using? 2016-07-22 18:42:40 guest-VcEFUS: public logs http://www.irclogger.com/.alpine-devel/2016-07-22 2016-07-22 18:42:57 guest-VcEFUS: I’m using Textual 2016-07-22 18:46:23 leo-unglaub: the bad programmers. The terrible, terrible programmers. Ewwwww, the ugly, nonworking code. SO, SO BAD. And you have to deal with that code! The horror. Also, I'm on vacation, I hope you're happy for me! 2016-07-22 18:46:44 ACTION sometimes is a horrible person. 2016-07-22 18:47:09 <^7heo> moin jirutka 2016-07-22 18:47:22 ^7heo: hi 2016-07-22 18:52:01 skarnet: I am afraid your holidays will end some someday :< 2016-07-22 19:04:40 scadu: it will, but not before 3 weeks, so you're not going to ruin my mood today! 2016-07-22 19:04:42 jirutka: hmm, but my desktop is powered by al - any gui recommandations? 2016-07-22 19:05:21 guest-VcEFUS: I dunno 2016-07-22 19:06:44 guest-VcEFUS: weechat or hexchat if GUI is needed 2016-07-22 19:06:58 skarnet: have a nice time then. 2016-07-22 19:07:03 jirutka: https://www.codeux.com/textual runs on al? 2016-07-22 19:07:37 guest-VcEFUS: as you see on the web page, it does not; I use al on servers, not on desktop 2016-07-22 19:10:05 jirutka: but devs and pkg-maintainer should feel the pain - shame on u ;-D 2016-07-22 19:10:40 guest-VcEFUS: I think that I already feel enough of pain… :/ 2016-07-22 19:10:48 jirutka: just testdrive grsec on desktop and your in love :D 2016-07-22 19:11:07 guest-VcEFUS: hm, what problems do you have with grsec? 2016-07-22 19:11:36 jirutka: why? :c 2016-07-22 19:11:58 scadu: what why? 2016-07-22 19:12:30 jirutka: >I already feel enough of pain 2016-07-22 19:12:52 scadu: I was just kidding ;) 2016-07-22 19:17:20 scadu: okay, not in the first moment… you know, it’s quite a pain to maintain some of the packages, those for horribly written software or just very complicated (for example everything that involves llvm…) 2016-07-22 19:18:36 jirutka: oh well. I'm on afternoon shift now, so we can cry together :f 2016-07-22 19:18:49 scadu: XD 2016-07-22 19:19:10 friday + afternoon shift is a great combo, isn't it? 2016-07-22 19:20:27 how about night shift in the week-ends 2016-07-22 19:21:53 skarnet: sysadmin? :f 2016-07-22 19:22:50 that happened to me a few times ^^ 2016-07-22 19:23:49 jirutka: no probs, just some hickups... ff/chrome/vivaldi vs pax-flags, docker vs grsec, which needed some sysctl.. fglrx was pain in the ass and trying amdgpu now... 2016-07-22 19:23:50 (last time I had oncall duties was 2 years ago and we had no night shifts, so that was a blessing.) 2016-07-22 19:24:36 fglrx is the sound you make when you have a pain in the ass 2016-07-22 19:24:40 jirutka: but it's my 3rd day with al and im pretty happy, what already works 2016-07-22 19:24:54 skarnet: where do you work now? :> 2016-07-22 19:26:24 guest-VcEFUS: have you installed FF from Alpine package? it should be correctly PaXed… 2016-07-22 19:26:32 scadu: now? at home, self-employed, with a generally smart customer. Very much enjoying this. :) 2016-07-22 19:30:08 jirutka: al's vanilla ff worked.. 2016-07-22 19:30:32 skarnet: cool. so where did you work previously? if it is not a secret. 2016-07-22 19:30:57 it's not a secret, but we should -> #alpine-offtopic 2016-07-22 19:31:04 skarnet: jealous… 2016-07-23 10:07:52 how did alpine get the branding license from Mozilla to ship Firefox as Firefox? 2016-07-23 10:09:21 <^7heo> no idea, I guess we didn't? 2016-07-23 10:09:42 <^7heo> isn't it available to anyone? 2016-07-23 10:11:11 no. 2016-07-23 10:11:21 https://www.mozilla.org/en-US/about/partnerships/distribution/ 2016-07-23 10:11:46 it is ridiculously illegal to ship *any* patched Firefox, even if it is a functionality patch (i.e. to enable build on musl), without express written consent from the Mozilla Foundation 2016-07-23 10:11:50 this is why Debian ships iceweasel 2016-07-23 10:12:48 but your mozconfig /explicitly/ enables official branding (it defaults to off, giving you a globe icon without a fox and calling itself something like "Aurora") 2016-07-23 10:13:57 line 27 and 46-47 of http://git.alpinelinux.org/cgit/aports/tree/testing/firefox/mozconfig#n46 2016-07-23 10:16:23 having worn a moz hat back in the day, it surprised me that you got a license since it takes a lot of chatter with legal 2016-07-23 14:24:09 anyone experimenting with lxc 2.0.3?? 2016-07-23 15:38:00 if someone interested in issue with lxc ≥2.x: https://github.com/lxc/lxc/issues/1095 2016-07-24 11:44:16 jirutka: https://github.com/lxc/lxc/commit/f24a52d5f588ff4e4575046903fb9498c376d833#diff-785fb95a8e48a2c59b9b6552dd6b3abc 2016-07-24 11:45:38 guest-VcEFUS_: this is not the source of the problem, I’m using cgroup:mixed since lxc 1.0.5 2016-07-24 11:46:10 it’s related to cgfsng introduced in 2.x 2016-07-24 12:06:13 jirutka: hmm, so your /usr/share/lxc/templates/lxc-alpine always had "lxc.mount.auto=cgroup:mixed proc:mixed sys:mixed" ? 2016-07-24 12:06:23 yes 2016-07-24 12:06:39 read https://github.com/lxc/lxc/issues/1095, there are already reactions from lxc developers 2016-07-24 13:21:20 jirutka: i read it, but read: https://pastee.org/29tgf and this tasted like an old lxc-alpine.template while container creation?! 2016-07-24 13:21:24 sorry 2016-07-24 13:39:54 guest-VcEFUS_: ? 2016-07-24 14:06:17 jirutka: tried to reproduce #1095 and therefor setup a fresh system, installed (lxc|lxc-templates)-1.1.5-r6, created a new container lxc-115.. [OK] Then upgraded to 2 2016-07-24 14:07:15 guest-VcEFUS_: and? as I already wrote in the issue, the configuration is exactly the same, so there’s NOT a problem in configuration 2016-07-24 14:08:29 guest-VcEFUS_: I’m also author of the new lxc-alpine template used in LXC ≥2.x (and I’m using it since lxc 1.0.5), so I know pretty well what’s here ;) 2016-07-24 16:09:27 [BUG:setup-alpine vs GPT-Disks] I just re-installed an old freebsd-box with al and setup-alpine failed while initializing partitions. after manually setting the label to "msdos" s-a worked as expected. 2016-07-24 16:10:33 just for interest.. "mklabel msdos" via "parted" did the trick 2016-07-24 16:40:32 no rush but curious what action i need to take if any for the latest ghc port series i submitted to the mailing list 2016-07-24 16:48:24 hi 2016-07-24 18:47:13 mitchty: I'll take a look tomorrow 2016-07-24 18:47:42 mitchty: I wonder if llvm3.7 shouldn't have -dev separated as well 2016-07-24 18:52:37 mitchty: I guess you forgot to put default_dev in ghc's dev(), but I'll fix it on my own 2016-07-24 19:12:25 mitchty: any ideas how long will bootstrapping take? 2016-07-24 19:22:32 which bootstrapping? 2016-07-24 20:18:13 Hi everyone 2016-07-24 20:27:21 Has anyone tried doing a 'sys' install onto a USB stick that needs to boot of EFI? 2016-07-24 20:33:31 DodoFXP: you might want to catch ncopa in the CET working hours 2016-07-24 20:33:43 I think he does use it 2016-07-24 20:37:47 Is he responsive on twitter? 2016-07-24 20:40:05 should be 2016-07-25 08:28:43 the setup scripts does not yet support efi 2016-07-25 08:28:52 need to do that manually 2016-07-25 08:39:08 <^7heo> ncopa: did you find any time to test the nlplug-findfs patch? 2016-07-25 08:39:28 <^7heo> ncopa: also, should I try to patch the missing close-on-exec about the bug I reported? 2016-07-25 12:02:50 wow...pyopenssl jumps from 0.15 to 16.0 2016-07-25 12:05:14 ncopa: can i push? http://sprunge.us/VaiP 2016-07-25 13:26:25 ncopa: could you please look at https://github.com/alpinelinux/aports/pulls?q=is%3Aopen+is%3Apr+label%3Aready ? 2016-07-25 13:26:41 ncopa: and also https://github.com/ncopa/lua-optarg/pull/1 :P 2016-07-25 13:27:19 <^7heo> btw, why is that README not ready again? 2016-07-25 13:27:43 <^7heo> what was the issue you had, jirutka? 2016-07-25 13:28:33 ^7heo: capitalization 2016-07-25 13:28:51 <^7heo> ah, would you mind leaving a comment? :) 2016-07-25 13:29:01 ^7heo: yeah, sure, sorry 2016-07-25 13:29:04 <^7heo> awesome, thanks :) 2016-07-25 13:30:50 Pokémons in Prague online http://pokemap.cz/ :P one friend of mine just deployed it 2016-07-25 13:39:13 fcolista: push py-openssl 2016-07-25 13:40:20 ok thx ncopa 2016-07-25 13:42:15 ^7heo: where did you report that close-on-exec bug? 2016-07-25 13:42:22 <^7heo> here only. 2016-07-25 13:42:25 <^7heo> should I create a br? 2016-07-25 13:44:45 bpiotrowski, takes me about 5 hours to bootstrap arm and x86_64 on my skylake nuc with nvme ssd's 2016-07-25 13:45:24 doh, not here any longer 2016-07-25 13:50:33 ^7heo: things mentioned only here on irc will be forgotten 2016-07-25 13:51:31 <^7heo> ncopa: understood. 2016-07-25 14:38:11 out of curiosity, is there an apkbuild example that builds from git as well as non git in say community? 2016-07-25 14:38:56 <^7heo> mitchty: say what? 2016-07-25 14:39:30 an apkbuild that can build from upstream git master or whatever branch, but also stable releases 2016-07-25 14:40:55 <^7heo> okay, are you asking if 2016-07-25 14:41:08 <^7heo> abuild can build a package from an APKBUILD; regardless of the origin of that APKBUILD? 2016-07-25 14:41:33 not exactly, i'm asking if i need to maintain 2 apkbuilds one for git and one not 2016-07-25 14:42:39 <^7heo> where would the "not" be stored, in your scenario? 2016-07-25 14:43:48 aka package/apkbuild and package-git/apkbuild OR could you selectively enable a subpackage in package/apkbuild or is that not possible? if it is, is there an example already 2016-07-25 14:44:05 <^7heo> okay, git doesn't work with different directories for different versions. 2016-07-25 14:44:15 <^7heo> it REPLACES the content of directories from one version to another. 2016-07-25 14:44:23 <^7heo> as a result 2016-07-25 14:44:25 i'm well awarehow git works 2016-07-25 14:44:32 git isn't the problem here 2016-07-25 14:44:39 <^7heo> I really think it is. 2016-07-25 14:44:51 <^7heo> no offense, but, either I still dont' get your question; or you don't get git. 2016-07-25 14:45:12 <^7heo> the releases are git tags. 2016-07-25 14:45:19 <^7heo> so unless you rewrite the history 2016-07-25 14:45:24 <^7heo> you cannot change what has been released. 2016-07-25 14:45:35 i'm really not sure what you're talking about here to be honest 2016-07-25 14:45:41 i'm not asking to rewrite released history 2016-07-25 14:45:45 i have a package foo 2016-07-25 14:45:50 <^7heo> and rewriting the history that has been shared isn't considered a very good practice, to say the least. 2016-07-25 14:45:53 i want to have a package foo-git which is built from stable master 2016-07-25 14:46:01 i'm not talking about rewriting history 2016-07-25 14:46:03 <^7heo> what is stable master? 2016-07-25 14:46:08 for the package 2016-07-25 14:46:20 aka i have php right 2016-07-25 14:46:23 <^7heo> yeah. 2016-07-25 14:46:26 and php has a version control 2016-07-25 14:46:29 <^7heo> please take some concrete example. 2016-07-25 14:46:30 <^7heo> no. 2016-07-25 14:46:31 it has a stable head or master 2016-07-25 14:46:36 <^7heo> php doesn't have a version control afaik. 2016-07-25 14:46:44 ignore that fact 2016-07-25 14:46:49 fine ok pick python 2016-07-25 14:46:54 <^7heo> php USES a RCS to version the codebase of the PHP engine. 2016-07-25 14:46:59 <^7heo> maybe that's what you meant? 2016-07-25 14:47:06 python has a stable branch of development in some version control 2016-07-25 14:47:20 ignore git ignore mercurial, svn, cvs, sccs, rcs, fossil 2016-07-25 14:47:28 version control doesn't matter 2016-07-25 14:47:35 <^7heo> okay, so, for a given SOFTWARE (the package is what you build with abuild) 2016-07-25 14:47:42 i want to build python and python at its current state of development 2016-07-25 14:47:43 <^7heo> you have different RCS systems to be aware of, yes. 2016-07-25 14:47:52 <^7heo> yes. 2016-07-25 14:48:05 none of this has to do with branches in git, or how alpine uses git to release things 2016-07-25 14:48:18 <^7heo> mitchty: yeah, I just got that you were talking about the upstream projects 2016-07-25 14:48:22 <^7heo> not about the alpine packages. 2016-07-25 14:48:36 so if i don't get git then forget about my question 2016-07-25 14:48:38 <^7heo> tbh it would have helped a lot if you would have used 'project' instead of 'package' 2016-07-25 14:48:42 <^7heo> or software, whatever you prefer. 2016-07-25 14:48:44 <^7heo> just not 'package' 2016-07-25 14:48:59 <^7heo> mitchty: no need to get pissy. 2016-07-25 14:49:07 <^7heo> mitchty: I'm taking on my time to try to help you. 2016-07-25 14:49:26 <^7heo> mitchty: now that I understood part of the issue, it's pretty stupid to stop. 2016-07-25 14:49:48 ^7heo: no worries, i'll just maintain 2 apkbuilds 2016-07-25 14:50:10 <^7heo> how is that related, now? 2016-07-25 14:50:19 <^7heo> I thought we were talking about upstream versionning here... 2016-07-25 14:50:56 <^7heo> bbl 2016-07-25 14:51:00 building the upstream version requires a lot of changes, differing dependencies, subdependencies etc... so it probably doesn't make sense to put it in one apkbuild 2016-07-25 14:56:52 ncopa: plz plz https://github.com/alpinelinux/aports/pulls?q=is%3Aopen+is%3Apr+label%3Aready :) 2016-07-25 15:00:56 ok 2016-07-25 15:09:06 repos down? 2016-07-25 15:10:23 im getting: https://pastee.org/f7a45 2016-07-25 15:12:13 <^7heo> mitchty: we are putting all the required dependencies to build upstream in any APKBUILD. 2016-07-25 15:12:18 <^7heo> mitchty: why doesn't it make sense? 2016-07-25 15:13:00 <^7heo> guest-VcEFUS: can you ping the host? 2016-07-25 15:13:08 guest-VcEFUS: works for me 2016-07-25 15:14:29 lol - our dns went down :-( 2016-07-25 15:15:09 <^7heo> yeah, then it's understandable. 2016-07-25 15:19:10 ^7heo: example, the current master branch requires llvm3.8, but the existing 3.7, and most people wouldn't want to wait for the versioned release to build as well as the version off git 2016-07-25 15:19:44 takes me 10 hours to build the arm version of things, doubling that to 20 and rebuilding the stable release when i just want an updated git release doesn't make as much sense 2016-07-25 15:20:27 <^7heo> mitchty: which package is requiring llvm3.8? 2016-07-25 15:20:55 <^7heo> (now I start getting your issue) 2016-07-25 15:21:16 ^7heo: nothing yet released, but ghc 8.2 (git master) does, 8.0.1 requires llvm3.7 2016-07-25 15:21:57 <^7heo> mitchty: people using edge are using the git tip afaik. 2016-07-25 15:22:06 <^7heo> mitchty: so if you're using edge, you're f**ked. 2016-07-25 15:22:23 i've never used edge 2016-07-25 15:22:41 <^7heo> mitchty: I'm running it on my laptop 2016-07-25 15:22:47 <^7heo> but it's x86 so not broken. 2016-07-25 15:22:50 <^7heo> I mean 2016-07-25 15:22:53 <^7heo> x86_64 2016-07-25 15:23:00 <^7heo> (I should have said x64 but whatever) 2016-07-25 15:24:47 <^7heo> wait no it's not arch dependent 2016-07-25 15:24:50 <^7heo> I'm saying bs 2016-07-25 15:24:56 <^7heo> it's just that I don't use ghc. 2016-07-25 15:25:40 what is bs? 2016-07-25 15:25:42 <^7heo> mitchty: I don't find a ghc package. Where do you get it from? 2016-07-25 15:25:45 <^7heo> bs == bullshit 2016-07-25 15:25:47 that llvm ir changes between versions? 2016-07-25 15:25:53 i submitted the port 2016-07-25 15:25:56 <^7heo> oh. 2016-07-25 15:25:59 <^7heo> I see now. 2016-07-25 15:26:14 <^7heo> Well, it's *your* responsability to bump the llvm then. 2016-07-25 15:26:27 <^7heo> either to bump the maintainer or send a patch in. 2016-07-25 15:26:33 http://patchwork.alpinelinux.org/patch/2235/ 2016-07-25 15:26:46 http://patchwork.alpinelinux.org/patch/2236/ 2016-07-25 15:26:55 http://patchwork.alpinelinux.org/patch/2237/ 2016-07-25 15:27:03 http://patchwork.alpinelinux.org/patch/2238/ 2016-07-25 15:27:04 <^7heo> okay, one second. 2016-07-25 15:27:12 http://patchwork.alpinelinux.org/patch/2239/ 2016-07-25 15:27:19 <^7heo> I still don't understand what is the *problem* you are hitting. 2016-07-25 15:28:47 <^7heo> mitchty: if the problem you are hitting is that you don't have the packages accepted fast enough; it's the same for all of us. 2016-07-25 15:28:54 <^7heo> mitchty: we're few, it takes time. 2016-07-25 15:29:05 <^7heo> mitchty: if the problem you are hitting is different, please state so. 2016-07-25 15:29:31 ^7heo: i thought i had explained, it, and no i'm not complaining about the speed 2016-07-25 15:29:57 <^7heo> mitchty: you have explained, but I didn't understand where the problem is. 2016-07-25 15:30:18 <^7heo> you wrote a lot of stuff, I thought I had gotten it; but I apparently haven't. 2016-07-25 15:30:43 so for upstream git ghc, i'll create an llvm3.8 package (note 3.9 doesn't work, llvm ir changes between versions), so the git version of ghc requires llvm3.8, but not llvm3.7 2016-07-25 15:30:47 porting that isn't the issue 2016-07-25 15:30:52 its done already 2016-07-25 15:30:57 <^7heo> ok? 2016-07-25 15:31:36 i'll probably just build the git master and continue on with publishing it myself 2016-07-25 15:31:45 and only submit the stable releases 2016-07-25 15:32:08 <^7heo> well, we're only updating software when releases of upstream are made, yes. 2016-07-25 15:32:15 <^7heo> we're not using the git tips in edge 2016-07-25 15:32:21 <^7heo> just the latest versions. 2016-07-25 15:32:28 <^7heo> at least AFAIK. 2016-07-25 15:32:44 <^7heo> if you want source-based rolling release, you'd better use gentoo. 2016-07-25 15:33:36 i'm not, i'm trying to make sure i can catch problems with the upstream before a release hits 2016-07-25 15:33:42 i'll just keep doing what i'm doing 2016-07-25 15:34:01 <^7heo> oh, so you want more QA? 2016-07-25 15:34:14 actually we have few packages in testing that pulls the last version from git repo 2016-07-25 15:35:12 no, i need to keep track that things don't break in the port or if changes are needed, its not something that most people need but would be nice to have as a combined port that can produce apks of say ghc-git-version and ghc-version but not both 2016-07-25 15:35:27 but if you want to test the last unreleased versions, then it’s definitely better to build it yourself; either just locally or create your own repo, you can start from https://github.com/jirutka/aports#how-to-setup-your-own-repository 2016-07-25 15:36:00 so right now all i'm doing is just building stuff every few days and validating it runs 2016-07-25 15:36:30 and i setup a repo on my website because s3 is getting costly 2016-07-25 15:36:43 do you need/want to do it in longterm? then it would make sense to automate it 2016-07-25 15:37:03 jirutka: i've setup jenkins to do it 2016-07-25 15:37:17 <^7heo> mitchty: s3 is always f*ing expensive. 2016-07-25 15:37:22 :) 2016-07-25 15:37:29 #selfhosted forever! 2016-07-25 15:37:48 <^7heo> yeah but people like amazon-ftp 2016-07-25 15:37:52 <^7heo> for some reason 2016-07-25 15:38:13 amazon-ftp? what’s that? just plain FTP, but with Amazon brand and Amazon price? 2016-07-25 15:38:24 <^7heo> jirutka: well, isn't S3 exactly that? 2016-07-25 15:39:07 ^7heo: it wasn't too bad till a few months ago, i setup a docker image and think a lot more people are using the docker image I produce with ghc, its fine but getting to be more than my vps costs 2016-07-25 15:39:27 <^7heo> mitchty: for the bw only? 2016-07-25 15:39:29 I dunno, I’ve never used S3… I don’t need it, I have my home server with ~6 TiB disk array, few OpenVZ containers from our local community hosting and many servers at work… 2016-07-25 15:39:47 ^7heo: yeah 2016-07-25 15:39:51 <^7heo> mitchty: wow. 2016-07-25 15:40:00 <^7heo> mitchty: yeah but anyway, S3's expensive. 2016-07-25 15:40:10 <^7heo> mitchty: why don't you distribute your code via some other infra? 2016-07-25 15:40:10 why docker for this? 2016-07-25 15:40:27 <^7heo> like I dunno, gh, or something docker, etc. 2016-07-25 15:40:56 jirutka: i use it to generate static binaries https://github.com/mitchty/alpine-static-tmux/blob/master/Dockerfile#L75 2016-07-25 15:41:21 you really don’t need Docker to just generate static binaries 2016-07-25 15:41:29 even plain old chroot would be sufficient 2016-07-25 15:41:44 true but this is less effort 2016-07-25 15:41:59 <^7heo> I'm not sure how using a docker file is less effort than chroot. 2016-07-25 15:42:04 I don’t think that it’s a less effort, but well… 2016-07-25 15:42:05 <^7heo> but your packages, your stuff. 2016-07-25 15:42:32 its more i'm running nixos and chroots there aren't quite the same without work 2016-07-25 15:42:57 and it would be maybe nice to also provide built binaries for download on GitHub, using releases ;) 2016-07-25 15:43:08 <^7heo> yeah 2016-07-25 15:43:24 you can run it e.g. on Travis, CircleCI, SemaphoreCI or other and deploy binaries to GitHub 2016-07-25 15:44:18 i tried a few of those, the build time of ghc via llvm tends to mean i get timeouts and killed 2016-07-25 15:44:43 or they build on one core only which doesn't help 2016-07-25 16:33:59 mitchty: 7 hours of travel killed me, I'll take a look later… 2016-07-25 16:34:33 mitchty: did you see all my comments? what about separate -dev for llvm3.7? 2016-07-25 16:38:52 bpiotrowski: you’re working on llvm3.7? that would be useful for Julia package 2016-07-25 16:39:18 bpiotrowski: they (upstream) kinda don’t like that I’ve used llvm 3.8 2016-07-25 16:39:22 well, work is done by mitchy, it just needs 2-3 changes 2016-07-25 16:39:34 where is it? on ML? 2016-07-25 16:39:38 bpiotrowski: yep, so i think i killed the -dev package for that more due to time than anything 2016-07-25 16:39:47 jirutka: yeah, I'll push it today 2016-07-25 16:39:53 mitchty: I see; I'll fix it then 2016-07-25 16:39:58 bpiotrowski: could you send me a link plz? 2016-07-25 16:40:06 jirutka: ghc has same issue, it can be patched to work with 3.8 but its basically: good luck with that 2016-07-25 16:40:23 jirutka: http://patchwork.alpinelinux.org/patch/2235/ 2016-07-25 16:40:28 mitchty: julia does work with llvm 3.8, but they still don’t like it :/ 2016-07-25 16:40:52 jirutka: so that llvm port mostly works, but i've never tried to build anything against it 2016-07-25 16:40:59 for ghc i only need opt/llc really 2016-07-25 16:42:04 i built it so you can install it alongside system llvm 2016-07-25 16:42:12 its a bit of a hack though 2016-07-25 16:42:50 bpiotrowski: no rush on things no worries 2016-07-25 16:43:17 its going to take a long time to build the arm ghc though 2016-07-25 16:43:45 bpiotrowski: and to answer your time question, it takes me about 5ish hours to compile both arm+x86_64 cross compilers for the bootstrap package 2016-07-25 16:44:12 yeah, I saw that on irclogger 2016-07-25 16:44:22 perfect for the night then 2016-07-25 16:44:46 which involves building llvm with musl patches, cross compiler gcc, and then finally ghc which is a 3 stage compile process 2016-07-25 16:45:24 the docker images for that are... large, about 10 gig a piece, so i tend to nuke them after i get the tar.xz files 2016-07-25 16:47:02 and i basically consider all this to be "good enough for the first release" not perfect by any means 2016-07-25 16:47:21 but if anything egregious needs fixing let me know 2016-07-25 16:50:27 no, I took a look at it yesterday, didn't build anything yet 2016-07-25 16:50:39 looks good to me 2016-07-25 16:54:16 mitchty: please prefix local variables with keyword `local` 2016-07-25 16:54:36 like `_ffi_include_dir`, the leading underscore is unnecessary for `local` vars 2016-07-25 16:54:45 sigh, that's on me, jirutka 2016-07-25 16:54:58 there is no things I couldn't fix myself, really 2016-07-25 16:55:12 also `f` in package() should be declared as `local` 2016-07-25 16:55:29 I often write it inline like `local f; for f in …; do` 2016-07-25 16:56:27 it would be also nice to not hardcode 3.7 and use variable, so it can be easily ported to other versions 2016-07-25 16:57:09 like in https://github.com/alpinelinux/aports/blob/master/community/ruby2.2/APKBUILD for example, there it’s called `_suffix` 2016-07-25 16:58:47 the code for applying patches in `prepare()` is just copy&pasted default code or it’s modified? if it’s not, then you can just pust `default_prepare || return 1` here 2016-07-25 16:59:41 `_builddir` should be named `builddir`, this has been changed quite recently (it’s an abuild variable now) 2016-07-25 17:01:04 hm, but it’s kinda swapped here… default_prepare uses `builddir` to find sources being patches, so builddir should be `$srcdir"/"$pkgname_short-$pkgver.src` in this case 2016-07-25 17:03:22 for the llvm apk? thats mostly the same as the llvm apkbuild was when I copied it 2016-07-25 17:03:40 i had to use --ignore-whitespace for one of the patches 2016-07-25 17:04:14 jirutka: so if you're done, I have all of this fixed here… 2016-07-25 17:04:34 great! :) 2016-07-25 17:04:57 hm not done yet 2016-07-25 17:05:38 you should also add `|| return 1` after every command that may (and should not) fail, except the last one; unfortunatelly abuild doesn’t run `set -e` (yet) 2016-07-25 17:05:57 and this is also fixed, even without your review 2016-07-25 17:06:05 great :) 2016-07-25 17:07:11 bpiotrowski: huh, you’re barthalion? why you’ve changed your nick? 2016-07-25 17:08:03 because I run this client locally, and the other one runs on the server 2016-07-25 17:08:09 aha 2016-07-25 17:08:26 I don't feel need to track the backlog here unless I want to catch someone or build something 2016-07-25 17:09:43 interesting that it took just few message for me to recognize you even when you’ve changed your nick… ;) 2016-07-25 17:12:03 don't worry, you are also very hard to mistook you 2016-07-25 17:12:11 … 2016-07-25 17:14:38 <^7heo> u w0t m8? 2016-07-25 17:15:02 <^7heo> less subjects, more thinking. :P 2016-07-25 17:17:54 ^7heo: yawn 2016-07-25 17:19:47 <^7heo> bpiotrowski: congrats! That is syntaxically, gramatically and semantically correct! :) 2016-07-25 17:20:17 thank you for reminding me to put you on /ignore locally too 2016-07-25 17:20:42 <^7heo> anytime. 2016-07-25 17:21:34 bpiotrowski: this is imho ready to merge, it should just be squashed https://github.com/alpinelinux/aports/pull/170 2016-07-25 17:22:38 bpiotrowski: you must be fan at parties… he didn’t write anything offensive or something like that… 2016-07-25 17:22:49 yeah, this time 8) 2016-07-25 17:22:56 I don't care. 2016-07-25 17:23:37 I kept him on ignore list before, I'm not going to change this wherever I run IRC client. 2016-07-25 17:25:11 really nice approach to contributors… 2016-07-25 17:25:52 <^7heo> Meh I couldn't care less. 2016-07-25 17:26:02 <^7heo> Him ignoring me also means less noise for me. 2016-07-25 17:26:08 <^7heo> And less wasted time. 2016-07-25 17:26:12 <^7heo> So I'm all good with that. 2016-07-25 17:26:54 <^7heo> I think he is actually doing the only thing that might improve the situation: preventing himself from reacting inappropriately by being annoyed at what I writes. 2016-07-25 17:27:00 <^7heo> but that's a discussion for #alpine-offtopic 2016-07-25 17:27:14 <^7heo> s/writes/write/ 2016-07-25 17:28:47 don't worry about my approach, I simply give tit for tat 2016-07-25 17:29:10 I'm sure 7heo will enjoy me ignoring him as much as I do 2016-07-25 17:29:17 everyone's happy 2016-07-25 17:30:59 <^7heo> bpiotrowski: it's quite obvious that you didn't ignore me tho; you're not mature enough to say that without reading what I wrote above. 2016-07-25 17:31:09 <^7heo> And yes, I know how it sounds. I stand by what I juste wrote. 2016-07-25 17:31:44 <^7heo> (and at least, what I just wrote will prevent you from reacting further to what I'll write, which is good) 2016-07-25 17:31:52 <^7heo> (now you can go ahead and really ignore me) 2016-07-25 17:37:53 enjoying late hrs peek-a-boo 2016-07-25 17:38:24 <^7heo> indeed. Shouldn't we use #alpine-offtopic for that tho? 2016-07-25 18:14:43 ncopa, there's new libvirt version, 2.0.0. 2016-07-25 18:14:44 http://sprunge.us/hMNU 2016-07-25 18:15:10 checkapk: http://sprunge.us/gcLC 2016-07-25 18:15:23 no soname differences 2016-07-25 18:16:05 i've ready also py-libvirt with py2/3 subpackages split: http://sprunge.us/PNJd 2016-07-25 18:16:18 i wait for your green light, though 2016-07-25 18:17:27 libvirt-glib is still at 0.2.3, so it remains untouched. Since there's no soname difference, i would not bump pkgrel neither 2016-07-25 18:19:36 btw I wrote a guide how to install Qemu/KVM on Alpine at vpsFree.cz (community OpenVZ hosting) and use it with qemu-openrc, but it’s written in Czech; https://kb.vpsfree.cz/navody/vps/kvm#kvm_na_alpine_linuxu 2016-07-25 18:20:27 the main admin of vpsFree.cz is interested in porting some their stuff to Alpine :) 2016-07-25 18:30:37 <^7heo> I will never understand how people can have free VPS 2016-07-25 18:30:46 <^7heo> if it uses electricity, it has to be paid. 2016-07-25 18:35:15 fcolista: please take a look at py-setproctitle 2016-07-25 18:35:37 setup.py install should be run in split functions 2016-07-25 18:37:24 jirutka, ^^^^ 2016-07-25 18:37:30 you're the maintainer 2016-07-25 18:37:44 since you're around, and i'm going @home, you can take a look 2016-07-25 18:37:51 otherwise i'll do it 2moro 2016-07-25 18:38:10 c u guys _o/ 2016-07-25 18:38:40 ^7heo: it’s not free, it cost 300 CZK/month 2016-07-25 18:39:33 bpiotrowski: fcolista what’s wrong with py-setproctitle? 2016-07-25 18:39:47 er, nothing 2016-07-25 18:40:10 fcolista: what I mean is: see what jirutka did, and do the same 2016-07-25 18:40:15 aha :) 2016-07-25 18:41:22 ^7heo: 36 EUR/month 2016-07-25 18:43:11 <^7heo> jirutka: that's not exactly my definition of free, indeed. 2016-07-25 18:43:16 <^7heo> okay I'm braindead now. 2016-07-25 18:43:21 ^7heo: it’s not a company, but a “civic association” (not sure if it’s a correct translation), so formally you don’t pay for hosting, but a membership fee… when you compare this price with classic hosting companies, it’s quite cheap for what you get 2016-07-25 18:43:23 <^7heo> getting to beer and then home. 2016-07-25 18:43:40 ^7heo: yes, I also quite don’t understand whey they use “free” in the name 2016-07-25 18:43:41 <^7heo> jirutka: I dunno, I pay 2€ a month for my VPS 2016-07-25 18:43:54 <^7heo> it doesn't pack much power but it's fine ;) 2016-07-25 18:44:36 ^7heo: well, but there you get 4 GiB RAM, 120 GiB disk with backups (+ 250 GiB on NAS) and 8 cores 2016-07-25 18:45:24 <^7heo> Wow. 2016-07-25 18:45:28 <^7heo> yeah no, not what I have :D 2016-07-25 18:46:04 and not just one VPS (well, OVZ container to be correct), you can create more containers 2016-07-25 18:47:38 <^7heo> ah yeah 2016-07-25 18:47:44 <^7heo> well, I like using terraform for that anyway. 2016-07-25 18:47:44 <^7heo> so... 2016-07-25 19:23:22 <^7heo> ncopa: #5961 2016-07-26 00:16:41 Hurray! Rust succesfully compiled for musl! https://github.com/rust-lang/rust/issues/31322#issuecomment-235124632 2016-07-26 04:03:46 whoo! 2016-07-26 05:08:47 Hi, any guru here know Timo Teras irc name? Thank you. 2016-07-26 05:30:38 tmh1999: I do, why do you ask 2016-07-26 05:30:53 he is not here 2016-07-26 05:31:00 but plenty of others will be happy to help you 2016-07-26 05:32:18 awilfox : I am discussing with him about the cross compiling stuff on the alpine-devel, just want ask him a few small questions 2016-07-26 05:32:49 lots of people here are knowledgeable about cross compiling, common courtesy is to ask the channel instead of one person 2016-07-26 05:33:25 awilfox : I understand, I just feel that asking people to follow the thing in the topic I asked in the mailling is not so nice 2016-07-26 05:33:40 anyway 2016-07-26 07:25:27 ncopa, probaly this was lost: 2016-07-26 07:25:28 fcolista> ncopa, there's new libvirt version, 2.0.0. 2016-07-26 07:25:28 http://sprunge.us/hMNU 2016-07-26 07:25:28 checkapk: http://sprunge.us/gcLC 2016-07-26 07:25:28 no soname differences 2016-07-26 07:25:28 i've ready also py-libvirt with py2/3 subpackages split: http://sprunge.us/PNJd 2016-07-26 07:25:32 i wait for your green light, though 2016-07-26 07:25:34 libvirt-glib is still at 0.2.3, so it remains untouched. Since there's no soname difference, i would not bump pkgrel neither 2016-07-26 07:27:45 sounds good 2016-07-26 07:27:46 but 2016-07-26 07:27:50 i can test it here locally 2016-07-26 07:28:05 k 2016-07-26 07:28:20 i would have waited for your green light before pushing. 2016-07-26 08:24:55 fcolista: you didn't change py-libvirt… 2016-07-26 08:25:20 fcolista: setup.py install should not be run in package() 2016-07-26 08:25:57 yes, you mentioned that, but i overlooked it 2016-07-26 08:26:10 please remember me the reason 2016-07-26 08:28:26 it will make our lifes simpler if package ships something in /usr/bin 2016-07-26 08:28:36 oh 2016-07-26 08:28:38 right 2016-07-26 08:28:39 yes 2016-07-26 08:28:43 now i remember 2016-07-26 08:28:43 and the same scheme for all py packages is nice 2016-07-26 08:28:47 thx for the reminder 2016-07-26 08:28:50 np 2016-07-26 08:28:57 just going to fix it 2016-07-26 08:29:10 i suppose i should to that with other py- packages too 2016-07-26 08:29:17 s/suppose/must 2016-07-26 08:29:26 s/should/must :)= 2016-07-26 08:41:28 anyone here around knows a video conferencing software like bigbluebutton, but less bloating? 2016-07-26 08:44:56 Self-hosted + html5 2016-07-26 08:46:28 ah: no java 2016-07-26 09:37:07 fcolista: jitsi had something 2016-07-26 09:37:52 https://github.com/jitsi/jitsi-meet 2016-07-26 09:55:06 bpiotrowski, it needs java 2016-07-26 09:55:18 ah, I didn't know 2016-07-26 09:55:39 yeah, is not immediate 2016-07-26 09:55:50 gotta read the installation/build doc 2016-07-26 09:55:53 it needs jdk 2016-07-26 09:55:56 uff 2016-07-26 09:56:23 hey :) 2016-07-26 09:58:33 <^7heo> hey. 2016-07-26 09:58:43 hey 2016-07-26 11:02:19 leo-unglaub: hi 2016-07-26 11:28:07 leo-unglaub: https://github.com/rust-lang/rust/issues/31322#issuecomment-235124632 2016-07-26 11:43:28 hi@all 2016-07-26 12:25:10 Hi folks, im trying to bootstrap aarch64-alpine-linux-musl on a alpine_x86-64-chroot on our debianbuildslaves, which are amd64.. I found http://dev.alpinelinux.org/~tteras but it fails poorly?! http://paste.debian.net/785336/ 2016-07-26 12:28:05 seems aarch64 is popular 2016-07-26 12:29:43 debianoid, yes, the aports repo has bad url at the moment 2016-07-26 12:29:49 i'm fixing the whole bootstrap chain 2016-07-26 12:29:59 making abuild fully cross-compile aware 2016-07-26 12:30:07 i hope to push stuff out today/tomorrow 2016-07-26 12:30:39 debianoid, oh, and we have aarch64 port building on clandmeter's box and hope to making it official 2016-07-26 12:30:48 unless you have specific reasons to build your own 2016-07-26 12:31:02 @clandmeter: Im focussing sh4, but for testing-purposes i pulled tterras-repo and fired it 2016-07-26 12:31:46 fabed: sh4 plz 2016-07-26 12:32:47 cool 2016-07-26 12:32:54 someone was working on s390x 2016-07-26 12:33:02 but no sh4 yet to my understanding 2016-07-26 13:32:03 fabled: any idea why cjdns wasn't build on armhf? 2016-07-26 13:32:35 bpiotrowski, was there build logs on failure? 2016-07-26 13:32:46 maybe it just did not get to it yet? 2016-07-26 13:32:47 there is no build logs at all 2016-07-26 13:33:00 maybe 2016-07-26 13:33:23 it's almost a month since I pushed it :( 2016-07-26 13:38:16 edge is still catching up testing 2016-07-27 09:55:25 hi 2016-07-27 09:55:38 <^7heo> hi. 2016-07-27 09:55:51 I submitted a pull request to the aports repository at GitHub https://github.com/alpinelinux/aports/pull/178 2016-07-27 09:56:08 but the development seems to be at http://git.alpinelinux.org/cgit 2016-07-27 09:56:23 am I doing the right thing? 2016-07-27 09:56:53 <^7heo> uma: gh is an alternative to the ML/IRC patches. 2016-07-27 09:57:08 <^7heo> uma: it's totally right to use it; and it provides the additional advantage to test your patches. 2016-07-27 09:57:45 sorry, that does ML stand for? 2016-07-27 09:58:14 <^7heo> Mailing List. 2016-07-27 09:58:30 <^7heo> damn jirutka isn't here. 2016-07-27 09:58:33 oh, right :P 2016-07-27 09:58:40 <^7heo> It's weird that your patch didn't trigger the tests. 2016-07-27 09:58:41 tyvm ^7heo 2016-07-27 09:58:48 <^7heo> uma: no worries. 2016-07-27 09:59:02 yeah, I noticed the other triggered a Travis build 2016-07-27 09:59:08 no idea either 2016-07-27 09:59:12 <^7heo> really weird. 2016-07-27 10:41:42 <^7heo> ncopa: moin 2016-07-27 10:42:17 <^7heo> ncopa: my computer died today; I need to re-install. Threefore it'd be awesome if I could have that nlplug-findfs patch in :P 2016-07-27 10:42:38 <^7heo> s/ree/ere/ 2016-07-27 11:04:56 ^7heo: does not look like it works 2016-07-27 11:05:22 i dont know if it is due to losetup 2016-07-27 11:05:23 <^7heo> daaaamn 2016-07-27 11:05:48 or if it is due to udev is messing with me 2016-07-27 11:06:01 <^7heo> did you test with a deported header? 2016-07-27 11:06:06 yes 2016-07-27 11:06:10 <^7heo> ok 2016-07-27 11:06:26 <^7heo> were you able to open the partition with the deported header with a shell? 2016-07-27 11:06:35 the /dev/loop0 was the cryptdevice and /dev/loop1 was the header 2016-07-27 11:06:37 yes 2016-07-27 11:06:37 <^7heo> like, with cryptsetup LuksOpen --header /dev/bla 2016-07-27 11:06:43 yes, that works 2016-07-27 11:06:46 <^7heo> ok 2016-07-27 11:06:51 and i mkfs.ext4 it 2016-07-27 11:06:54 <^7heo> yeah 2016-07-27 11:07:05 <^7heo> that's bad news for me. 2016-07-27 11:07:08 blkid shows it when its opened 2016-07-27 11:07:14 <^7heo> ok 2016-07-27 11:07:20 i think we are close though 2016-07-27 11:07:20 <^7heo> but nlplug-findfs doesn't find the fs? 2016-07-27 11:07:42 it asks for passphrease 2016-07-27 11:07:46 <^7heo> ok 2016-07-27 11:08:05 <^7heo> but then there no matter what passphrase you input 2016-07-27 11:08:09 <^7heo> it refuses to open the disk? 2016-07-27 11:08:19 Enter passphrase for /dev/loop0: 2016-07-27 11:08:19 No key available with this passphrase. 2016-07-27 11:08:52 <^7heo> I wonder if it would change something if we would explicitely set what key we want to use. 2016-07-27 11:09:23 <^7heo> 'cause for now 2016-07-27 11:09:37 <^7heo> what it does is check all the keys with that pf 2016-07-27 11:09:43 <^7heo> and reports if one works. 2016-07-27 11:10:02 <^7heo> jirutka: travis didn't trigger: https://github.com/alpinelinux/aports/pull/178 2016-07-27 11:10:06 <^7heo> jirutka: any idea why? 2016-07-27 11:10:07 <^7heo> jirutka: moin :P 2016-07-27 11:10:19 <^7heo> (sorry for jumping on you with travis before I even said hello) 2016-07-27 11:10:39 ^7heo: maybe because it’s not merged yet? ;) 2016-07-27 11:10:50 <^7heo> jirutka: what do you mean? 2016-07-27 11:11:01 do you see it here? https://github.com/alpinelinux/aports/commits/master 2016-07-27 11:11:11 the PR was opened 2 hours ago 2016-07-27 11:11:12 <^7heo> jirutka: with all my PRs, travis triggered before anything. 2016-07-27 11:11:21 aha 2016-07-27 11:11:22 sorry 2016-07-27 11:11:32 <^7heo> jirutka: like: https://github.com/alpinelinux/aports/pull/175 2016-07-27 11:11:34 too early for me 2016-07-27 11:11:44 <^7heo> ok :P 2016-07-27 11:11:45 yeah, there’s something wrong 2016-07-27 11:11:53 <^7heo> I wish I could bring you some coffee; but you're a little too far. 2016-07-27 11:12:04 <^7heo> and we're out of mugs anyway. 2016-07-27 11:12:13 <^7heo> what company is out of mugs, really. 2016-07-27 11:12:15 <^7heo> :P 2016-07-27 11:13:13 no worry, we have a great coffee machine :) 2016-07-27 11:13:38 it seems that Travis have some problems 2016-07-27 11:13:54 it’s not listed in https://travis-ci.org/alpinelinux/aports/pull_requests 2016-07-27 11:17:48 <^7heo> yeah 2016-07-27 11:17:51 <^7heo> it's weird. 2016-07-27 11:18:06 <^7heo> I wonder how uma submitted it. 2016-07-27 11:19:09 I just forked the repo and used the plain old GH interface for submitting PRs 2016-07-27 11:19:34 I just forked the repo 2016-07-27 11:19:43 what I don't like with github in 5 words 2016-07-27 11:20:00 <^7heo> skarnet: what's the problem with forking 2016-07-27 11:20:00 when forking a repo becomes the normal way of doing things :( 2016-07-27 11:20:01 <^7heo> ? 2016-07-27 11:20:13 <^7heo> the PR based workflow is great, in practice. 2016-07-27 11:21:09 well, I need to own my own copy of the project, with write access 2016-07-27 11:21:10 sorry, if it's not obvious to you what the problem is with forking a repo as a normal workflow, I'm not sure I'll be able to convey it to you in the amount of time and energy I'm willing to commit to it. 2016-07-27 11:21:26 otherwise I wouldn't be able to submit changes 2016-07-27 11:21:40 uma: I understand, that wasn't against you. 2016-07-27 11:21:41 <^7heo> skarnet: that's a very convoluted way to say that you're considering me too dumb for your time. 2016-07-27 11:22:55 That wasn't what I said, but if you prefer misinterpreting my words, I'm not going to try to correct you either. 2016-07-27 11:22:57 <^7heo> skarnet: you do realize that "forking" is merely a fancy way to copy a repo with setting a remote to the original, right? 2016-07-27 11:23:15 I do, yes. 2016-07-27 11:23:23 <^7heo> so, what's wrong with git cloning? 2016-07-27 11:23:36 <^7heo> or is there something wrong with setting a remote to the original? 2016-07-27 11:23:50 Time's up! lunch time. 2016-07-27 11:23:51 <^7heo> or, is your problem marketing? 2016-07-27 11:23:58 ^ there you go. 2016-07-27 11:24:01 <^7heo> ah. 2016-07-27 11:24:14 <^7heo> Nah but... that's different. It's not github. It's the industry. 2016-07-27 11:24:31 <^7heo> docker is the same 2016-07-27 11:24:45 <^7heo> it's taking a lot of techs and marketing them together with a name. 2016-07-27 11:24:52 uma: you did it right, skarnet is just not familiar with GitHub… it’s not problem on your side 2016-07-27 11:24:52 <^7heo> fancy name for standard stuff. 2016-07-27 11:25:17 <^7heo> jirutka: when did skarnet say that it was a problem on uma's side? =/ 2016-07-27 11:25:21 <^7heo> (I missed that if he did) 2016-07-27 11:25:26 ^7heo: I dunno? 2016-07-27 11:25:33 ^7heo: just skimming the conversation 2016-07-27 11:26:12 <^7heo> ah ok 2016-07-27 11:26:14 uma: I’ve tried to build https://github.com/alpinelinux/aports/pull/178 locally and it failed 2016-07-27 11:26:18 <^7heo> nomnomnomzeit. 2016-07-27 11:26:22 <^7heo> bis bald. 2016-07-27 11:26:39 uma: http://haste.fit.cvut.cz/omoroka.log 2016-07-27 11:26:48 <^7heo> jirutka: could it be that it failed so bad that travis didn't dare to report it? :P 2016-07-27 11:27:13 ^7heo: no, Travis just occasionally didn’t work, don’t worry about it ;) 2016-07-27 11:27:21 <^7heo> oh ok 2016-07-27 11:27:30 <^7heo> again, nomnomnomzeit. 2016-07-27 11:27:31 <^7heo> p/ 2016-07-27 11:28:33 ^7heo: what the hell nomnomnomzeit means? according to its length, is it some german word? :P 2016-07-27 11:32:09 jirutka hm, it looks like I was overoptimistic 2016-07-27 11:32:18 I'll look into it in the evening 2016-07-27 11:32:25 thank you for the log 2016-07-27 11:32:38 uma: okay, no problem :) 2016-07-27 11:55:37 sorry for baiting, I really did have to go get lunch. What I don't like with "forking" is mostly the terminology, and the confusion it entails. Cloning a repo to modify it and then send a PR is reasonable: it's a good way to avoid problems with write access to the master. But it's a very different thing from actually forking a project, which is a very heavy and consequential operation. 2016-07-27 11:56:06 github conflates the two, and people come to think that forking a project is perfectly normal. 2016-07-27 11:56:55 I don't like the industry and commercialization of FOSS, which github is a part of, but the PR workflow is good. 2016-07-27 11:58:11 But using "forking" to mean "creating a temp repo in order to work on my patch and send a PR", and not insisting that those two things are very different, is almost criminal to my eyes. 2016-07-27 11:58:22 There, I've ranted enough for today. Next episode tonight. 2016-07-27 12:06:17 skarnet: this functionality on GitHub is named “Fork”, so when someone tell you that (s)he forked repo on GitHub, you should know what (s)he mean and it’s quity silly to start bitching that “fork” means something else ;) it just confuses people; however, I totally agree with you that it’s not a good terminology 2016-07-27 12:07:38 however, they use it like “Fork the *repository*”, not “Fork the *project*”… and that’s exactly the difference you’re talking about 2016-07-27 12:07:54 it’s a terminus technicus 2016-07-27 12:08:52 human language is very ambiguous and it’s quite common that one word means something (even totally) different depending on context 2016-07-27 12:09:02 yes, and I want the person at GH who came up with that terminology skinned and hanged to a butcher's hook 2016-07-27 12:12:59 In this case I actually meant to say "forking" instead of "creating a temp repo in order to work on my patch and send a PR", as I was asked *exactly how* I submitted the PR 2016-07-27 12:13:17 but I understand that they're basically the same thing 2016-07-27 12:28:46 <^7heo> jirutka: nomnomnom http://www.urbandictionary.com/define.php?term=om%20nom 2016-07-27 12:28:51 <^7heo> jirutka: zeit: time 2016-07-27 12:29:38 this reminds me that I should make myself some coffee :) 2016-07-27 12:30:07 jirutka: is there already a fix for lxc 2.x? 2016-07-27 12:30:58 <^7heo> skarnet: I see the problem. Github is advocating software forking (technically it is). But it makes it look like a trival thing with no consequences. 2016-07-27 12:31:01 <^7heo> skarnet: right? 2016-07-27 12:31:29 <^7heo> skarnet: okay, no need to confirm; I read your second sentence now. 2016-07-27 12:32:59 <^7heo> jirutka: the issue skarnet has is that it's implicitely saying "the repository" and by that, also implicitely possibly meaning "the project", since a repository can very well contain a whole project. 2016-07-27 12:33:09 <^7heo> jirutka: I have to admit that I'm with him on this one. 2016-07-27 12:33:36 <^7heo> < jirutka> human language is very ambiguous 2016-07-27 12:33:42 <^7heo> Now I can see that you're not German ;) 2016-07-27 12:34:00 <^7heo> what you're saying is true for *English* and absolutely wrong for German. 2016-07-27 12:34:30 <^7heo> now that we proved that #alpine-offtopic is there for no reason; we can go back on topic :P 2016-07-27 12:39:28 ^7heo: heh, I really don’t think that German is an exception for this ;) 2016-07-27 12:39:45 <^7heo> jirutka: think again. There's a precise word for anything in German. 2016-07-27 12:40:19 ^7heo: really? you don’t have any single world that can have different meaning? 2016-07-27 12:40:50 <^7heo> jirutka: not as far as I know, no. 2016-07-27 12:40:52 clandmeter: what fix for lxc 2.x do you mean? 2016-07-27 12:41:11 <^7heo> jirutka: if it happens, it's because of an semantical error. 2016-07-27 12:41:17 <^7heo> jirutka: i.e. wrong word. 2016-07-27 12:41:24 jirutka: 2.x works on alpine? 2016-07-27 12:41:32 clandmeter: yes, I’m already using it 2016-07-27 12:41:38 <^7heo> like, you can call a motorcycle "motorized bicycle" 2016-07-27 12:41:46 <^7heo> people will understand it 2016-07-27 12:41:51 <^7heo> but it's not the correct word. 2016-07-27 12:41:52 jirutka: i remember it was broken 2016-07-27 12:42:11 clandmeter: but only privileged containers and “unprivileged” (i.e. using id_map) started by root 2016-07-27 12:42:26 clandmeter: pure unprivileged containers don’t work for me, but not sure why 2016-07-27 12:43:20 ah i see you already added a fix to abuild regarding hte cgroup issue 2016-07-27 12:43:40 nice! 2016-07-27 12:43:45 clandmeter: btw you may be interested in https://github.com/jirutka/uidmapshift 2016-07-27 12:43:50 good work 2016-07-27 12:44:14 clandmeter: uidmapshift from nsexec doesn’t work on Alpine, because it uses some glibc extensions 2016-07-27 12:45:22 clandmeter: I’ve also opened an issue on LXC about adding such functionality to LXC https://github.com/lxc/lxc/issues/1099 2016-07-27 13:01:40 fcolista: around? 2016-07-27 13:01:46 yup 2016-07-27 13:02:17 im trying to build llvm 2016-07-27 13:02:27 but it fails 2016-07-27 13:02:44 its using sphinx 2016-07-27 13:02:54 fabled had this issue 2016-07-27 13:03:03 it was due to a bug of py-setuptools 2016-07-27 13:03:08 that has been corrected in edge 2016-07-27 13:03:09 sphinx deps on 2016-07-27 13:03:10 six 2016-07-27 13:03:13 py-six 2016-07-27 13:03:28 but py-six is empty 2016-07-27 13:03:37 shouldnt that pull in py2-six? 2016-07-27 13:03:58 yes 2016-07-27 13:03:58 python2 setup.py build || return 1 2016-07-27 13:03:58 python3 setup.py build || return 1 2016-07-27 13:04:07 sorry 2016-07-27 13:04:09 wrong paste 2016-07-27 13:04:13 clandmeter: llvm or llvm3.7? 2016-07-27 13:04:18 _py2() { 2016-07-27 13:04:18 _py python2 2016-07-27 13:04:18 replaces="$pkgname" 2016-07-27 13:04:18 } 2016-07-27 13:05:48 llvm 2016-07-27 13:06:19 i need uboot-tools but abuild -R pulls in llvm for some reason. 2016-07-27 13:06:32 pkg_resources.DistributionNotFound: The 'six>=1.4' distribution was not found and is required by Sphinx 2016-07-27 13:07:06 ok 2016-07-27 13:07:36 http://sprunge.us/ViBh 2016-07-27 13:07:43 that's the content of py-six package 2016-07-27 13:10:08 strange 2016-07-27 13:10:31 my aaarch64 builder does not pull in py2-six when installing py-sphinx 2016-07-27 13:11:24 fabled: do you have clue why this happends on aarch64? 2016-07-27 13:11:48 my x86_64 seems to work as it should. 2016-07-27 13:12:05 ncopa: http://sprunge.us/IAEQ 2016-07-27 13:12:10 can I push it? 2016-07-27 13:13:25 clandmeter, sounds weird. maybe there's wrong dependency somewhere, and others pickup due to install_if or similar 2016-07-27 13:15:33 clandmeter, wanna try now? 2016-07-27 13:17:01 fcolista: how does apk know to pull py2 when installing py-six? 2016-07-27 13:18:09 py2-six probably has install_if="py-six python2" ? 2016-07-27 13:18:11 ah, python2 is not yet build 2016-07-27 13:18:22 so it doesnt catch the installif 2016-07-27 13:18:27 fabled, right 2016-07-27 13:19:31 i sent a status update to alpine-devel on the cross abuild work, and some crazy future ideas 2016-07-27 13:19:35 mailing list that is 2016-07-27 13:22:51 clandmeter, install_if="$pkgname=$pkgver-r$pkgrel $python" is missing in py-six 2016-07-27 13:23:11 I'm wondering if we should leave as is 2016-07-27 13:23:19 and update llvm to use py2-six 2016-07-27 13:23:51 python2 is broken abuild 2016-07-27 13:24:20 ? 2016-07-27 13:24:20 somebody really likes to use vars in src 2016-07-27 13:24:27 what you mean? 2016-07-27 13:24:44 ah 2016-07-27 13:24:44 http://www.$pkgname.org/ 2016-07-27 13:24:48 very ugly :) 2016-07-27 13:24:52 :) 2016-07-27 13:25:32 definitely a crack smoker 2016-07-27 13:27:53 fcolista: pushed fix 2016-07-27 13:28:41 hehe 2016-07-27 13:31:04 fcolista: now it doenst pull any py*-six anymore 2016-07-27 13:32:19 i think is due to install_if that is missing 2016-07-27 13:32:28 yes 2016-07-27 13:32:37 but i'm not 100% sure that we want to keep it 2016-07-27 13:33:01 so we should not depends on py-* anymore? 2016-07-27 13:33:46 well, py-* actually is going to be changed to py2 and py3. I would use that rather than a "version free" py-* 2016-07-27 13:33:53 but of course this is open to discussion 2016-07-27 13:34:06 i'm unsure even if it's a good idea 2016-07-27 13:34:24 doesnt this change now break more then one pkg? 2016-07-27 13:34:50 jirutka updates APKBUILD with this template, without install_if 2016-07-27 13:35:12 we dont have some global switch that makes py-* p2 or p3? 2016-07-27 13:35:24 as default python 2016-07-27 13:35:39 I don't think so 2016-07-27 13:36:12 ok so we should specifically depend on a version 2016-07-27 13:36:47 not sure how many abuilds we are talking about, could be aports needs a cleanup/fix. 2016-07-27 13:36:47 Yes...that's the same we do with lua, actually 2016-07-27 13:37:35 well..that's not completely true. lua is lua5.1. 2016-07-27 13:41:29 fcolista: what was wrong with an install_if based on the python version that is installed? 2016-07-27 13:41:36 i think we do similar with lua 2016-07-27 13:42:55 you really need a system equivalent to symlinks. 2016-07-27 13:43:07 For instance, if packages were organized by directory in the filesystem, you'd have: 2016-07-27 13:43:14 lua-5.1: current implementation 2016-07-27 13:43:46 lua-5 -> lua-5.1: packages that depend on lua 5 (not 4 or 6) but don't care about the minor use lua-5 in their scripts 2016-07-27 13:43:59 lua -> lua-5: default installed lua 2016-07-27 13:44:38 same with python-2.7, python-2 -> python-2.7, python -> python-2 looking to change to python -> python-3 2016-07-27 13:44:53 any package manager *should* support that kind of indirection 2016-07-27 13:45:04 skarnet, we should some sort of update-alternatives 2016-07-27 13:45:28 *we should have 2016-07-27 13:45:31 update-alternatives is a deb hack because the deb format doesn't support indirections 2016-07-27 13:45:40 the real solution is to support indirections in apk 2016-07-27 13:45:47 that's why we don't want update-alternatives 2016-07-27 13:46:11 yes, makes sense 2016-07-27 13:46:23 clandmeter, re: install_if 2016-07-27 13:46:30 i don't think that there's something wrong 2016-07-27 13:46:47 If you can live with the current duct tape solutions until next year, I can help revisit apk then 2016-07-27 13:47:06 i'd like to know what's ncopa's idea about that 2016-07-27 13:47:31 sicne we have some py- packaged shipped with package() having python setup.py install 2016-07-27 13:47:59 then we have some py- with $python setup.py install in _py() function rather that package() 2016-07-27 13:48:19 that allows to better manage python's binary installations 2016-07-27 13:48:40 skarnet: what are indirections? 2016-07-27 13:48:51 but this second let's call "template" does not have install_if 2016-07-27 13:49:31 clandmeter: symbolic links, pointers, etc. "indirection" is the generic term. 2016-07-27 13:50:03 CNAME is indirection for DNS. 2016-07-27 13:51:08 fabled, how far is #5011 while you're working on cross-compile? 2016-07-27 13:54:57 fcolista, is mingw built-in to gcc, or separate? 2016-07-27 13:55:35 i think is separate 2016-07-27 13:55:36 but probably not too far away 2016-07-27 13:55:39 oh 2016-07-27 13:55:48 well, it's just building the separate tool then 2016-07-27 13:55:57 i think it does not make sense to package .exe's to .apk 2016-07-27 13:56:06 so my work is not directly related 2016-07-27 13:57:15 so i just need to compile minigw 2016-07-27 14:00:23 nah 2016-07-27 14:00:47 <^7heo> guys, if I execute `git submodule update --init --recursive` 2016-07-27 14:01:06 <^7heo> will git try to find a .git folder BEFORE searching for .gitmodules in the director where it found the .git folder? 2016-07-27 14:01:17 <^7heo> or will it try to search directly the .gitmodules in the current directory? 2016-07-27 14:19:38 fcolista: sorry, I had a meeting… what APKBUILD? 2016-07-27 14:19:50 py templates 2016-07-27 14:20:12 the one you have used: 2016-07-27 14:20:24 which one? 2016-07-27 14:20:26 _py() { 2016-07-27 14:20:26 local python=$1 2016-07-27 14:20:26 pkgdesc="$pkgdesc - $python" 2016-07-27 14:20:26 arch="all" 2016-07-27 14:20:26 cd "$builddir" 2016-07-27 14:20:27 $python setup.py install --prefix=/usr --root="$subpkgdir" 2016-07-27 14:20:29 } 2016-07-27 14:20:40 arh, which package? 2016-07-27 14:20:47 don't remember...lemme check 2016-07-27 14:20:57 barthalion was mentioning it 2016-07-27 14:21:21 ok 2016-07-27 14:21:21 py-setproctitle 2016-07-27 14:21:42 there is install_if https://github.com/alpinelinux/aports/blob/master/testing/py-setproctitle/APKBUILD#L41 2016-07-27 14:21:45 so what’s the problem? 2016-07-27 14:21:51 right 2016-07-27 14:21:54 i missed it 2016-07-27 14:21:58 just figured it now 2016-07-27 14:22:00 nevermind 2016-07-27 14:22:01 sorry 2016-07-27 14:22:11 that’s the problem with copypasta programming… 2016-07-27 14:22:26 i like pasta! 2016-07-27 14:22:38 we really need some lightweight equialent for Gentoo eclass 2016-07-27 14:22:59 ACTION reads eclass and starts to cry 2016-07-27 14:23:08 and I’d like to highlight “lightweight”, because eclasses in Gentoo are really insane 2016-07-27 14:24:05 fcolista: so this python pkg does have install_if. so whats the idea now? 2016-07-27 14:24:08 but this style of copy&pasting chunks of code is also bad 2016-07-27 14:24:21 clandmeter, i'm going to add it. 2016-07-27 14:24:27 fcolista: ok 2016-07-27 14:24:42 this will fix other build issues. 2016-07-27 14:27:47 jirutka: did you add a template for newapkbuild for py packages? 2016-07-27 14:28:26 clandmeter: nope, we currently don’t have any support for py- packages in newapkbuild… but I can add it 2016-07-27 14:28:28 clandmeter, we need an apkbuild-py for that 2016-07-27 14:28:40 libe apkbuild-cpan 2016-07-27 14:28:45 i would prefer that instead of going the eclass route 2016-07-27 14:28:46 or directly newapkbuild 2016-07-27 14:29:08 this is not a real solution, it’s just automated copypasta 2016-07-27 14:29:15 but yea, still better than nothing 2016-07-27 14:29:20 jirutka, do you have a better idea? 2016-07-27 14:30:01 plugins system for apkbuild, something like eclass, but with simplicity in mind 2016-07-27 14:30:44 but that would require more time and thinking, so we should probably start with apkbuild-py, to have at least something 2016-07-27 14:31:59 we both know that eclasses are… well… crazy… a lot of indirection, totally non-transparent…but I think that it can be done better 2016-07-27 14:33:12 ones you start to use lots of plugins transparency is gone. 2016-07-27 14:33:20 +1 2016-07-27 14:33:44 btw I have ~6 years of experience with Gentoo, wrote a lot of ebuilds and also one eclass, so I know it quite well… and yet I’m still lost in eclasses :/ 2016-07-27 14:33:55 it’s not black&white 2016-07-27 14:33:58 one you give users the tools to do it, crazy shit will happen. 2016-07-27 14:34:21 we are in control, so it’s our responsibility to not let it go crazy 2016-07-27 14:35:03 <^7heo> guys, can we use a git repo instead of a tgz in an APKBUILD file? 2016-07-27 14:35:08 to keep these “plugins” really tiny, simple and transparent, just to avoid too much repetitive code 2016-07-27 14:35:08 <^7heo> (as the source of a software) 2016-07-27 14:35:15 we are so much in control that we never wanted plugins for sake of transpernace, but we are still disucssing the topic. 2016-07-27 14:35:16 <^7heo> or rather 2016-07-27 14:35:22 ^7heo: why 2016-07-27 14:35:38 ^7heo: why? 2016-07-27 14:35:41 <^7heo> Adran: because the tar.gz contains git submodules and the information for retrieving them is missing from the tgz? 2016-07-27 14:35:55 ^7heo: It shoudln't contain git sub modules 2016-07-27 14:35:57 ^7heo: then you have two problems… 2016-07-27 14:36:00 <^7heo> yeah 2016-07-27 14:36:02 <^7heo> actually 3. 2016-07-27 14:36:04 <^7heo> it's go software. 2016-07-27 14:36:08 <^7heo> jirutka: ;) 2016-07-27 14:36:19 ^7heo: lol, okay, I’m leaving this dicussion XD 2016-07-27 14:36:20 ^7heo: I package bro - and it requires a LOT of sub modules 2016-07-27 14:36:26 <^7heo> jirutka: tssk tssk 2016-07-27 14:36:36 <^7heo> Adran: is your bro that fat? 2016-07-27 14:36:39 <^7heo> ACTION hides 2016-07-27 14:36:53 Bro is awful to package because it wants things that musl will never support 2016-07-27 14:36:55 <^7heo> anyway Adran please continue, I'm curious how you do that. 2016-07-27 14:37:08 use a snapshot and make sure the source is always the same. 2016-07-27 14:37:15 its the only way 2016-07-27 14:37:15 <^7heo> 'cause the main reason why they use git submodules is for vendoring with go. 2016-07-27 14:37:26 <^7heo> clandmeter: no. I don't want snapshots, sorry. 2016-07-27 14:37:34 But the point is, when you finish packaging, it should be source files, and what clandmeter said. 2016-07-27 14:37:34 <^7heo> clandmeter: they are absolutely unoptimal. 2016-07-27 14:37:36 its not a choice 2016-07-27 14:37:46 atleast not from my point of view 2016-07-27 14:37:50 ^7heo: You are packaging a release 2016-07-27 14:37:54 <^7heo> Adran: yes. 2016-07-27 14:38:20 I mean maybe allow apk to have a "git" release so you can just pull latest and submodules 2016-07-27 14:38:21 But thats a special case, if you have a version number, it should be static files at that point 2016-07-27 14:38:28 got get fetches HEAD afaik 2016-07-27 14:38:37 clandmeter: what 2016-07-27 14:38:37 <^7heo> Adran: eactly. 2016-07-27 14:38:52 <^7heo> s/ea/exa/ 2016-07-27 14:38:54 ^7heo: that means you shouldn't need to have git directories 2016-07-27 14:39:18 <^7heo> Adran: well, I'll have to fetch the version of the submodules from somewhere. 2016-07-27 14:39:25 <^7heo> Adran: and they are *only* in the git tree afaik. 2016-07-27 14:39:27 <^7heo> Adran: so... 2016-07-27 14:39:41 <^7heo> Adran: I'm afraid that for this precise software, there's no other way. 2016-07-27 14:40:27 <^7heo> bbl 2016-07-27 14:41:16 Adran: i mean go get fetch git HEAD from deps. atleast i could not find any reference to tags. 2016-07-27 14:41:28 oh 2016-07-27 14:41:30 command 2016-07-27 14:41:50 clandmeter: if you're only partially awake, you're spekaing another language. :D 2016-07-27 14:41:51 "go get fetch git" 2016-07-27 14:41:52 "do can please clandmeter!" 2016-07-27 14:41:53 :D 2016-07-27 14:42:00 But I understand now. 2016-07-27 14:42:09 :) 2016-07-27 14:42:19 ^7heo: You have the apkbuild? 2016-07-27 14:42:41 yes, "go get" fetches a repo's HEAD instead of a proper tag. 2016-07-27 14:44:09 thats why in my GO apkbuild's I use a snapshot to make sure the build is reproducable. 2016-07-27 14:47:27 <^7heo> Adran: well, it's failing since I can't get the submodules 2016-07-27 14:47:42 <^7heo> Adran: but I'm thinking of vendoring those modules myself and THEN have the build process fetch them with glide. 2016-07-27 14:48:43 <^7heo> clandmeter: and I want to get rid of those snapshots and use glide instead, because it replaces a heavy process involving us hosting something by a simple file in the aport. 2016-07-27 14:49:01 <^7heo> (glide.sh for future ref') 2016-07-27 14:50:04 ^7heo: glide will store version information? 2016-07-27 14:50:10 <^7heo> clandmeter: in a file. 2016-07-27 14:50:12 <^7heo> afaik. 2016-07-27 14:50:31 <^7heo> http://glide.sh/ 2016-07-27 14:51:02 <^7heo> item #5 is what is interesting for us. 2016-07-27 14:51:11 <^7heo> (and is a consequence of the items #1-#4) 2016-07-27 14:51:50 <^7heo> #!/usr/bin/env sh 2016-07-27 14:51:51 <^7heo> dafuq. 2016-07-27 14:51:58 ok that sounds much better then just go get. 2016-07-27 14:52:02 <^7heo> yes. 2016-07-27 14:52:05 <^7heo> that's why I want to go there. 2016-07-27 14:52:12 <^7heo> and I just got the whole afternoon to work on that. 2016-07-27 14:52:23 <^7heo> my supervisor told me to get that working asap 2016-07-27 14:52:29 <^7heo> and I can contribute to alpine that way. 2016-07-27 14:52:31 <^7heo> so I will. 2016-07-27 14:52:43 <^7heo> but I'm a bit annoyed at #!/usr/bin/env sh tbh. 2016-07-27 14:52:52 <^7heo> source: https://glide.sh/get 2016-07-27 14:53:07 <^7heo> /usr/bin/env is less portable than /bin/sh 2016-07-27 14:53:10 get a pitchfork, tar and feathers 2016-07-27 14:53:19 <^7heo> yeah. 2016-07-27 14:53:24 and go have a nice friendly civilized talk with the author of that script 2016-07-27 14:53:27 <^7heo> ACTION will fetch some tar. 2016-07-27 14:53:41 <^7heo> who takes care of the pitchfork and the feathers? 2016-07-27 14:54:06 <^7heo> to be very honest 2016-07-27 14:54:15 <^7heo> https://github.com/Masterminds/glide is apparently 99.6% go. 2016-07-27 14:54:23 <^7heo> so they probably don't really well know how to sh. 2016-07-27 14:54:24 not me, sorry, I'm busy getting the butcher hook ready for the github "fork" guy 2016-07-27 14:54:34 <^7heo> skarnet: :D 2016-07-27 14:57:58 everytime I’m a witness of discussion about Go I wanna cry and sometimes just jump from a window… 2016-07-27 14:58:06 lol 2016-07-27 14:58:25 <^7heo> jirutka: what about a port of systemd in go? 2016-07-27 14:58:40 that will use about the same amount of memory as the original 2016-07-27 14:58:42 <^7heo> then you could write $ go get systemd 2016-07-27 14:58:45 ^7heo: you wanna destroy an universe?! 2016-07-27 14:58:55 <^7heo> jirutka: it's faster than actually dividing by zero. 2016-07-27 14:59:12 <^7heo> I propose to call it systemg. 2016-07-27 14:59:21 systemd-divide-by-zero 2016-07-27 14:59:24 <^7heo> :D 2016-07-27 14:59:50 <^7heo> and let's implement the pentium-FDIV bug in software in it. 2016-07-27 14:59:53 <^7heo> just for the lulz. 2016-07-27 15:03:31 fcolista: could you please avoid trailing spaces? :( 2016-07-27 15:04:03 fcolista: all of your lasts commits contains two spaces after install_if… line 2016-07-27 15:59:47 <^7heo> jirutka: https://github.com/alpinelinux/aports/pull/179 2016-07-27 16:00:42 ^7heo: what does `go get -v -d` do? 2016-07-27 16:05:17 <^7heo> jirutka: downloads the dependencies. 2016-07-27 16:05:26 <^7heo> jirutka: s/^/verbosely / 2016-07-27 16:06:03 how are the dependencies specified? to be more specific, is there some “lock file” that defined exact versions? 2016-07-27 16:06:31 <^7heo> jirutka: no, that's the purpose of glide... 2016-07-27 16:06:39 <^7heo> jirutka: can't build glide with glide support. 2016-07-27 16:06:52 <^7heo> at least not the first time. 2016-07-27 16:06:57 <^7heo> so you can't *expect* it. 2016-07-27 16:07:21 <^7heo> To be very honest, I think it's important to use go get -v -d here and nowhere else. 2016-07-27 16:13:23 <^7heo> jirutka: I commented on the PR. 2016-07-27 16:14:03 so you get different dependencies each time you run it? 2016-07-27 16:14:19 <^7heo> yes. 2016-07-27 16:14:39 I thought that this is unacceptable… 2016-07-27 16:14:44 <^7heo> more correctly: "you potentially get different dependency versions each time you run it." 2016-07-27 16:14:47 <^7heo> jirutka: please read my comment. 2016-07-27 16:14:55 <^7heo> especially the bottom part. 2016-07-27 16:15:18 I read it 2016-07-27 16:15:22 <^7heo> especially the "we cannot depend on glide to build glide" part. 2016-07-27 16:15:34 <^7heo> recursive dependency isn't an option. 2016-07-27 16:15:38 is there some way to make `go get` use a specific tag or commit? 2016-07-27 16:15:42 this is totally unacceptable for any other package, I don’t see any reason why Go should be the only exception 2016-07-27 16:15:49 <^7heo> ncopa: no, otherwise glide wouldn't have a reason to be. 2016-07-27 16:16:00 <^7heo> jirutka: you don't understand. 2016-07-27 16:16:03 <^7heo> jirutka: go isn't the exception. 2016-07-27 16:16:05 <^7heo> jirutka: glide is. 2016-07-27 16:16:15 what is glide? 2016-07-27 16:16:18 when dealing with similar situation in other packages, we must explicitly declare all the dependencies in apkbuild and download them 2016-07-27 16:16:21 <^7heo> glide is a vendoring tool for go. 2016-07-27 16:16:32 <^7heo> glide allows to have reproducible builds with go. 2016-07-27 16:16:57 glide is basically a poor workaround for absence of any sane dependency control in Go… 2016-07-27 16:16:59 <^7heo> as per http://glide.sh/, #5: " 2016-07-27 16:16:59 <^7heo> Reproducible Installations 2016-07-27 16:16:59 <^7heo> Install the dependencies and revisions listed in the lock file into the vendor directory. If no lock file exists an update is run. 2016-07-27 16:17:02 <^7heo> " 2016-07-27 16:17:15 <^7heo> jirutka: not so poor. 2016-07-27 16:17:20 that’s what I asked, if there’s some lock file 2016-07-27 16:17:28 <^7heo> jirutka: once you have glide, yes. 2016-07-27 16:17:40 <^7heo> jirutka: but we cannot depend on glide for glide. 2016-07-27 16:17:54 so you ned glide to build glide 2016-07-27 16:18:01 that’s not so uncommon 2016-07-27 16:18:06 you need to bootstrap? 2016-07-27 16:18:07 <^7heo> ncopa: no you don't. 2016-07-27 16:18:08 we have similar situatuon with openjdk, rust etc. 2016-07-27 16:18:18 <^7heo> ncopa: you need glide to build glide *reproducably* 2016-07-27 16:18:26 ok-ish solution is to create a snapshot and use that for building next versions 2016-07-27 16:18:31 <^7heo> jirutka: I was gonna say that. 2016-07-27 16:18:42 <^7heo> jirutka: glide is the only go package that *needs* a snapshot. 2016-07-27 16:19:02 <^7heo> Should I write a snapshot function for that package? 2016-07-27 16:19:08 except all these go shits (i mean packages) that doesn’t use glide or anythins imilar… yeah… :) 2016-07-27 16:19:09 <^7heo> For it to be merged? 2016-07-27 16:19:32 <^7heo> jirutka: we are going to use glide for all go packages from now on, I hope. 2016-07-27 16:19:37 <^7heo> jirutka: clandmeter is already informed. 2016-07-27 16:19:52 <^7heo> in any case 2016-07-27 16:20:09 <^7heo> ncopa, jirutka: should I change the contributor name to mine if I push something, or do I leave it that way? 2016-07-27 16:20:28 as I see, it’s not a new aport, but just update… but IMHO this aport should not be accepted at the first place… maybe we should write rules, because I’m very sure that this was not acceptable for any other packages 2016-07-27 16:20:44 <^7heo> jirutka: it's an update of an aport that doesn't have a reproducible build. 2016-07-27 16:21:07 <^7heo> jirutka: so far I only bumped the version. 2016-07-27 16:21:23 and I really hate when I see how some crappy yet popular lang comes and now we don’t care about some rules anymore, just for this platform… 2016-07-27 16:21:29 it’s very unfair 2016-07-27 16:21:36 <^7heo> jirutka: now, I'm also agreeing with you that we should't accept aports that aren't reproducible. 2016-07-27 16:21:51 <^7heo> jirutka: no matter what lang. 2016-07-27 16:23:16 it’s not just about reproducibility… there’s also some rule about explicit declaration of dependencies (i.e. there are specified in $source and we have checksums), isn’t it? 2016-07-27 16:26:25 <^7heo> jirutka: well, yes and no. 2016-07-27 16:26:46 <^7heo> jirutka: if in C, you're using a header, you don't put that in the checksums. 2016-07-27 16:27:11 <^7heo> jirutka: you just have a package that provides them, and you builddepend on it. 2016-07-27 16:27:16 no, I must create a package for that dependency that provides the head file 2016-07-27 16:27:21 <^7heo> yeah. 2016-07-27 16:27:31 but you’re not creating packages for that dependencies 2016-07-27 16:27:35 <^7heo> now, that package fetches the headers from somewhere 2016-07-27 16:27:45 <^7heo> and that archive has a checksum too. 2016-07-27 16:27:51 you’re just letting some crappy tool to fetch them, whatever version does it actually fetch, we don’t even know if it’s somehow verfied 2016-07-27 16:27:52 <^7heo> right? 2016-07-27 16:28:04 <^7heo> can you please stop ranting a minute and bear with me? 2016-07-27 16:28:22 I’m not fetching a header from somewhere… 2016-07-27 16:28:40 the package typically fetches some source tarball, we have a checksum of this tarball 2016-07-27 16:28:41 <^7heo> okay, in the event of the linux headers... 2016-07-27 16:28:44 <^7heo> how do you obtain them? 2016-07-27 16:29:01 <^7heo> that's *exactly* what I've been saying. 2016-07-27 16:29:04 <^7heo> anyway. 2016-07-27 16:29:17 <^7heo> Since we both agree but still need to argue about the same thing... 2016-07-27 16:29:25 <^7heo> I'll continue without paying attention to the argument for now. 2016-07-27 16:29:28 <^7heo> So 2016-07-27 16:29:55 the point is that once you create a package, you have a guarantee that next time you build it, you will get exact the same tarball as previous, exact the same version… otherwise it will fail 2016-07-27 16:30:08 that is the problem 2016-07-27 16:30:13 <^7heo> The difference between using a vendoring file and the packages is that the vendoring file contains versions of archives. Not checksums. 2016-07-27 16:30:34 <^7heo> if the vendoring file would contain checksums along with versions, and that the vendoring tool (glide in our case) would ensure that they are consistent... 2016-07-27 16:30:42 <^7heo> that would be exactly identical. 2016-07-27 16:30:50 <^7heo> (albeit not enforced by abuild) 2016-07-27 16:31:08 <^7heo> So 2016-07-27 16:31:10 glide-0.11.1 might not be the same as glide-0.11.1 if they are not built at the same time 2016-07-27 16:31:11 wait a moment… I’d be quite okay with a file that defines exact versions… but we’re talking about quite different topic now 2016-07-27 16:31:12 <^7heo> now we have two things 2016-07-27 16:31:35 <^7heo> 1. we need to create a snapshot for glide to insure that we always get the same files 2016-07-27 16:31:59 <^7heo> 2. we need to have glide lockfiles that contain checksums and check them. 2016-07-27 16:32:02 <^7heo> OR 2016-07-27 16:32:23 <^7heo> the-1-and-only. We need to vendor any go library in apk ourselves. 2016-07-27 16:32:30 <^7heo> but that is a lot of work. 2016-07-27 16:32:56 <^7heo> at the same time, if we need some C library, we need a -dev package for it. 2016-07-27 16:33:03 <^7heo> so, it's already what we do for C. 2016-07-27 16:33:08 yeah, it’s a lot of work… it’s waste of resources… exactly… and what do you think that is creating packages for Python/Ruby/Lua modules…, hm? 2016-07-27 16:33:49 <^7heo> jirutka: please don't ask sarcastic questions, less clarity is the last thing we need when we try to agree on something. 2016-07-27 16:34:02 ^7heo: it seems like glide builds without `go get`? 2016-07-27 16:34:17 <^7heo> ncopa: not on my machine it doesn't. 2016-07-27 16:34:18 ^7heo: I think that you don’t understand me now 2016-07-27 16:34:31 <^7heo> jirutka: I'm not sure I do; I'd like to be sure I do ;) 2016-07-27 16:34:37 http://tpaste.us/Gxmo 2016-07-27 16:34:45 ^7heo: what error do you get? 2016-07-27 16:35:07 <^7heo> ncopa: well, missing deps. 2016-07-27 16:35:11 <^7heo> I got that before already. 2016-07-27 16:35:15 <^7heo> but lemme pastebin it for you. 2016-07-27 16:35:49 $ abuild -r 2>&1 | tpaste 2016-07-27 16:35:49 http://tpaste.us/AyEy 2016-07-27 16:36:38 ^7heo: In my opinion current state of package managers in common distributions is outdated and unsustainable, it was created just with C/C++ and dynamic linking in mind, it doesn’t make any sense when we have more modern platforms that handles dependencies 2016-07-27 16:36:49 <^7heo> ncopa: http://ix.io/181Q 2016-07-27 16:37:42 ^7heo: but we have some rules… and we should decide if we want to change them, for all, or not… not violate them just for some 2016-07-27 16:38:01 <^7heo> jirutka: I agree, we need better tools. 2016-07-27 16:38:04 <^7heo> jirutka: but we don't have them. 2016-07-27 16:38:13 <^7heo> jirutka: so, let's find a solution to THAT problem and then improve the world ;) 2016-07-27 16:38:33 <^7heo> jirutka: I don't want to postpone each problem I encounter to solve a bigger one. 2016-07-27 16:38:40 <^7heo> jirutka: that's not a way to succeeed. 2016-07-27 16:38:48 ^7heo: we alreday have them: cargo, rubygem, pip, … the only problem is with this horrible C/C++ legacy 2016-07-27 16:38:54 <^7heo> jirutka: and not having a package isn't an option =/ 2016-07-27 16:39:15 <^7heo> jirutka: okay, how do we build pip? 2016-07-27 16:39:16 ^7heo: and of course, another problem that these lang-specific dependency managers don’t talk with each other 2016-07-27 16:39:24 i wonder why you get that error 2016-07-27 16:39:30 while i dont 2016-07-27 16:39:47 <^7heo> ncopa: because you have those packages installed in your $GOROOT and I don't 2016-07-27 16:40:03 <^7heo> ncopa: or in your gopath. 2016-07-27 16:40:08 <^7heo> ncopa: by previous installations. 2016-07-27 16:40:17 <^7heo> ncopa: you basically vendored them already once. 2016-07-27 16:40:21 <^7heo> ncopa: they are there. 2016-07-27 16:40:33 <^7heo> ncopa: outside of the build dir. So they stayed. 2016-07-27 16:40:53 where is the gopath? 2016-07-27 16:40:59 <^7heo> echo $GOPATH 2016-07-27 16:41:10 <^7heo> that should tell you ;) 2016-07-27 16:41:10 empty 2016-07-27 16:41:22 <^7heo> $ grep GOPATH .zshrc 2016-07-27 16:41:22 <^7heo> export GOPATH="/home/theo/Workspace" 2016-07-27 16:41:39 ah 2016-07-27 16:41:50 <^7heo> but 2016-07-27 16:41:53 and GOROOT? 2016-07-27 16:41:57 ^7heo: we should ask if we want to change the rules or not… if not, then handle it in the same way as in other packages… don’t rely on go get, but declare all the dependencies in source=, let abuild fetch them and place them to the correct path 2016-07-27 16:41:58 <^7heo> your GOROOT is set by the go tools afaik. 2016-07-27 16:42:05 <^7heo> because, I have no $GOROOT 2016-07-27 16:42:14 <^7heo> sh -c 'echo $GOROOT' 2016-07-27 16:42:15 <^7heo> 2016-07-27 16:42:24 <^7heo> same in zsh 2016-07-27 16:42:36 weird 2016-07-27 16:42:39 <^7heo> well 2016-07-27 16:43:20 <^7heo> ncopa: I updated http://ix.io/181Q with the output of my $ go env 2016-07-27 16:43:21 ^7heo: or we can change the rules… but what you’re currently doing is not changing the rules, but violating them 2016-07-27 16:43:31 <^7heo> ncopa: now you can see what values it takes. 2016-07-27 16:43:56 <^7heo> ncopa: $GOPATH is from my .zshrc bu $GOROOT is defaulting to the binary's defaults I'd say. 2016-07-27 16:44:09 <^7heo> jirutka: okay, what do you propose? 2016-07-27 16:44:22 <^7heo> jirutka: that we vendor those needed packages in apk ourselves, and use glide for the rest? 2016-07-27 16:44:35 <^7heo> jirutka: that we require a snapshot? 2016-07-27 16:44:43 ^7heo: i'm not convinced 2016-07-27 16:44:43 ^7heo: and now to be more pragmatic… the main problem I see is that you have no control what versions it will use; isn’t there some way how to semi-manually parse glide lockfile to download specified versions? 2016-07-27 16:44:45 <^7heo> jirutka: or another solution that I don't know? 2016-07-27 16:44:50 <^7heo> ncopa: of? 2016-07-27 16:45:02 that go get is actually needed 2016-07-27 16:45:17 <^7heo> ncopa: it is not. If we have packages for the dependencies it is fine. 2016-07-27 16:45:40 i think the deps are shipped in the tarball 2016-07-27 16:45:41 <^7heo> jirutka: I would like to not rely on a snapsopt myself. I would be okay to maintain the few dev packages needed for glide. 2016-07-27 16:45:48 i am pretty sure i dont have the deps installed 2016-07-27 16:45:51 <^7heo> ncopa: what? no. 2016-07-27 16:45:55 <^7heo> ncopa: lemme check. 2016-07-27 16:46:36 i want push it and see what happens 2016-07-27 16:46:39 <^7heo> ncopa: my apologies. 2016-07-27 16:46:42 without the go get 2016-07-27 16:46:42 <^7heo> ncopa: you are right. 2016-07-27 16:46:48 <^7heo> ncopa: no wait. please wait. 2016-07-27 16:46:52 ^7heo: how does it work? https://github.com/Masterminds/glide/blob/master/glide.lock there are all the dependencies that it needs? including transitive ones? 2016-07-27 16:47:08 <^7heo> ncopa: you are right, it is bound to work. 2016-07-27 16:47:12 ncopa: you can let Travis to build it 2016-07-27 16:47:19 <^7heo> ncopa: the reason why I get this error is because my go path doesn't include the srcdir. 2016-07-27 16:47:45 <^7heo> ncopa: lemme patch the APKBUILD so it works on systems that have already have a go setup. 2016-07-27 16:47:54 jirutka: thanks for reviewing it 2016-07-27 16:48:04 i call this teamwork :) 2016-07-27 16:48:28 ^7heo: if this https://github.com/Masterminds/glide/blob/master/glide.lock contains all the packages you need and these “version” attributes are git sha1, then it’s simple 2016-07-27 16:48:28 <^7heo> thanks ncopa for notifying me that they vendor the dependencies. 2016-07-27 16:49:13 <^7heo> jirutka: yes this is containing the git sha. 2016-07-27 16:49:29 ^7heo: remove the go get line and git push -f and let travis build it 2016-07-27 16:49:38 ^7heo: github.com/codegangsta/cli 71f57d300dd6a780ac1856c005c4b518cfd498ec → https://github.com/urfave/cli/archive/d9021faab69f92295ef7061bd39e4a76dcbdef32.tar.gz 2016-07-27 16:49:38 <^7heo> jirutka: it basically gives you a way to get the dependencies of a go project with locked sha. 2016-07-27 16:49:38 you can add -v to go build though 2016-07-27 16:50:01 <^7heo> ncopa: no, it needs to build on computers that have a go setup. 2016-07-27 16:50:04 ^7heo: you can put these to source= and let aubild manage them (verify checksums, fetch them etc.) 2016-07-27 16:50:08 <^7heo> ncopa: not only on disposable VMs. 2016-07-27 16:50:22 <^7heo> ncopa: I'm gonna remove the go get -d -v line and tweak the GOPATH. 2016-07-27 16:51:17 the weird thing that the APKBUILD actually set the GOPATH 2016-07-27 16:51:24 so i wonder why it happens 2016-07-27 16:51:46 ^7heo: are you still with me? :) what do you think about my proposal about using information from glide.lock…? 2016-07-27 16:52:30 i'm gonna push perl 5.24 now 2016-07-27 16:52:38 it will keep the builders busy for a while 2016-07-27 16:53:48 <^7heo> ncopa: yeah, but it doesn't set the GOPATH to the right folder. 2016-07-27 16:53:53 <^7heo> ncopa: I don't know why it works for you 2016-07-27 16:53:59 <^7heo> ncopa: but the right folder is vendor/ 2016-07-27 16:54:45 <^7heo> testing/glide/src/go/src/github.com/Masterminds/glide/vendor/ contains all I need. 2016-07-27 16:56:03 <^7heo> also 2016-07-27 16:56:13 <^7heo> go searches for 'src/' in the GOPATH. 2016-07-27 16:56:24 <^7heo> so if the folder is called 'vendor/' that doesn't work. 2016-07-27 16:58:18 maybe we can create some symlink 2016-07-27 16:58:32 <^7heo> ncopa: yeah 2016-07-27 16:58:38 <^7heo> ncopa: what version of go do you have? 2016-07-27 16:59:13 go version 2016-07-27 16:59:13 go version go1.6.2 linux/amd64 2016-07-27 16:59:16 aha 2016-07-27 16:59:29 <^7heo> yeah. 2016-07-27 16:59:35 <^7heo> go version go1.4.2 linux/amd64 2016-07-27 16:59:40 <^7heo> that might explain why. 2016-07-27 16:59:44 yup 2016-07-27 16:59:53 <^7heo> $ sudo apk add -u go 2016-07-27 16:59:53 <^7heo> OK: 1794 MiB in 480 packages 2016-07-27 16:59:59 edge? 2016-07-27 16:59:59 <^7heo> yeeaaaaah. 2016-07-27 17:00:01 <^7heo> yeah. 2016-07-27 17:00:21 <^7heo> I don't know why 2016-07-27 17:00:26 <^7heo> my packages are getting stuck quite often. 2016-07-27 17:00:31 weird indeed 2016-07-27 17:00:36 apk version 2016-07-27 17:00:41 <^7heo> hah 2016-07-27 17:00:45 <^7heo> apk version go 2016-07-27 17:00:45 <^7heo> Installed: Available: 2016-07-27 17:00:45 <^7heo> go-1.4.2-r0 ? 2016-07-27 17:00:56 <^7heo> (I did that before, hence the 'hah') 2016-07-27 17:01:05 <^7heo> I'm gonna pastebin you my /etc/apk/repositories 2016-07-27 17:01:07 maybe you dont have community repo 2016-07-27 17:01:23 <^7heo> http://ix.io/182i 2016-07-27 17:01:46 <^7heo> I do. 2016-07-27 17:01:51 <^7heo> it's just tagged. 2016-07-27 17:01:53 you need specify it 2016-07-27 17:01:58 apk add go@community 2016-07-27 17:02:00 <^7heo> so apk add go@community fix. 2016-07-27 17:02:05 yes 2016-07-27 17:02:06 <^7heo> s/fix/&ed it/ 2016-07-27 17:02:20 <^7heo> let's see if it works better now. 2016-07-27 17:02:28 i bet it does 2016-07-27 17:02:33 <^7heo> well, it's still dl-ing 2016-07-27 17:03:27 <^7heo> ooooh, it -works- 2016-07-27 17:03:41 <^7heo> well, I'm sorry we spent so much time for me not knowing how to upgrade my system. 2016-07-27 17:03:48 :D 2016-07-27 17:03:51 lol 2016-07-27 17:04:19 <^7heo> package upgraded. 2016-07-27 17:05:05 <^7heo> jirutka: you can see it now. 2016-07-27 17:05:10 <^7heo> also 2016-07-27 17:05:25 <^7heo> we should flag all the APKBUILD files containing 'go get' 2016-07-27 17:05:35 <^7heo> wooooow 2016-07-27 17:05:37 <^7heo> there are a LOT. 2016-07-27 17:06:13 i dont know how to solve the go problem. so i just stick my head in the sand and hope someone else fixes it... 2016-07-27 17:06:22 <^7heo> http://ix.io/182k 2016-07-27 17:06:29 <^7heo> that's the packages we need to refactor without go get. 2016-07-27 17:06:41 <^7heo> ncopa: I propose to try to fix it. 2016-07-27 17:06:48 you call that "a LOT" :) 2016-07-27 17:07:12 <^7heo> ncopa: Nah, I actually was running the command grep -lri 'go get' instead of grep -lri 'go get' | grep APKBUILD 2016-07-27 17:07:21 <^7heo> ncopa: then I wrote 'a LOT' 2016-07-27 17:07:30 <^7heo> ncopa: then I realized that most of it was from gogs. 2016-07-27 17:07:31 i just pushed a "handful" updates of perl rebuilds 2016-07-27 17:08:13 <^7heo> Anyway, so, we have glide now. 2016-07-27 17:08:15 <^7heo> Newest version. 2016-07-27 17:08:20 good 2016-07-27 17:08:31 <^7heo> I'm gonna have to make sure that it does the checksum checking correctly. 2016-07-27 17:09:22 <^7heo> the problem I see is that we can use glide at two different moments: 2016-07-27 17:09:29 <^7heo> 1. when we build the package 2016-07-27 17:09:36 <^7heo> 2. when we write the APKBUILD 2016-07-27 17:10:57 <^7heo> ncopa: would it be acceptable to have a file that is versionned (and has a checksum) along with the APKBUILD, which contains git sha-1 versions of a software? 2016-07-27 17:11:10 <^7heo> ncopa: there's no way someone can change the software without changing the sha-1 afaik. 2016-07-27 17:11:19 <^7heo> ncopa: so that would provide reproducible builds all the time, right? 2016-07-27 17:12:06 <^7heo> jirutka: sorry I got sidetracked. 2016-07-27 17:12:39 <^7heo> jirutka: about that information from the glide.lock, here is what I propose: 2016-07-27 17:13:19 <^7heo> - glide.lock points to specific source in a specific place. There is no way to replace that source without changing the sha-1, so without invalidating the lock file. 2016-07-27 17:13:36 <^7heo> - that glide.lock file has a checksum, so we can ensure it doesn't change. 2016-07-27 17:14:21 ^7heo: thats what we kind of do by checksumming the tarballs 2016-07-27 17:14:53 <^7heo> ncopa: yeah. 2016-07-27 17:15:08 <^7heo> ncopa: so I think that with glide, having an APKBUILD file along with the glide.lock file... 2016-07-27 17:15:35 <^7heo> ncopa: would allow us to ensure the reproducibility of the builds, along with ensuring that the code didn't change. 2016-07-27 17:15:52 <^7heo> ncopa: and that would be enough. 2016-07-27 17:16:12 <^7heo> jirutka: what about greping for harmful patterns in the APKBUILDS in travis? 2016-07-27 17:16:24 <^7heo> jirutka: for example 'go get' 2016-07-27 17:16:39 <^7heo> grep -q 'go get' && return 1 2016-07-27 17:24:00 <^7heo> jirutka: https://github.com/alpinelinux/aports/pull/118 < I ucfirst()ed the names in there. Please tell me if it's still missting something. 2016-07-27 17:30:16 ^7heo: yes, but what about glide itself? I’m suggesting to construct URLs for tar.gz from glide’s glide.lock, add these URLs to source=, let abuild fetch them, put them somewhere when go can find it and use when building itself 2016-07-27 17:30:39 ^7heo: sorry for long response time, some colleague of mine came to talk with me 2016-07-27 17:31:52 <^7heo> jirutka: glide itself contains the necessary dependencies. 2016-07-27 17:31:58 <^7heo> jirutka: they have been clever enough to ship them in. 2016-07-27 17:32:12 ^7heo: https://github.com/Masterminds/glide/blob/master/glide.lock → { name: github.com/codegangsta/cli, version: 71f57d300dd6a780ac1856c005c4b518cfd498ec } → https://github.com/urfave/cli/archive/d9021faab69f92295ef7061bd39e4a76dcbdef32.tar.gz 2016-07-27 17:32:16 <^7heo> jirutka: I was considering them stupid, they proved me wrong. 2016-07-27 17:32:23 ^7heo: aha 2016-07-27 17:32:38 ^7heo: I think that your consideration is actually right… :P 2016-07-27 17:32:43 <^7heo> :P 2016-07-27 17:33:07 <^7heo> So long story short: would you consider failing the travis on some harmful patterns? 2016-07-27 17:33:14 <^7heo> such as 'go get' 2016-07-27 17:33:20 Go was developer specifically for stupid coding monkeys that happens to work at google… :P 2016-07-27 17:33:33 <^7heo> tssk tssk; now now... 2016-07-27 17:34:09 ^7heo: oh yes, I’d be happy to add some check like makedepends="go" → fail the build :P 2016-07-27 17:34:30 ^7heo: oh, you’re talking just about “go get”… okay… 2016-07-27 17:36:14 ^7heo: GitHub is actually written GitHub, not Github :P 2016-07-27 17:38:53 <^7heo> jirutka: meeeeeeeh 2016-07-27 17:38:59 <^7heo> okay, changing that. 2016-07-27 17:40:56 <^7heo> jirutka: done. 2016-07-27 17:40:58 <^7heo> jirutka: better? 2016-07-27 17:41:24 ^7heo: yeah, my OCD is happier now :) 2016-07-27 17:42:01 <^7heo> jirutka: I'm always happy to comply by other developer's OCDs ;) 2016-07-27 17:42:08 XD 2016-07-27 17:42:10 <^7heo> jirutka: it's better than mindlessly committing all the crap and never testing. 2016-07-27 17:42:16 btw Alpine-Linux → Alpine Linux :P 2016-07-27 17:42:21 <^7heo> ACTION hides 2016-07-27 17:42:25 <^7heo> ok 2016-07-27 17:43:37 <^7heo> jirutka: better? 2016-07-27 17:43:51 :+1: 2016-07-27 17:44:07 <^7heo> great. 2016-07-27 17:44:17 <^7heo> ncopa: are you okay with merging https://github.com/alpinelinux/aports/pull/118 ? 2016-07-27 17:44:46 <^7heo> jirutka: awesome, thanks for merging the new glide. 2016-07-27 18:23:06 <^7heo> jirutka: https://github.com/alpinelinux/aports/pull/180 2016-07-27 18:23:09 <^7heo> jirutka: what do you think of that? 2016-07-27 18:24:10 ^7heo: that it should be a separate script 2016-07-27 18:24:26 <^7heo> jirutka: why? 2016-07-27 18:24:42 ^7heo: also it would be more useful to add some hint why is that pattern forbidden 2016-07-27 18:25:09 <^7heo> jirutka: well, no, that would be the role of the commit message associated with the pattern addition in .travis/forbidden_patterns 2016-07-27 18:25:20 <^7heo> jirutka: but I could point that out in the error message. 2016-07-27 18:25:29 ^7heo: because the responsibility of build-pkgs script is to build packages, not to do some ad-hoc checks of apkbuilds 2016-07-27 18:25:55 <^7heo> jirutka: so you would rather modify the travis.yaml file and add a step there? 2016-07-27 18:26:08 ^7heo: also why it should be tight with travis scripts? 2016-07-27 18:26:13 ^7heo: no, that’s not what I mean 2016-07-27 18:26:29 ^7heo: it can be a separate script in .travis called from build-pkgs 2016-07-27 18:26:34 <^7heo> ah 2016-07-27 18:26:45 <^7heo> jirutka: I don't get the point in doing that tho. 2016-07-27 18:27:13 ^7heo: separation of concerns 2016-07-27 18:27:35 <^7heo> okay, lemme check. 2016-07-27 18:28:50 ^7heo: also it would be more useful to make it as a separate tool that one can install using apk; there are still a lot people sending patches via mailing list 2016-07-27 18:31:18 <^7heo> jirutka: yeah well 2016-07-27 18:31:27 <^7heo> jirutka: separating it is already annoying AF. 2016-07-27 18:31:39 <^7heo> jirutka: I only wanted to do that quickly to reject the shit. 2016-07-27 18:31:39 ? 2016-07-27 18:31:44 <^7heo> jirutka: you want that perfect. 2016-07-27 18:31:52 <^7heo> jirutka: I'll do that tomorrow. Recursively. 2016-07-27 18:32:08 yeah, but there are way more patterns that we’d like to check 2016-07-27 18:32:41 for example URLs with pypi.python.org/packages 2016-07-27 18:34:11 I just want to keep scripts clean, simple and maintainable, not add ad-hoc stuff we currently need, this leads to the hell 2016-07-27 18:34:13 <^7heo> jirutka: you can add one pattern per line in the file. 2016-07-27 18:34:17 <^7heo> jirutka: isn't that enough? 2016-07-27 18:34:43 <^7heo> jirutka: but deporting the functionality is adding much more complexity to it. 2016-07-27 18:34:50 <^7heo> jirutka: sh cannot 'return' values. 2016-07-27 18:35:13 but it can print to the stdout/stderr 2016-07-27 18:35:13 <^7heo> you have to echo them. 2016-07-27 18:35:16 <^7heo> yeah. 2016-07-27 18:35:21 <^7heo> but then you have to pipe. 2016-07-27 18:35:24 and it can return exit code 2016-07-27 18:35:28 <^7heo> and doing that you lose the exit code. 2016-07-27 18:35:30 that is perfectly suitable for a linter 2016-07-27 18:35:43 <^7heo> yeah but if I pipe I say goodbye to the exit code 2016-07-27 18:35:49 why? 2016-07-27 18:35:51 <^7heo> if I use the exit code I say goodbye to returning echo. 2016-07-27 18:36:03 <^7heo> because false | echo 'bla' will always return true. 2016-07-27 18:36:17 <^7heo> and echo 'bla' also 2016-07-27 18:36:47 <^7heo> so essentially 2016-07-27 18:36:52 <^7heo> either I echo in my function 2016-07-27 18:36:53 uh, it’s very simple, we just need to know if it’s okay (return 0), or not (return 1) 2016-07-27 18:36:59 and also print some message for the user 2016-07-27 18:37:00 <^7heo> or I determine the exit code based on the output. 2016-07-27 18:37:04 why pipes etc? 2016-07-27 18:37:27 <^7heo> because the output should be done after. 2016-07-27 18:37:36 <^7heo> but okay, I'll do the output in the function. 2016-07-27 18:37:38 <^7heo> and exit after. 2016-07-27 18:37:52 I don’t understand what you mean 2016-07-27 18:38:38 <^7heo> nevermind. 2016-07-27 18:38:43 <^7heo> I'll push soon and you'll review that. 2016-07-27 18:38:50 <^7heo> it's easier to see the code than to describe it. 2016-07-27 18:39:13 and btw this `[ "$pattern" = "" ] && continue` may not work with set -e (but not sure now) 2016-07-27 18:39:55 also the second line may fail, because when the condition is not satisfied, then return value of whole statement is 1 2016-07-27 18:40:05 <^7heo> jirutka: why not? 2016-07-27 18:40:28 <^7heo> because if "$pattern" != "" then it will return false? 2016-07-27 18:40:38 yeah 2016-07-27 18:40:54 <^7heo> nah 2016-07-27 18:41:02 but `set -e` behaves differently in various shells, so I’m not sure 2016-07-27 18:41:02 <^7heo> continue should return 0 or? 2016-07-27 18:41:06 <^7heo> yeah 2016-07-27 18:41:31 you can just swap it, use || instead of && 2016-07-27 18:41:52 or use if… then… fi 2016-07-27 18:42:08 but I really should do some work now 2016-07-27 18:42:35 <^7heo> jirutka: http://ix.io/183E 2016-07-27 18:42:58 do you have `set -e` enabled? 2016-07-27 18:43:06 <^7heo> read it :) 2016-07-27 18:43:08 aha, you have 2016-07-27 18:43:08 sry 2016-07-27 18:43:10 <^7heo> ;) 2016-07-27 18:43:47 and is this ash? 2016-07-27 18:43:54 <^7heo> jirutka: http://ix.io/183F 2016-07-27 18:43:56 <^7heo> yes. 2016-07-27 18:44:01 <^7heo> that is busybox's sh. 2016-07-27 18:44:19 okay 2016-07-27 18:44:21 <^7heo> just to show you, that it works as expected. 2016-07-27 18:44:50 <^7heo> So yeah 2016-07-27 18:52:13 <^7heo> okay, barthalion was helpful on that one. 2016-07-27 18:52:19 <^7heo> I'll do what he siad. 2016-07-27 18:52:20 <^7heo> said* 2016-07-27 18:53:26 <^7heo> jirutka: can you apply the "WIP" label to that PR? 2016-07-27 18:56:30 <^7heo> skarnet: curl -Ssl glide.sh/get | head -n1 2016-07-27 18:56:32 <^7heo> \o/ 2016-07-27 19:04:18 ^7heo: what the heck are you doing? this is like throwing a grenade to skarnet… :P 2016-07-27 19:05:32 ^7heo: ah, it’s head, no sh… nevermind 2016-07-27 19:05:55 ^7heo: when I saw it I thought that it’s common piping to shell… too tired :P/ 2016-07-27 19:07:21 <^7heo> jirutka: nah I wouldn't do that. :) 2016-07-27 19:07:28 <^7heo> jirutka: but yeah it's been a long day. 2016-07-27 19:07:34 <^7heo> jirutka: and I want to commit concourse before I go home. 2016-07-27 19:10:09 ^7heo: I’m still writing some documentation (not exactly a technical documentation, more like a manager report) and it’s insanely boring… and it’s still so hot there :/ 2016-07-27 19:11:59 <^7heo> jirutka: ncopa aggreed with 118. Do you have a minute to merge? 2016-07-27 19:12:06 <^7heo> jirutka: https://github.com/alpinelinux/aports/pull/118 2016-07-27 19:12:47 <^7heo> jirutka: and yeah communicating with humans is really annoying. 2016-07-27 19:12:49 <^7heo> jirutka: :) 2016-07-27 20:02:26 <^7heo> where are the build server statuses again? 2016-07-27 20:29:52 ^7heo: http://build.alpinelinux.org/ 2016-07-27 20:30:51 <^7heo> thanks jirutka 2016-07-27 20:31:29 uh, already 22.30… doorman will be mad… 2016-07-27 20:32:04 if I will not show up till one hour, then (s)he killed me 2016-07-27 20:36:09 <^7heo> fortunately there's no doorman here. 2016-07-27 20:36:13 <^7heo> I can basically sleep here. 2016-07-27 21:29:56 ^7heo: you managed to get it fixed? Congratulations. :) 2016-07-27 21:30:10 (never underestimate the power of pitchforks, tar and feathers) 2016-07-27 21:35:22 <^7heo> skarnet: yep 2016-07-27 21:35:29 <^7heo> skarnet: ;) 2016-07-28 07:47:40 <^7heo> concourse is a pain to package, ffs. 2016-07-28 09:10:14 apkbuild-cpan is no longer working with new perl shipped 2016-07-28 09:10:18 5.24 2016-07-28 09:11:43 Experimental keys on scalar is now forbidden at /usr/bin/apkbuild-cpan line 141. 2016-07-28 09:18:46 ncopa, i don't have push w access to abuild repo. Can you please review and apply this patch? 2016-07-28 09:18:46 http://sprunge.us/LeRZ 2016-07-28 09:19:00 it fixes th apkbuild-cpan error above mentioned 2016-07-28 09:20:12 <^7heo> can someone have a look at the new gogs I made? I judt pushed the latest version; te WIP tag isn'tneeded anymore. 2016-07-28 09:20:18 <^7heo> clandmeter: ^ 2016-07-28 09:25:34 ^7heo: hi 2016-07-28 09:25:39 where should i look? 2016-07-28 09:30:40 <^7heo> clandmeter: the new APKBUILD should build fine 2016-07-28 09:30:47 <^7heo> the output should be consistent and reproducible 2016-07-28 09:31:02 <^7heo> clandmeter: just a review; then a merge, I guess, if it's all fine with you? 2016-07-28 09:38:00 <^7heo> clandmeter: imho it's good now. 2016-07-28 09:45:23 ^7heo: where is it located? 2016-07-28 09:46:38 <^7heo> clandmeter: sorry, I was so focused on work that I forgot that you'd not look directly in the GH PRs 2016-07-28 09:47:15 <^7heo> clandmeter: https://github.com/alpinelinux/aports/pull/175 2016-07-28 09:47:32 <^7heo> clandmeter: if nothing else, you can remove the WIP label. 2016-07-28 09:49:30 ^7heo: should i see something new? 2016-07-28 09:49:54 <^7heo> clandmeter: well yes. 2016-07-28 09:50:04 <^7heo> clandmeter: It's now using glide. 2016-07-28 09:50:37 the link you gave me is 22 days old commit 2016-07-28 09:51:06 <^7heo> clandmeter: no, it's a recent one. It was originally pushed 22 days ago, yes. 2016-07-28 09:51:15 oh ok 2016-07-28 09:51:25 <^7heo> clandmeter: but since AuthorDate != CommitDate... 2016-07-28 09:51:31 <^7heo> AuthorDate: Wed Jul 6 21:53:52 2016 +0200 2016-07-28 09:51:34 <^7heo> CommitDate: Thu Jul 28 11:31:48 2016 +0200 2016-07-28 09:53:38 <^7heo> clandmeter: I'm not sure if the version hashes are doing anything tho. 2016-07-28 09:55:48 <^7heo> it looks like the lock file isn't responsible for this 2016-07-28 10:04:37 ^7heo: i never used glide, so i cannot really comment on it. 2016-07-28 10:04:57 <^7heo> clandmeter: yeah no, on the rest. 2016-07-28 10:05:01 if you are sure the src is reproducable, then its fine by me. 2016-07-28 10:05:11 <^7heo> clandmeter: not sure yet; making sure of it now. 2016-07-28 10:05:24 <^7heo> clandmeter: it looks that the glide.lock file is useless. 2016-07-28 10:05:33 <^7heo> clandmeter: and that one has to put the hashes in the yaml file. 2016-07-28 10:05:45 manual? 2016-07-28 10:06:23 <^7heo> are you asking if I do changes manually, if there is a manual, or? 2016-07-28 10:06:39 <^7heo> because if it's the *doc* you're after, it's not good enough 2016-07-28 10:06:50 no i want to know how you use it. 2016-07-28 10:06:56 how to generate the files 2016-07-28 10:07:11 <^7heo> which files? the glide.* files? 2016-07-28 10:07:24 <^7heo> if so: glide init 2016-07-28 10:07:28 <^7heo> or glide create 2016-07-28 10:07:32 <^7heo> I don't remember which one. 2016-07-28 10:08:32 ok so you donwload the projects release tarbal 2016-07-28 10:08:47 enter it and run some glide cmd that will generate the files? 2016-07-28 10:08:55 <^7heo> almost. 2016-07-28 10:09:01 <^7heo> 1. dl tgz, extract 2016-07-28 10:09:06 <^7heo> 2. cd 2016-07-28 10:09:17 <^7heo> 3. COPY the glide.yaml file from the $startdir 2016-07-28 10:09:27 <^7heo> 4. glide update 2016-07-28 10:09:29 <^7heo> 5. go build 2016-07-28 10:09:54 <^7heo> from what I got so far, glide.lock is temporary and created by glide update and therefore useless in our case. 2016-07-28 10:10:57 but the hashes are not in the yml file right? 2016-07-28 10:11:07 so how does it know which to fetch? 2016-07-28 10:12:01 <^7heo> wait, I'm asking this on the gitter.im chat. 2016-07-28 10:12:14 <^7heo> "glide.lock should be committed to the repo yes. glide init generates glide.yaml from your source code. glide get updates glide.yaml. glide update generates glide.lock from glide.yaml and implicitly runs glide install. glide install creates /vendor from glide.lock." 2016-07-28 10:12:33 <^7heo> so it turns out that: 2016-07-28 10:12:49 <^7heo> 1. glide.lock wasn't used because of me using `glide update` 2016-07-28 10:12:59 <^7heo> 2. I should probably use `glide install` instead. 2016-07-28 10:13:31 ^7heo: are any other dists using glide? 2016-07-28 10:15:17 <^7heo> no idea. How does that matter? 2016-07-28 10:16:14 it matters that users just like us have done research on this topic and made a choice what to use. 2016-07-28 10:17:19 <^7heo> there is a choice when there are alternatives. 2016-07-28 10:17:26 <^7heo> Find one and I'll search for other users. 2016-07-28 10:17:32 <^7heo> I didn't find any alternative to glide so far. 2016-07-28 10:17:51 godep? 2016-07-28 10:18:12 godep helps build packages reproducibly by fixing their dependencies. 2016-07-28 10:18:51 <^7heo> yeah 2016-07-28 10:18:55 <^7heo> I didn't know of it. 2016-07-28 10:19:11 ive seen it before because its in aports 2016-07-28 10:19:15 but never used it. 2016-07-28 10:19:24 <^7heo> https://github.com/uber/tchannel-go/commit/200e957b4c1f2c2ae6cc66e9783a097fc6f49b31 2016-07-28 10:19:28 <^7heo> found that. 2016-07-28 10:19:32 and im not saying its better or worse 2016-07-28 10:20:37 <^7heo> yeah no no right 2016-07-28 10:20:40 <^7heo> I gotcha 2016-07-28 10:20:43 <^7heo> https://dzone.com/articles/glide-sea-go-package-managers 2016-07-28 10:20:46 <^7heo> more alternatives. 2016-07-28 10:21:01 <^7heo> okay, so with godep, I find much more results than with just glide. 2016-07-28 10:25:06 <^7heo> honestly, glide isn't to hard to use, once you know what does what. 2016-07-28 10:33:51 i was looking at gentoo 2016-07-28 10:33:58 they have few eclasses 2016-07-28 10:34:12 you can choose snapshot or just go get 2016-07-28 10:35:20 <^7heo> okay. 2016-07-28 10:35:29 just go with glide 2016-07-28 10:35:30 <^7heo> I think I have found a way to work with glide. 2016-07-28 10:35:33 try it and see what it brings 2016-07-28 10:35:35 <^7heo> and reliably. 2016-07-28 10:35:40 <^7heo> yeah. 2016-07-28 10:35:52 <^7heo> We might want to write some doc' about it. 2016-07-28 10:35:58 <^7heo> where would that go? 2016-07-28 10:36:17 we only have the wiki. 2016-07-28 10:36:34 <^7heo> no support for git versionned md right? 2016-07-28 10:36:56 but you could also write a template for go packages, if the procedure is simliar for other go apps. 2016-07-28 10:37:38 <^7heo> it is. 2016-07-28 10:37:47 <^7heo> how would one write such a template? 2016-07-28 10:38:37 newapkbuild 2016-07-28 10:38:47 its probably part of abuild 2016-07-28 10:39:01 and should have templates for other pkg types 2016-07-28 10:39:17 <^7heo> nah but, for instance 2016-07-28 10:39:23 <^7heo> when you create a glide thing 2016-07-28 10:39:38 <^7heo> you need to run glide update IN the APKBUILD, and then fail at the end of the build() function 2016-07-28 10:39:54 <^7heo> to be able to grab the created glide.yaml and glide.lock files from the $srcdir 2016-07-28 10:40:03 <^7heo> or rather, from the $builddir 2016-07-28 10:40:09 <^7heo> and THEN 2016-07-28 10:40:28 <^7heo> you can use those files and replace glide update with glide install 2016-07-28 10:40:37 <^7heo> now; how would I ever put that as a template? 2016-07-28 10:41:04 you can define your own functions in apkbuild 2016-07-28 10:41:32 <^7heo> hmm. 2016-07-28 10:41:50 <^7heo> Not sure exactly how to do that 2016-07-28 10:41:51 <^7heo> but okay. 2016-07-28 10:42:00 just like my snapshot function 2016-07-28 10:42:03 <^7heo> for now, gogs is pushed to the latest version I made. 2016-07-28 10:42:06 <^7heo> it should pass the tests 2016-07-28 10:42:08 its just a shell function 2016-07-28 10:42:10 <^7heo> and all is pinned. 2016-07-28 10:42:32 <^7heo> clandmeter: sure, but your snapshot function is overriding the internal one 2016-07-28 10:42:35 <^7heo> isn't it? 2016-07-28 10:42:52 any function in your apkbuild will overide abuild ones 2016-07-28 10:43:07 you can also create your own build function 2016-07-28 10:44:18 the advantage of having the function in the apkbuild is that ppl know what is happening (comprarred to eclasses where nobody knows that its doing) 2016-07-28 10:44:27 <^7heo> yeah no but I really like that. 2016-07-28 10:44:30 <^7heo> not complaining. 2016-07-28 10:44:40 <^7heo> just asking to ensure what I know 2016-07-28 10:45:08 <^7heo> now 2016-07-28 10:45:10 but for now, just make your apkbuild work, and write your sets on the wiki 2016-07-28 10:45:13 <^7heo> https://github.com/alpinelinux/aports/pull/175 is reproducible. 2016-07-28 10:45:23 then later we can create a template for it. 2016-07-28 10:45:24 <^7heo> so there's that. 2016-07-28 10:45:32 <^7heo> maybe we can merge? 2016-07-28 10:45:51 <^7heo> it's better than before. 2016-07-28 10:45:53 <^7heo> much better. 2016-07-28 10:46:30 why didnt you like that snapshot function? 2016-07-28 10:46:48 because i still dont see why this would be so much better. 2016-07-28 10:47:29 <^7heo> clandmeter: because afaik the snapshot function relies on ourselves hosting the tarballs. 2016-07-28 10:47:43 <^7heo> clandmeter: s/function/workflow. 2016-07-28 10:47:49 <^7heo> / 2016-07-28 10:50:38 your pr is weird, when you push an updated version the timestamp doesnt change. 2016-07-28 10:50:54 i remember when i force push you can see that. 2016-07-28 10:58:14 ^7heo: can you format-patch your commit and sprunge it? im getting pink unicorns 2016-07-28 11:16:59 <^7heo> clandmeter: what? 2016-07-28 11:17:54 <^7heo> clandmeter: http://ix.io/18gx 2016-07-28 11:18:09 <^7heo> (the 'what?' was related to pink unicorns) 2016-07-28 11:19:16 <^7heo> clandmeter: where do, on the wiki, the information about a specific toolchain/lang go; related to the APKBUILD/abuild use? 2016-07-28 11:19:40 <^7heo> clandmeter: I'm checking https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package but I see nothing that is toolchain/lang related. 2016-07-28 11:35:54 <^7heo> jirutka: moin 2016-07-28 11:35:56 <^7heo> clandmeter: ping? 2016-07-28 12:00:58 ^7heo: pong 2016-07-28 12:01:53 <^7heo> jirutka: are you doing MITM now? 2016-07-28 12:02:04 ^7heo: wat? 2016-07-28 12:02:26 <^7heo> jirutka: I pinged clandmeter and you answer... 2016-07-28 12:02:31 <^7heo> jirutka: just saying. 2016-07-28 12:02:42 ^7heo: ah, I overlooked it XD 2016-07-28 12:02:58 ^7heo: but what is a common answer to moin? 2016-07-28 12:03:34 <^7heo> jirutka: moin 2016-07-28 12:04:13 omg Docker users are so idiots 2016-07-28 12:04:31 like how to install apt-something package on Alpine… WTF?! 2016-07-28 12:05:43 I’m occasionally answering Alpine related questions on StackOverflow… 2016-07-28 12:06:43 <^7heo> jirutka: yeah well, automagic doesn't bring skilled people in. 2016-07-28 12:06:54 <^7heo> jirutka: and docker is the essence of automagic. 2016-07-28 12:07:17 ^7heo: no, docker is essence of shit… 2016-07-28 12:07:36 <^7heo> where did you get that automagic != shit? 2016-07-28 12:07:44 ^7heo: good point 2016-07-28 12:07:46 <^7heo> ;) 2016-07-28 12:07:57 <^7heo> also, apache is shit. 2016-07-28 12:08:01 <^7heo> and PHP too. 2016-07-28 12:08:04 yes 2016-07-28 12:08:07 <^7heo> so, apache + PHP in docker... 2016-07-28 12:08:20 <^7heo> it's killing me slowly, with its fingers... 2016-07-28 12:08:49 poor people who don’t know anything but Apache web server… 2016-07-28 12:08:52 <^7heo> Strumming my pain with its bugs... 2016-07-28 12:09:05 <^7heo> jirutka: I gotta test against it unfortunately. 2016-07-28 12:09:21 <^7heo> jirutka: and it'd be great if I could just have a throwable env for it. 2016-07-28 12:09:41 <^7heo> jirutka: care to merge 175? 2016-07-28 12:09:51 <^7heo> jirutka: I finally got a way to pin down go deps. 2016-07-28 12:10:23 you mean something like lxc-start-ephemeral ? 2016-07-28 12:11:35 huh, what `go fix` do? 2016-07-28 12:11:44 <^7heo> fixes da imports 2016-07-28 12:11:51 <^7heo> automagic ftw. 2016-07-28 12:12:03 <^7heo> maybe we should remove that and rely on patches instead... 2016-07-28 12:12:18 <^7heo> I mean, I was hesitating about that one. 2016-07-28 12:12:54 <^7heo> jirutka: do you think it makes more sense to remove it and use patches? 2016-07-28 12:13:01 fixes imports? like replacing arbitrary URLs that may not exist in few months with something more persistent…? 2016-07-28 12:13:12 eh, of course not, what I was thinking 2016-07-28 12:13:33 <^7heo> no, replacing arbitrary URLs that may not exist in few months by other arbitrary URLs that may not exist in few months. 2016-07-28 12:14:15 I dunno, but it just broken GitHub… literally… reading this patch and suddenly HTPT 500 2016-07-28 12:14:16 HTTP 2016-07-28 12:14:28 and angry unicorn 2016-07-28 12:14:42 <^7heo> so, a job for patches, ideally; but the problem with using patches would be: a package could stop building all of a sudden because a URL changed. 2016-07-28 12:15:01 really, what exactly does go fix do? 2016-07-28 12:15:15 I donjt know it so hard to say if you should use patches instead 2016-07-28 12:15:34 jirutka https://golang.org/cmd/fix/ 2016-07-28 12:16:00 aha 2016-07-28 12:16:49 <^7heo> jirutka: related to your HTTP 500: http://asset-2.soupcdn.com/asset/16116/8670_2417_520.gif 2016-07-28 12:17:00 XD 2016-07-28 12:17:21 <^7heo> without further adue, I give you the fuckyounicorn. 2016-07-28 12:17:44 where did you get glide.yml and glide.lock for gogs? 2016-07-28 12:17:54 generated by glide tool from gogs sources? 2016-07-28 12:18:07 <^7heo> http://stackoverflow.com/questions/27867242/running-apache-in-docker 2016-07-28 12:18:13 <^7heo> "This is a classic docker issue. The process you start must execute in the foreground, otherwise the container simply stops. 2016-07-28 12:18:16 <^7heo> Ah. 2016-07-28 12:18:19 <^7heo> So that is who. 2016-07-28 12:18:28 <^7heo> s/o\./y./ 2016-07-28 12:18:40 <^7heo> jirutka: indeed, generated. 2016-07-28 12:19:13 <^7heo> jirutka: you kinda have to replace 'glide install' by 'glide create' 2016-07-28 12:19:25 <^7heo> then 'glide create' by 'glide update' 2016-07-28 12:19:37 <^7heo> then return 1 after the go build 2016-07-28 12:19:42 <^7heo> then grab the files from the $buildir 2016-07-28 12:19:56 <^7heo> s/ld/ldd/ 2016-07-28 12:20:05 <^7heo> then commit them 2016-07-28 12:20:09 <^7heo> then you can use glide install. 2016-07-28 12:20:13 <^7heo> it's a little painful to do. 2016-07-28 12:20:16 okay 2016-07-28 12:20:39 it may be helpful to add a short comment to the apkbuild how to generate these files 2016-07-28 12:21:05 at least something like “these files are generated by glide create” 2016-07-28 12:22:01 <^7heo> jirutka: nah I'd like to write a doc' about that instead. 2016-07-28 12:22:10 <^7heo> jirutka: and later, delete the doc and implement that in abuild templates. 2016-07-28 12:24:42 <^7heo> the httpd package isn't ensuring that /run/apache2/httpd.pid can exist. 2016-07-28 12:24:51 <^7heo> s/httpd/apache2/ 2016-07-28 12:24:55 well, then add a link to that docs (preferably on alpine wiki) 2016-07-28 12:24:57 <^7heo> therefore, can't start httpd. 2016-07-28 12:25:05 <^7heo> jirutka: sure, but where in the wiki? 2016-07-28 12:25:16 <^7heo> 13:19 < ^7heo> clandmeter: where do, on the wiki, the information about a specific toolchain/lang go; related to the APKBUILD/abuild use? 2016-07-28 12:25:19 <^7heo> 13:19 < ^7heo> clandmeter: I'm checking https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package but I see nothing that is toolchain/lang related. 2016-07-28 12:27:26 ^7heo: it seems that you’re first here :P 2016-07-28 12:28:25 maybe into https://wiki.alpinelinux.org/wiki/APKBUILD_examples 2016-07-28 12:28:42 yeah, there are Application specific examples 2016-07-28 12:29:14 many of them also outdated; I should find some time and improve documentation :( 2016-07-28 12:29:18 <^7heo> jirutka: https://github.com/alpinelinux/aports/pull/183 2016-07-28 12:29:30 <^7heo> jirutka: is there a better way to ensure that a directory is present after install? 2016-07-28 12:30:16 <^7heo> jirutka: damn, forgot to pump the rel 2016-07-28 12:30:22 <^7heo> s/p/b/ 2016-07-28 12:39:51 this is totally wrong, /run is tmpfs 2016-07-28 12:40:03 so it’s wiped after each restart 2016-07-28 12:40:43 this should be handled in runscript, using helper function checkpath 2016-07-28 12:41:00 <^7heo> ok, I suspected so. 2016-07-28 12:44:11 <^7heo> jirutka: weird 2016-07-28 12:44:18 <^7heo> checkpath --directory $(dirname $PIDFILE) is already in the file. 2016-07-28 12:44:24 <^7heo> in start 2016-07-28 12:44:30 <^7heo> oooh, I KNOW WHY. 2016-07-28 12:44:33 <^7heo> stupid me. 2016-07-28 12:44:34 why…? 2016-07-28 12:44:45 <^7heo> the docker image doesn't have the init system. 2016-07-28 12:44:54 <^7heo> people won't start binaries with openrc-run 2016-07-28 12:44:56 yeah… ’cause it’s docker 2016-07-28 12:44:59 <^7heo> yeah. 2016-07-28 12:46:41 because openrc wasn't made for docker, since it comes with a whole "start the real machine services" policy. 2016-07-28 12:47:49 that's not on docker, that's on openrc. I know you like to blame Docker, but there are enough good reasons not to like it, you don't need to blame it when it's not responsible. :) 2016-07-28 12:48:05 <^7heo> skarnet: true. 2016-07-28 12:48:13 <^7heo> skarnet: how should we handle that tho? 2016-07-28 12:48:28 <^7heo> skarnet: we can't expect people to find that /run/apache2 is missing. 2016-07-28 12:48:33 <^7heo> s/people/docker users/ 2016-07-28 12:49:00 docker users are not people :P 2016-07-28 12:49:22 I don't know exactly what you're trying to do, I didn't read all the context. 2016-07-28 12:49:23 and this is not Alpine’s fault 2016-07-28 12:50:04 maybe more an Apache’s fault, but not sure about it 2016-07-28 12:50:23 <^7heo> skarnet: essentially, a directory's missing in /run 2016-07-28 12:50:30 <^7heo> skarnet: preventing apache2 from starting 2016-07-28 12:50:39 <^7heo> skarnet: and ofc apache2 doesn't say anything. 2016-07-28 12:50:45 <^7heo> skarnet: took me minutes to find it. 2016-07-28 12:50:54 <^7heo> skarnet: it could take hours for an average docker user to find that. 2016-07-28 12:51:12 mkdir -p /run/apache2 in an init script that will also be executed on Docker images? 2016-07-28 12:51:26 <^7heo> skarnet: there isn't any init script executed on docker images. 2016-07-28 12:51:43 <^7heo> there isn't a proper init system anyway in those. 2016-07-28 12:51:52 <^7heo> ncopa: what do you think of that, how to fix it? 2016-07-28 12:51:54 well that's on the people that package the images. 2016-07-28 12:52:00 <^7heo> skarnet: meh 2016-07-28 12:52:04 It is. 2016-07-28 12:52:17 <^7heo> I mean, I get your point. 2016-07-28 12:52:20 Images that use s6, and there are quite a few, work well. :P 2016-07-28 12:52:30 <^7heo> But it's kinda crappy that we package a software that doesn't always start when we invoke it. 2016-07-28 12:52:43 <^7heo> and that relies on you looking at the log and reading it to find out why. 2016-07-28 12:52:54 ^7heo: not true, apache2 starts when you properly invoke it, using runscript 2016-07-28 12:53:00 <^7heo> shouldn't we use s6 instead of openrc-run? 2016-07-28 12:53:12 ^7heo: it’s not our fault that apache2 requires some directory to exists when started manually 2016-07-28 12:53:16 <^7heo> jirutka: runscript has been replaced by openrc-run right? 2016-07-28 12:53:22 <^7heo> jirutka: true. 2016-07-28 12:53:24 not having a proper init system for docker images is an issue. 2016-07-28 12:53:31 <^7heo> skarnet: yes it is. 2016-07-28 12:53:35 ^7heo: definitely not now, s6-rc is not ready for general usage yet 2016-07-28 12:53:42 <^7heo> ok? 2016-07-28 12:53:44 <^7heo> why not? 2016-07-28 12:53:57 <^7heo> (genuine question, never used it) 2016-07-28 12:53:57 how is that that we don’t have such problem with LXC… :P 2016-07-28 12:54:07 <^7heo> jirutka: no idea. 2016-07-28 12:54:14 there’s no problem with using OpenRC in LXC container… or any other container… jsut with Docker… 2016-07-28 12:54:14 jirutka: hey, I didn't even mention s6-rc. 2016-07-28 12:54:21 <^7heo> I did. 2016-07-28 12:54:26 btw https://github.com/Yelp/dumb-init 2016-07-28 12:54:51 <^7heo> myeah. 2016-07-28 12:54:59 <^7heo> well anyway, that's too much for now. 2016-07-28 12:55:03 <^7heo> my image works, so all good 2016-07-28 12:55:13 yay for requiring python for your init :P 2016-07-28 12:55:44 ^7heo: s6-rc doesn’t have an “UI”… I mean some sane way how to describe services 2016-07-28 12:56:07 skarnet: it’s written in C, they use Python for tests 2016-07-28 12:56:09 <^7heo> yeah no, dumb-init isn't an option. 2016-07-28 12:56:14 <^7heo> ah? 2016-07-28 12:56:14 sane is in the eye of the beholder! 2016-07-28 12:56:39 skarnet: because writing tests in C sucks… 2016-07-28 12:56:49 writing tests sucks, no matter the language 2016-07-28 12:56:56 skarnet: not exactly true 2016-07-28 12:56:59 <^7heo> myeah. but they're needed. 2016-07-28 12:57:09 <^7heo> nah he's right, writing tests is never fun. 2016-07-28 12:57:20 <^7heo> it's 99% boilerplate and 1% assertions 2016-07-28 12:57:25 <^7heo> so yeah, not fnu. 2016-07-28 12:57:29 <^7heo> s/nu/un/ 2016-07-28 12:57:29 It may be fun if you have good testing framework… the problem is that most of them are just crap 2016-07-28 12:57:41 anyway, if "dumb-init" requires tests, then it's not dumb enough. 2016-07-28 12:58:12 if you need 99 % of boilerplate, then it’s an indicator that your code sucks… not always truth, some cases are hard to test from principle, but it’s an indicator 2016-07-28 12:58:26 skarnet: I hope that you’re not serious now 2016-07-28 12:58:51 skarnet: but I don’t expect from hard-code C programmer to understand the value of tests… so… nevermind 2016-07-28 12:59:22 *hard-code 2016-07-28 12:59:25 shit 2016-07-28 12:59:28 I mean hard-core 2016-07-28 13:00:00 I am serious. If you claim to write a "dumb init", then you should be able to get it right without tests. Tests are important when you're doing smart things, but would you require tests for a Hello World package? 2016-07-28 13:00:12 no, you’re wrong 2016-07-28 13:00:22 and I’m leaving now, because I really should do some work today 2016-07-28 13:01:01 I am fully expecting jirutka to provide us with a complete test suite for Hello World 2016-07-28 13:01:05 when he comes back 2016-07-28 13:01:12 He can use Python if he wants. 2016-07-28 13:01:37 <^7heo> skarnet: well, I agree with you about the 'dumb' part, but tests never harm. 2016-07-28 13:02:06 They do when they pull in heavy dependencies. 2016-07-28 13:02:10 <^7heo> skarnet: I just wish it was using dumb tests instead of two thirds of the code base in complexity just for testing. 2016-07-28 13:04:37 there is also a tini 2016-07-28 13:05:32 there is also s6-overlay 2016-07-28 13:05:49 tini is deisnged for docker like setups 2016-07-28 13:06:09 it will only forward signals to the service 2016-07-28 13:06:16 and reap zombies 2016-07-28 13:06:40 oh, great, did it also invent hot water? 2016-07-28 13:07:27 i think it already do too much 2016-07-28 13:08:56 fun fact: one of the binaries in execline, "trap", does exactly that: forward signals to a process, and reap zombies. You can also customize what to do on receipt of a signal. I'm quite willing to bet "tini" is bigger than "trap". 2016-07-28 13:09:31 i suppose trap is a better tool for the job then 2016-07-28 13:09:52 what package provides it? 2016-07-28 13:10:22 execline 2016-07-28 13:10:30 ls -l /bin/trap 2016-07-28 13:11:15 My point is not "look at how awesome I am" (although I am, indeed, awesome, and you should look at me). My point is: don't be fooled into thinking those "tiny init" initiatives do anything magic. Practically all of them are half-assed, broken reimplementations of the same mistakes, over and over again. 2016-07-28 13:12:03 yeah, i get that point 2016-07-28 13:12:10 and tini is 18k 2016-07-28 13:12:13 trap is half the size 2016-07-28 13:12:27 That was easy. 2016-07-28 13:12:41 but 2016-07-28 13:12:48 0x0000000000000001 (NEEDED) Shared library: [libexecline.so.2.1] 2016-07-28 13:12:49 0x0000000000000001 (NEEDED) Shared library: [libskarnet.so.2.3] 2016-07-28 13:13:01 oh, of course you should always compare static binaries. 2016-07-28 13:14:17 on x86_64, a static trap binary with musl is is 26k. 2016-07-28 13:14:23 -is 2016-07-28 13:14:46 but again, it was just an example. I am not suggesting using trap as a process 1 for Docker. 2016-07-28 13:15:17 trap is 34416 2016-07-28 13:15:24 strip it. 2016-07-28 13:16:06 that is stripped 2016-07-28 13:16:20 wrong compile options then. 2016-07-28 13:16:40 might be the additional features... 2016-07-28 13:16:48 -rwxr-xr-x 1 ska users 25984 Jul 28 13:14 trap 2016-07-28 13:17:04 anyway 2016-07-28 13:17:29 or its just the help text :) 2016-07-28 13:17:39 what I am suggesting is not to invest any more time and energy into this than is strictly necessary to make apache (and maybe other things) work with duct tape 2016-07-28 13:18:20 and to revisit the whole init thing later on when you have time - for instance next year when I'll be available to help 2016-07-28 13:18:35 well, it might be an idea to have a zombie reaper in docker 2016-07-28 13:19:20 because the service you want to run will effectively be pid 1 2016-07-28 13:19:27 the problem with Docker isn't that there's no zombie reaper, the problem is that false and wrong idea that only 1 process should run inside a container. 2016-07-28 13:19:35 yeah, THAT is the problem 2016-07-28 13:19:44 *nod* 2016-07-28 13:19:49 the service you want to run should not be pid 1, end of story 2016-07-28 13:20:16 and I'm not a Docker hater as some of the other chan dweller, but I *will* fight Docker on this 2016-07-28 13:21:05 the idea with docker is that you run only 1 single process in its own container 2016-07-28 13:21:23 hiding all other pids on the same machine 2016-07-28 13:21:30 yeah, and that's a braindead, broken, and wrong idea, and I have a few spare butcher hooks for the people who came up with it 2016-07-28 13:21:46 a service is not equal to a process. 2016-07-28 13:22:09 a service is a dynamic set of processes, at least one of which is long-lived. That's all. 2016-07-28 13:22:39 i think the idea came from "how much can we remove" 2016-07-28 13:22:40 All the problems with Docker and inits come from this assumption that a service is one process. 2016-07-28 13:23:01 i thought they were trying to use control groups to "work around" their single process stuff 2016-07-28 13:23:25 "how much can we remove from standard Unix while using mutant Linux features to work around our braindead design" 2016-07-28 13:25:53 There is a way to make containers work under the current design of Docker: run a complete init system in the container, which takes care of multiprocess and zombies. That's perfectly reasonable, and not even bad design, but Docker has to stop pretending it's not necessary. 2016-07-28 13:27:16 i think they are aware of the problem 2016-07-28 13:28:26 That's a good first step. Now tell them to have a look at s6 ;) 2016-07-28 13:30:26 i dont think they want enforce adding another binary to every docker image 2016-07-28 13:31:11 docker images are like packages or software bundles 2016-07-28 13:31:22 so you dont need compile statically 2016-07-28 13:31:30 instead you add all deps to the docker image 2016-07-28 13:31:41 they cannot control what people put in their images 2016-07-28 13:32:03 so they are aware of the problem and decided to do nothing? 2016-07-28 13:32:15 In that case, it's indeed up to us to provide correct images 2016-07-28 13:32:28 its a tricky problem 2016-07-28 13:32:30 but yes 2016-07-28 13:32:43 the images that we provides can have it fixed 2016-07-28 13:33:00 which is actually a good point 2016-07-28 13:33:06 we can do it in the alpine image 2016-07-28 13:33:54 but i'm not sure we can enforce that it is executed first 2016-07-28 13:34:15 and yes i have talked with atleast one engineer about it 2016-07-28 13:34:31 this was one of the first things i wanted to discuss :) 2016-07-28 13:36:01 again, if you can fix it with duct tape so it holds for 6 months, I volunteer to help with it afterwards 2016-07-28 13:36:42 ideally unifying the "real machine" image and the "virtual machine" image as much as possible 2016-07-28 13:36:59 for people who gets bitten, the current duct tape is running a service manager or tini 2016-07-28 13:37:11 random docker question since i'm here about alpine, is there an armhf docker image? my quick search didn't bite one 2016-07-28 13:37:20 err find 2016-07-28 13:37:25 pre coffee me is not coherent 2016-07-28 13:37:39 mitchty: i dont know really. i am not aware of any arm alpine image 2016-07-28 13:39:19 ncopa: ok, was hoping i didn't have to try to build one but it would be handy 2016-07-28 13:39:38 skarnet: i have heard some interesting ideas on how to solve it 2016-07-28 13:40:05 which would be execute the init form the host, before entering the container 2016-07-28 13:40:28 i also saw something similar for qemu emulators 2016-07-28 13:40:37 so you could run a different arch in qemu 2016-07-28 13:40:46 without needing ot have the qemu executable in the container 2016-07-28 13:46:50 it makes sense to run qemu first and unshare later, yes. But init is not qemu, and again, as long as Docker sticks to the "we only handle one process" model, a full-featured init (that doesn't mean "big") *is* necessary to have inside the container. 2016-07-28 13:47:54 There's no way around it: you gotta have something to do your guest process management. If the container manager won't do it, then you have to run something inside that will do it. 2016-07-28 13:53:00 *nod* 2016-07-28 14:06:43 <^7heo> at least having the container manager to do it would yield the advantage of making it work directly with all existing images. 2016-07-28 14:06:55 <^7heo> but yeah, that would require docker to change. 2016-07-28 14:26:52 <^7heo> can we avoid using cloudflare to host the js on our website? =/ 2016-07-28 14:27:34 <^7heo> https://cdnjs.cloudflare.com/ajax/libs/chosen/1.4.2/chosen.css isn't really something we should rely one. 2016-07-28 14:27:37 <^7heo> on( 2016-07-28 14:27:39 <^7heo> rafuck 2016-07-28 14:31:34 where is it used from? 2016-07-28 14:56:24 <^7heo> ncopa: packages. 2016-07-28 14:57:34 <^7heo> also, using a combination of apk and pip to maintain python packages isn't ideal. 2016-07-28 14:57:51 <^7heo> the apks should use pip to do anything python, at least. 2016-07-28 14:58:01 <^7heo> because for now, we have different versions in pip and apk 2016-07-28 14:58:13 <^7heo> and vendoring is awful 2016-07-28 15:03:48 with ruby and gems we simply killed all ruby-* packages and let user run gem install instead 2016-07-28 15:03:59 not sure we can do that with python apps though 2016-07-28 15:04:59 <^7heo> ncopa: xen has (a) python package(s) 2016-07-28 15:08:07 <^7heo> (for instance) 2016-07-28 15:08:15 many other C libs/apps has python bindings 2016-07-28 15:08:24 <^7heo> and if you do a pip list | xargs pip install --upgrade 2016-07-28 15:08:29 <^7heo> you upgrade that TOO. 2016-07-28 15:08:40 <^7heo> maybe we should put that somewhere else? 2016-07-28 15:08:58 i dont know 2016-07-28 15:09:04 <^7heo> also 2016-07-28 15:09:06 <^7heo> I dunno for you 2016-07-28 15:09:11 <^7heo> but for me, on edge, ipython segfaults. 2016-07-28 15:09:39 but i noticed that fedora recently added some support for provides of python libs 2016-07-28 15:10:01 i think that was so dnl would be happy if you had pip installed a dep 2016-07-28 15:10:22 <^7heo> yeah 2016-07-28 15:11:43 https://fedoraproject.org/wiki/Changes/Automatic_Provides_for_Python_RPM_Packages 2016-07-28 15:11:52 <^7heo> ncopa: does ipython work for you? 2016-07-28 15:11:59 i havent tried 2016-07-28 15:12:02 <^7heo> (pip install ipython) 2016-07-28 15:12:09 <^7heo> if you can try that would be really cool 2016-07-28 15:12:20 <^7heo> because I'm missing /usr/lib/python2.7/site-packages/prompt_toolkit/terminal/fcntl* 2016-07-28 15:12:23 <^7heo> (5 files) 2016-07-28 15:12:29 <^7heo> and I wonder what is supposed to provide them. 2016-07-28 22:03:41 <^7heo> so 2016-07-28 22:05:38 <^7heo> what about https://github.com/alpinelinux/aports/pull/175 2016-07-28 22:05:39 <^7heo> ? 2016-07-28 22:05:42 <^7heo> jirutka: ^ 2016-07-28 22:05:45 <^7heo> clandmeter: ^ 2016-07-28 22:06:29 <^7heo> clandmeter: http://ix.io/18gx as you requested, originally posted at 13:17 CEST. 2016-07-28 22:08:00 not now, currently trying to set up ZNC 2016-07-28 22:08:10 <^7heo> meh 2016-07-28 22:08:16 <^7heo> clandmeter: agreed to that AFAIR 2016-07-28 23:17:41 <^7heo> damn 2016-07-28 23:17:45 <^7heo> ipython is broken 2016-07-28 23:17:48 <^7heo> but more importantly 2016-07-28 23:17:55 <^7heo> ipython3 is python2 =/ 2016-07-28 23:17:57 <^7heo> wtf. 2016-07-28 23:18:09 <^7heo> I could blame that on alpine, but this is actually installed by pip 2016-07-28 23:19:24 <^7heo> ipython is a pile of crap. 2016-07-29 00:08:30 <^7heo> jirutka: http://ix.io/18rP 2016-07-29 00:08:38 <^7heo> jirutka: maybe here you can actually read me live. 2016-07-29 00:09:40 ha, great, it even sent away message 2016-07-29 00:09:52 <^7heo> yeah 2016-07-29 00:10:04 <^7heo> but did you get that I couldn't stop sending messages that I sent in the past? ;) 2016-07-29 00:10:22 what do you mean? 2016-07-29 00:10:28 <^7heo> I flooded you basically 2016-07-29 00:10:33 <^7heo> because your instructions were unclear. 2016-07-29 00:10:43 <^7heo> so the IRCd started to buffer and delay 2016-07-29 00:10:49 aha XD 2016-07-29 00:11:10 <^7heo> so yeah 2016-07-29 00:11:15 at least I didn’t caused endless recursive loop 2016-07-29 00:11:18 <^7heo> sorry, I can't change the past. 2016-07-29 00:11:27 <^7heo> I sometimes wish I could. 2016-07-29 00:11:28 <^7heo> but I can't. 2016-07-29 00:13:14 btw just for fun… this ZNC instance is running on Alpine, inside LXC container that is running on Alpine that is running inside KVM that is running on Alpine (obviously) inside an OpenVZ container! 2016-07-29 00:13:40 <^7heo> that you don't control, right? 2016-07-29 00:13:44 because I can’t run LXC inside OpenVZ container, so… 2016-07-29 00:13:46 <^7heo> (the host) 2016-07-29 00:13:56 it’s on vpsFree.cz 2016-07-29 00:14:01 <^7heo> yeah I thought so. 2016-07-29 00:14:04 <^7heo> nice setup tho 2016-07-29 00:14:08 <^7heo> overhead all the things. 2016-07-29 00:14:11 yeah… quite insane 2016-07-29 00:14:41 actually it’s not much bigger overhead than what get from traditional hosting companies… 2016-07-29 00:14:50 <^7heo> :DDD 2016-07-29 00:15:00 <^7heo> jirutka: did you test what I wrote in /query? 2016-07-29 06:16:11 good morning 2016-07-29 06:16:33 ^7heo: that paste is an python error not an git patch 2016-07-29 08:15:05 <^7heo> clandmeter: you mean, the first 'how to reproduce' or the 'workaround' in shell? 2016-07-29 08:15:13 <^7heo> because in both cases it's shell 2016-07-29 08:15:35 <^7heo> and I won't ever give a workaround as a patch: it's a workaround, not a patch. 2016-07-29 08:15:40 <^7heo> it's not supposed to be shipped in any way. 2016-07-29 08:15:48 i asked for a git patch of your PR and you return me a python error? 2016-07-29 08:17:24 <^7heo> wow dude 2016-07-29 08:17:30 <^7heo> I know you're in NL 2016-07-29 08:17:33 <^7heo> but smoke the pot. 2016-07-29 08:17:41 <^7heo> s/smoke/stop/ 2016-07-29 08:17:50 <^7heo> I need a coffee. bbl. 2016-07-29 08:21:04 <^7heo> ok so 2016-07-29 08:21:20 <^7heo> clandmeter: I sent you the patch, via ix.io *two* times. 2016-07-29 08:21:37 <^7heo> clandmeter: then I *also* found a bug in python, that I thought was worth sharing with you and jirutka 2016-07-29 08:22:18 <^7heo> or not sure if the bug is in python, musl or else 2016-07-29 08:22:27 <^7heo> but something that could potentially have more incidences. 2016-07-29 08:23:39 <^7heo> So long story short, the patch on ix.io is maybe there, maybe not (I did some cleanup yesterday) 2016-07-29 08:24:08 <^7heo> if it is not, I will repost it once I am at work. 2016-07-29 09:04:17 <^7heo> jirutka: can you have a look at PR175? 2016-07-29 09:19:52 ^7heo: let me take you out of your fantasy. I dont wear wooden shoes; i dont have a windmill in my backyard; and i dont spoke pot. 2016-07-29 09:25:34 <^7heo> clandmeter: yet you ranted at me for providing you with all you wanted, and failing to see it... 2016-07-29 09:26:07 <^7heo> clandmeter: I removed the patch from the paste, I'll re-paste it now. 2016-07-29 09:26:09 no i wasnt, you are. I was just asking a question. 2016-07-29 09:26:23 trying to help you. 2016-07-29 09:27:51 <^7heo> clandmeter: I dunno, I'm used to 100% passive-aggressiveness when people ask stuff like: "i asked for a git patch of your PR and you return me a python error?" 2016-07-29 09:28:15 please drop the escalation, both of you, and focus on the technical issue you're having, no matter what. 2016-07-29 09:28:22 <^7heo> *especially* with the '?' at the end, which clearly states that you're questionning the person's logic, and by extent, the person's intelligence. 2016-07-29 09:28:28 It's too early for aggression on the channel. 2016-07-29 09:28:35 <^7heo> yeah I'm fine with that; but I had enough passive aggressivity so far. 2016-07-29 09:28:41 <^7heo> (not here, in my life) 2016-07-29 09:28:49 <^7heo> so I'd rather avoid it if at all possible. 2016-07-29 09:28:54 <^7heo> anyway, let's focus on work. 2016-07-29 09:29:37 <^7heo> skarnet: happy sysadmin day btw. 2016-07-29 09:29:57 heh, indeed. Happy sysadmin day everyone :) 2016-07-29 09:30:19 <^7heo> I'm not a sysadmin anymore technically, but for all the years as one: thanks. 2016-07-29 09:31:29 <^7heo> clandmeter: http://ix.io/18zU 2016-07-29 09:31:40 <^7heo> here you go. 2016-07-29 09:31:49 ^7heo: http://tpaste.us/2DPq 2016-07-29 09:32:21 <^7heo> clandmeter: and also; to ease the discussion: I have nothing personal against you. I was just reacting at something I expected to be passive-aggressivity for the aforementioned reasons. 2016-07-29 09:32:41 <^7heo> clandmeter: that one's gone. 2016-07-29 09:33:02 <^7heo> clandmeter: this isn't my offset anymore. I freed it. 2016-07-29 09:33:26 ^7heo: when did you last update this patch? 2016-07-29 09:34:05 <^7heo> clandmeter: CommitDate: Fri Jul 29 11:29:02 2016 +0200 2016-07-29 09:34:18 <^7heo> (rebase against upstream/master) 2016-07-29 09:34:26 <^7heo> clandmeter: before that, well... probably yesterday. 2016-07-29 09:34:28 <^7heo> clandmeter: why? 2016-07-29 09:34:32 why does that patch not follow that date? 2016-07-29 09:35:00 <^7heo> clandmeter: because I am doing a git commit --amend on github to discard the previous vesions of the patch? 2016-07-29 09:35:28 <^7heo> see, here? I didn't do it on purpose, but I was passive aggresive with the '?'. A little but still. 2016-07-29 09:35:32 <^7heo> So I'm sorry, I meant to write: 2016-07-29 09:35:34 <^7heo> clandmeter: because I am doing a git commit --amend on github to discard the previous vesions of the patch. 2016-07-29 09:36:11 ok, its confusing github doesnt show the pr has been updated. 2016-07-29 09:36:19 <^7heo> yeah I know. 2016-07-29 09:36:24 <^7heo> but it knows. 2016-07-29 09:36:41 and i remember it did before, so i just wonder what you do different, or what changed at gh. 2016-07-29 09:36:57 <^7heo> well 2016-07-29 09:37:14 <^7heo> I'd advocate that git itself might have changed its behavior regarding that 2016-07-29 09:37:25 <^7heo> And I would personally tend for that explanation. 2016-07-29 09:37:54 <^7heo> as in: amend used to change the commit date by default 2016-07-29 09:37:57 <^7heo> no longer does. 2016-07-29 10:01:00 <^7heo> clandmeter: thanks for the update! :) 2016-07-29 10:03:13 ^7heo: what are the steps to generate the glide files? 2016-07-29 10:03:47 and i guess for every version they need to be updated? 2016-07-29 10:05:53 <^7heo> clandmeter: you guess right. 2016-07-29 10:06:07 <^7heo> clandmeter: to generate the glide files, you need two steps, and one condition. 2016-07-29 10:06:35 <^7heo> clandmeter: the condition is to be in the $builddir (i.e. in our case src/gogs-0.9.48/) 2016-07-29 10:07:24 <^7heo> clandmeter: and the two steps are: glide init (AKA create), to get the glide.yaml; and glide update, to get the glide.lock. 2016-07-29 10:07:40 <^7heo> clandmeter: we want the former to list the dependencies, we want the later to lock them down. 2016-07-29 10:13:27 <^7heo> on build.a.o, where are the logs? 2016-07-29 10:14:03 http://build.alpinelinux.org/buildlogs/build-edge-x86_64/testing/gogs/gogs-0.9.48-r0.log 2016-07-29 10:14:31 <^7heo> BUILDlogs 2016-07-29 10:14:32 <^7heo> thanks 2016-07-29 10:14:38 <^7heo> I was trying with /logs 2016-07-29 10:15:57 <^7heo> gogs-0.9.48-r0.apk is on fr.a.o 2016-07-29 10:15:59 <^7heo> \o/ 2016-07-29 10:16:02 <^7heo> time to try it out. 2016-07-29 10:18:47 <^7heo> it's funny, gogs reports "0.9.35.0702" for the "Application Version" 2016-07-29 10:19:00 <^7heo> meh, not time to report that. 2016-07-29 10:20:03 ^7heo: is go fix still needed? 2016-07-29 10:20:13 <^7heo> clandmeter: afaik yes. 2016-07-29 10:20:19 <^7heo> clandmeter: go fix has nothing to do with dependencies. 2016-07-29 10:20:33 <^7heo> clandmeter: it is about import paths being URLs and URLs mutating all the time. 2016-07-29 10:20:56 okk 2016-07-29 10:21:10 <^7heo> clandmeter: for each import, it takes a 'potentially dead link' and if necessary rewrites it in another 'potentially dead link' 2016-07-29 10:21:19 <^7heo> AFAIK, I might be wrong, I'm no go expert. 2016-07-29 10:21:47 <^7heo> anyway, upgraded gogs to 0.9.48 on my prod server. 2016-07-29 10:21:51 <^7heo> works great. 2016-07-29 10:21:54 <^7heo> looks really good too. 2016-07-29 10:22:10 btw, you should not use the startdir like this. 2016-07-29 10:22:23 always use srcdir 2016-07-29 10:23:42 <^7heo> no. 2016-07-29 10:23:52 <^7heo> go expects the GOPATH to contain src 2016-07-29 10:23:57 <^7heo> actually, src/ 2016-07-29 10:24:27 cp "$startdir/glide.yaml" "$startdir/glide.lock" . 2016-07-29 10:24:38 that should be srcdir 2016-07-29 10:24:38 <^7heo> so, unless we want do create /testing//src/src/ 2016-07-29 10:24:54 <^7heo> we should use $startdir in the case of go. 2016-07-29 10:25:01 you are copying from apkbuild dir, but you need to copy them from srcdir. 2016-07-29 10:25:12 srcdir has files that are checksummed. 2016-07-29 10:25:22 <^7heo> clandmeter: oh, I see. 2016-07-29 10:25:33 <^7heo> clandmeter: you mean, for the cp operation, not for the GOPATH. 2016-07-29 10:25:35 so if you forget to add them to src, it will still work. 2016-07-29 10:25:48 we dont want it to work if not added to srcdir. 2016-07-29 10:25:55 <^7heo> true. 2016-07-29 10:26:06 <^7heo> Okay, I'm gonna patch that. 2016-07-29 10:26:31 also put that comment above the go build 2016-07-29 10:26:41 we try to break at 80 2016-07-29 10:27:23 ^7heo: you dont have to increment pkgrel 2016-07-29 10:27:38 <^7heo> clandmeter: really? 2016-07-29 10:27:48 <^7heo> clandmeter: because the checksums aren't gonna change or what? 2016-07-29 10:27:52 no, it wont change the outcome now. 2016-07-29 10:27:59 <^7heo> ah 2016-07-29 10:28:11 its just not right to do it like this. 2016-07-29 10:28:13 <^7heo> "we try to break at 80", what does that mean? 2016-07-29 10:28:21 clandmeter, in main we have sdl and sdl2, but only sdl_image. I've done sdl2_image. I think i can push it directly to main, but i'd like your though about that. What do you think? 2016-07-29 10:28:56 lines should not be longer then 80 chars. 2016-07-29 10:29:07 where possible of course 2016-07-29 10:29:47 <^7heo> clandmeter: yeah just got it. 2016-07-29 10:30:22 fcolista: sdl_image is a subpkg? 2016-07-29 10:30:26 no 2016-07-29 10:30:54 oh you mean sdl2_image is a new pkg? 2016-07-29 10:31:01 yes 2016-07-29 10:31:05 sure push it. 2016-07-29 10:31:20 umh 2016-07-29 10:31:30 looks the same reasoning is valid for sdl_mixer 2016-07-29 10:32:08 i guess they both dep on sdl? 2016-07-29 10:32:17 right. 2016-07-29 10:32:47 It's not very optimized, but is cleaner. 2016-07-29 10:32:50 I would prefer do that 2016-07-29 10:33:18 <^7heo> clandmeter: http://ix.io/18zU 2016-07-29 10:33:25 <^7heo> clandmeter: that's the new patch. 2016-07-29 10:34:06 <^7heo> clandmeter: the || return 1 was bringing the line to 81 chars, so I removed a space. 2016-07-29 10:36:42 ^7heo: little nitpicking, but the tabs are followed by a space. 2016-07-29 10:37:08 <^7heo> clandmeter: really? 2016-07-29 10:37:31 <^7heo> clandmeter: I didn't touch package() afaik 2016-07-29 10:37:33 package part 2016-07-29 10:38:06 <^7heo> clandmeter: yeah, to align with the previous line I guess? 2016-07-29 10:38:19 <^7heo> (the mkdir -p command) 2016-07-29 10:38:41 <^7heo> which is stupid, because a tab isn't necessarily 8 spaces. 2016-07-29 10:39:10 default in vim tabs are not 4 spaces, but you can tell it to show like it. 2016-07-29 10:39:34 <^7heo> sure. 2016-07-29 10:39:44 <^7heo> that isn't the question tho, but sure ;) 2016-07-29 10:39:46 <^7heo> ts=4 2016-07-29 10:41:05 <^7heo> clandmeter: updated http://ix.io/18zU 2016-07-29 11:32:57 ^7heo: http://tpaste.us/GB4Y 2016-07-29 11:33:05 that could be part of the template 2016-07-29 11:35:15 builddir should be up one line http://tpaste.us/2bJM 2016-07-29 11:46:32 anyone has tried to install Alpine using alpine-virt iso x86? once disk and its type selected I receive error about missing e2fsprogs, sfdisk and syslinux. I assume these packages are excluded from iso. 2016-07-29 11:47:32 http://i.imgur.com/VPrgoMp.png 2016-07-29 12:38:57 <^7heo> clandmeter: yes 2016-07-29 12:39:18 <^7heo> clandmeter: what about buildmode=pie ho? 2016-07-29 12:44:10 im not sure we always need to set it? 2016-07-29 12:45:14 <^7heo> s/ho/t&/ 2016-07-29 12:45:18 <^7heo> okay. 2016-07-29 12:45:48 <^7heo> scadu: why do you assume? 2016-07-29 12:46:00 <^7heo> scadu: did you try "apk add e2fsprogs sfdisk syslinux" ? 2016-07-29 13:09:43 ^7heo: I thought these packages should be included since alpine-setup is using them in disk installation but I might be wrong. will check when I came home then. 2016-07-29 13:10:07 <^7heo> scadu: included != installed. 2016-07-29 13:22:34 scadu: I’ve installed Alpine using alpine-virt-x86_64 2016-07-29 13:31:30 so not sure if pebkac or it is only related with x86 iso. 2016-07-29 13:31:36 ^7heo: now i understand why you choose glide, it was not your choice at all. 2016-07-29 13:33:33 <^7heo> clandmeter: ? 2016-07-29 13:33:52 gogs is already using glide 2016-07-29 13:33:55 <^7heo> ah? 2016-07-29 13:33:58 i didnt notice that :) 2016-07-29 13:34:02 <^7heo> me neither. 2016-07-29 13:34:13 <^7heo> that's weird, I didn't see a glide file in there. 2016-07-29 13:34:35 <^7heo> ph 2016-07-29 13:34:37 <^7heo> oh* 2016-07-29 13:34:39 <^7heo> weird. 2016-07-29 13:35:04 <^7heo> but wait. 2016-07-29 13:35:05 lol 2016-07-29 13:35:25 <^7heo> we don't need the glide.lock and glide.yaml keys to be versionned by us then. 2016-07-29 13:35:31 <^7heo> we can just get rid of those. 2016-07-29 13:35:56 right 2016-07-29 13:36:12 i wonder if other projects are already using it 2016-07-29 13:36:12 <^7heo> but it's not urgent. 2016-07-29 13:36:21 <^7heo> well, a couple of them 2016-07-29 13:36:33 <^7heo> I'm going to start packaging drone-ci now 2016-07-29 13:37:07 oh no, what I did… why I mentioned drone ci? 2016-07-29 13:37:33 <^7heo> jirutka: v_v 2016-07-29 13:37:38 I should stop giving tips for applications before getting a coffee 2016-07-29 13:37:41 <^7heo> jirutka: what's the problem with more software? 2016-07-29 13:37:56 I have no problem with more software, I have proelbm with more Go packages… 2016-07-29 13:37:58 <^7heo> jirutka: if it works as I expect, you'd have saved my day. 2016-07-29 13:38:00 that’s different :P 2016-07-29 13:38:12 and ruined my day XD 2016-07-29 13:38:15 <^7heo> jirutka: oh come on, *I* am the one maintaining them. 2016-07-29 13:38:24 <^7heo> jirutka: you don't have anything to do with that. 2016-07-29 13:38:36 <^7heo> jirutka: you will be able to apk add drone if you want tho, later. 2016-07-29 13:39:27 i wonder if there is a sane way to detect a go src dir 2016-07-29 13:39:50 <^7heo> clandmeter: what do you call a "go src dir"? 2016-07-29 13:40:17 the tarball coming from the project 2016-07-29 13:40:49 <^7heo> I don't really understand your question... we are hardcoding the tarball URLs... 2016-07-29 13:40:54 <^7heo> it's not hard to "guess" 2016-07-29 13:41:30 i mean, if i have a tarball, how do i know for sure its a go project. 2016-07-29 13:41:50 autotools has a configure script you can target. 2016-07-29 13:41:53 <^7heo> wtf is wrong with git now?! 2016-07-29 13:42:15 <^7heo> oh. 2016-07-29 13:42:22 <^7heo> I didn't commit concourse, and I won't. 2016-07-29 13:42:31 <^7heo> my brain is fucked, I can't make the difference between words. 2016-07-29 13:44:35 clandmeter: find . -name '*.go' ? 2016-07-29 13:44:40 <^7heo> :D 2016-07-29 13:44:52 <^7heo> yeah, or hopefully the project includes a Makefile? 2016-07-29 13:45:14 and how can you detect go from makefile? 2016-07-29 13:51:07 <^7heo> ? 2016-07-29 13:51:18 <^7heo> dude stop toying with my brain on fridays 2016-07-29 13:57:31 ? 2016-07-29 13:58:59 lawl 2016-07-29 14:04:01 ^7heo: could you please rewrite community/syncthing to use glide? 2016-07-29 14:04:17 <^7heo> jirutka: yes, this week end if I have time. 2016-07-29 14:04:23 okay 2016-07-29 14:04:25 <^7heo> jirutka: for now, I'm trying to have drone build 2016-07-29 14:04:34 <^7heo> jirutka: it's better than concourse but not really done yet. 2016-07-29 14:07:29 <^7heo> damn, go is a pain to build. 2016-07-29 14:07:38 oh, you don’t say?! XD 2016-07-29 14:08:00 I’m literally shocked, I definitely didn’t expected that! XD 2016-07-29 14:09:52 <^7heo> :DDD 2016-07-29 14:09:53 <^7heo> Come on 2016-07-29 14:10:07 <^7heo> it's almost working, once you put an army of symlinks around so go has what it wants. 2016-07-29 14:10:58 I guess that it’s also needed to sacrifice a virgin 2016-07-29 14:11:02 <^7heo> that drone makefile wants to make modifications on my system 2016-07-29 14:11:14 <^7heo> sh: amberc 2016-07-29 14:11:20 <^7heo> and has a dependency on amberc 2016-07-29 14:11:25 <^7heo> sh: amberc: not found 2016-07-29 14:16:50 <^7heo> dafuq, people expecting you to run makefiles as root. 2016-07-29 14:16:52 <^7heo> seriously. 2016-07-29 14:19:18 I’m telling you, Go culture is like PHP… 2016-07-29 14:22:53 "Go culture" 2016-07-29 14:29:08 <^7heo> skarnet: Go culture yourself. 2016-07-29 14:29:12 <^7heo> ;) 2016-07-29 14:40:57 I mean, Go is too young to be talking about Go culture. Go should be roughly transitioning from baby bottles to potties right now, and maybe walking on two legs without help. But it's definitely still wearing diapers - and given how most developers dump code, it's quite fortunate it is. 2016-07-29 14:41:55 That's the extent of "Go culture" right now. Ah-dah-dah. Shiny, colored objects, put the round thingy into the round hole. 2016-07-29 14:42:38 (a skill that developers seem to have long forgotten) 2016-07-29 14:51:43 <^7heo> (huhu) 2016-07-29 15:07:13 <^7heo> clandmeter: for your information 2016-07-29 15:07:22 <^7heo> clandmeter: building gogs with the distributed glide files fails. 2016-07-29 15:07:29 <^7heo> clandmeter: there are depedencencies missing. 2016-07-29 15:07:44 <^7heo> so I'm gonna have to patchs it. 2016-07-29 15:07:46 <^7heo> patch* 2016-07-29 15:07:47 and why did it work on the builder? 2016-07-29 15:09:40 <^7heo> clandmeter: did you build it without the glide files I provided? 2016-07-29 15:09:57 <^7heo> clandmeter: distributed == upstream distributed. 2016-07-29 15:10:09 <^7heo> clandmeter: I'm not calling the file we make the "distributed files" of a project. 2016-07-29 15:10:47 im going home, its weekend! 2016-07-29 15:11:02 <^7heo> enjoy :) 2016-07-29 15:13:11 and yes 2016-07-29 15:13:48 <^7heo> yes to everything. 2016-07-29 15:13:55 <^7heo> because I can. 2016-07-29 15:14:00 GO sucks 2016-07-29 15:14:10 we should ask github to remove all repo's 2016-07-29 15:14:11 <^7heo> It's better than to write "Go suck" 2016-07-29 15:14:13 <^7heo> :D 2016-07-29 15:14:35 <^7heo> clandmeter: at least that'll solve a lot of dependency problems. 2016-07-29 15:14:45 [INFO] --> Setting version for golang.org/x/net to 6a513affb38dc9788b449d59ffed099b8de18fa0. 2016-07-29 15:14:48 [ERROR] Failed to set version on golang.org/x/net to 6a513affb38dc9788b449d59ffed099b8de18fa0: Unable to update checked out version 2016-07-29 15:15:09 those dep managers are going to be a nightmare 2016-07-29 15:15:16 too many src locations that can go wrong. 2016-07-29 15:15:42 anyways, happy weekend climbers. 2016-07-29 15:29:55 <^7heo> clandmeter: that's just the golang.org server flapping. 2016-07-29 15:29:58 <^7heo> clandmeter: as always. 2016-07-29 15:30:04 <^7heo> clandmeter: when it does that, try again, it's gonna work. 2016-07-29 15:30:10 <^7heo> clandmeter: if it doesn't, try again. 2016-07-29 17:17:08 <^7heo> and btw 2016-07-29 17:17:18 <^7heo> jirutka: find . -name '*.go' won't work. 2016-07-29 17:17:34 <^7heo> jirutka: https://blog.golang.org/generate 2016-07-29 17:31:51 <^7heo> and that just cost me a failure again. 2016-07-29 17:31:57 <^7heo> (that generate) 2016-07-29 17:32:32 <^7heo> jirutka: if you knew how much pain maintaining a go language is... 2016-07-29 17:32:42 <^7heo> s/langu/pack/ 2016-07-29 17:45:18 <^7heo> jirutka: half of the software is apparently generated 2016-07-29 17:45:30 <^7heo> jirutka: for some reason, it's not working when I change the package. 2016-07-29 17:45:52 <^7heo> jirutka: not sure how easily I can generate that. 2016-07-31 01:55:35 Hey guys, I could not find min requirements in terms of CPU / RAM 2016-07-31 01:56:03 looking for a mini distro for an old (as in 20+ years old) PC 2016-07-31 02:03:24 1996? 2016-07-31 02:03:30 is it i586? 2016-07-31 02:03:41 alpine might run as it has low ram requirements 2016-07-31 02:03:55 1995 :P 2016-07-31 02:03:59 Low memory though 2016-07-31 02:04:03 IIRC the base system uses only 30mb of ram without any additional apk packages 2016-07-31 02:04:05 It's a i586 2016-07-31 02:04:15 That's not too bad, memory for it is inexpensive 2016-07-31 02:04:22 tx: good, alpine is optimized for that arch 2016-07-31 02:04:49 will it run X? 2016-07-31 02:04:54 hahaha 2016-07-31 02:04:56 yes 2016-07-31 02:05:16 what video hardware 2016-07-31 02:05:16 There's another issue in that the chipset / arch does not do out of order execution 2016-07-31 02:05:33 so software runs awfully unless it is compiled 'specially 2016-07-31 02:05:37 but that' something I will need to deal with :P 2016-07-31 02:05:49 some very basic "chips technologies" integrated jobby 2016-07-31 02:05:55 it will obviously need to all be software-rendered 2016-07-31 02:06:47 xf86-video-vesa might work 2016-07-31 02:06:53 dont expect it to run fast at all 2016-07-31 02:06:56 I don't doubt it 2016-07-31 02:06:59 it is VESA compatible 2016-07-31 02:07:29 memory / disk IO is the biggest issue :P 2016-07-31 02:07:34 The ATA bus is ISA 2016-07-31 02:07:40 so no DMA :P 2016-07-31 02:08:24 But that will be fixed (kinda) with a CF card 2016-07-31 02:08:31 Not the no DMA part, but at least part of the performance issues. 2016-07-31 02:16:05 tx: I would say get an S3 card but there's barely any for ISA on sale... 2016-07-31 02:16:23 I would have said cirrus but alpine does not package xf86-video-cirrus sadly.... 2016-07-31 02:17:58 kazblox: is a laptop 2016-07-31 02:18:04 o 2016-07-31 02:18:07 there is an expansion slot (currently occupied by a modem) 2016-07-31 02:18:11 but I am not sure what it is :P 2016-07-31 02:18:13 ok 2016-07-31 02:18:19 probably ISA 2016-07-31 02:50:49 hrm, guess pcmcia wasn't around back then? 2016-07-31 02:52:24 looks like cardbus / pci pcmcia came out in 97 for laptops 2016-07-31 03:49:03 it has cardbus 2016-07-31 03:49:11 the laptop was manufactured before 1997 lol 2016-07-31 03:49:18 maybe it was not ratified into a complete standard 2016-07-31 03:49:40 the expansion slot is specifically for a modem / NIC 2016-07-31 03:49:48 (not user serviceable) 2016-07-31 03:50:00 cardbus and pcmcia are not the same 2016-07-31 03:50:03 you have pcmcia 2016-07-31 03:50:07 which is 16-bit 2016-07-31 03:50:15 cardbus is pin compatible, and 32-bit 2016-07-31 03:50:22 ah right 2016-07-31 03:51:01 it has 2 slots 2016-07-31 03:51:04 I use it for wifi ;) 2016-07-31 03:51:09 (In Windows, mind you) 2016-07-31 03:51:58 Not enough IRQs for usb + firewire 2016-07-31 23:50:20 <^7heo> OMFG I HATE GO. 2016-07-31 23:50:33 <^7heo> How can such a thing still exist. 2016-07-31 23:54:24 <^7heo> And go developers use it SO wrong. 2016-07-31 23:55:13 <^7heo> How can such a thing still exist. 2016-07-31 23:55:29 because teenagers 2016-07-31 23:55:45 IIRC that's what the program was designed for according to some quote 2016-07-31 23:56:12 it's babies C, except it isnt 2016-07-31 23:58:08 <^7heo> Yeah 2016-07-31 23:58:10 <^7heo> But in the end 2016-07-31 23:58:15 <^7heo> I found the solution. 2016-07-31 23:58:19 <^7heo> It's in the documentation. 2016-07-31 23:58:26 <^7heo> I've been trying to build the package for like 3 days now. 2016-07-31 23:58:39 <^7heo> And the doc says "Drone ships as a single binary file inside a minimalist 20 MB Docker image. Docker is the only dependency." 2016-07-31 23:58:49 <^7heo> Ergo, it is NOT meant to be built 2016-07-31 23:58:51 go is terrible to package 2016-07-31 23:59:10 <^7heo> awilfox: I know, I have attempted to package 4 go binaries so far. 2016-07-31 23:59:14 <^7heo> only two have succeeded. 2016-07-31 23:59:38 <^7heo> and to be very honest, it makes a LOT of sense to distribute go binaries as docker images. 2016-07-31 23:59:49 <^7heo> because it goes well together. 2016-07-31 23:59:57 <^7heo> put the crap with the crap.