<     May 2017     >
Su Mo Tu We Th Fr Sa  
    1  2  3  4  5  6  
 7  8  9 10 11 12 13  
14 15 16 17 18 19 20  
21 22 23 24 25 26 27  
28 29 30 31
00:37 <kaniini> tmh1999: what does your /etc/network/interfaces look like
01:05 s33se_ joined
01:45 TemptorSent joined
01:59 <tmh1999> kaniini : it has lo and eth0. currently I just replace awk line with a block of code doing the same purpose. not a big deal now. Trying to setup the KVM network interface so the VM in KVM can have internet access.
02:02 <tmh1999> *awk line in /etc/init.d/networking
02:03 <tmh1999> https://git.alpinelinux.org/cgit/aports/tree/main/openrc/networking.initd#n26
03:25 Aeyris joined
03:44 <kaniini> tmh1999: which awk do you have installed ?
03:44 <tmh1999> kaniini : um.. probably default
03:45 <kaniini> awk --help
03:46 <tmh1999> on the go, I will be back on my machine tmr :D Thank you
05:19 fabled joined
06:01 faffolter joined
06:01 faffolter joined
06:19 fekepp joined
07:24 <clandmeter> Shiz, any comment regarding my question?
07:25 <fcolista> hi all
07:25 <fcolista> any hint on this issue?
07:26 <fcolista> crc32table.h:11:18: error: initializer element is not constant
07:26 <fcolista> # define tobe(x) ((uint32_t)__bswap_constant_32(x))
07:26 <fcolista> the code portion is:
07:26 <fcolista> https://github.com/jjzhang/ocfs2-tools/blob/master/libocfs2/crc32table.h
07:27 <Shiz> clandmeter: yeah, couple of reasons
07:27 <fcolista> it complains on the first parenthesis of uint32_t
07:27 <fcolista> crc32table.h:11:18: error: initializer element is not constant
07:27 <fcolista> # define tobe(x) ((uint32_t)__bswap_constant_32(x))
07:27 <fcolista> ^
07:33 <^7heo> showing that via IRC isn't the best idea. it currently shows me the error on the _ between bswap and constant
07:34 <^7heo> because wordwrapping
07:34 <Shiz> sorry, doing a few tthings at once again
07:34 <Shiz> fcolista: that sounds like a compiler bug
07:34 <Shiz> fcolista: what package?
07:34 <Shiz> fcolista: an easy fix is just doing a manual endian swap
07:35 <Shiz> if you remember how to :)
07:35 <Shiz> fcolista: or try replacing it with
07:35 <Shiz> __builtin_bswap32
07:36 <Shiz> clandmeter: so like i said, a couple of reasons
07:37 <Shiz> 1) less dependency on GNU, and multiple system compilers helps with catching bugs
07:37 <Shiz> 2) development wise, clang is far more active and likely the way forward in terms of development power put into it
07:37 <Shiz> 3) security features like CFI and UBSan which are not in gcc
07:37 <^7heo> pretty much what ncopa said about musl
07:38 <^7heo> aside the implementation details
07:39 <clandmeter> Thx guys
07:39 <Shiz> there's also a kernel hardening aspect
07:40 <Shiz> with grsecurity not in the picture for most people anymore, it's mostly up to big companies like google (sadly) to start fixing up security measures for linux
07:40 <Shiz> and well
07:40 <Shiz> companies like google use clang to compile the kernel
07:40 <Shiz> they're not going to write gcc plugins anymore like grsec did
07:40 <Shiz> they'd write clang plugins :P
07:41 <^7heo> what did those plugins do?
07:41 <fcolista> Shiz, it's ocfs2-tools
07:42 <Shiz> i think __builtin_bswap32 should work
07:42 <Shiz> ^7heo: support for PaX's RAP feature, constifying structures, randomizing structures, some other stuff
07:42 <fcolista> Shiz, this is the code:
07:42 <fcolista> https://github.com/jjzhang/ocfs2-tools/blob/master/libocfs2/crc32table.h
07:42 <fcolista> it defines or LITTLE_ENDIAN or BIG_ENDIAN
07:43 <^7heo> Shiz: I see. Thanks
07:43 <xentec> also Shiz: 4) easier cross-compiling
07:43 <Shiz> xentec: nah
07:43 <Shiz> at least cross-compiling for bootstrapping is a pain in the ass
07:43 <Shiz> :P
07:44 <fcolista> i'll patch that from ((uint32_t)__bswap_constant_32(x)) to __builtin__bswap_constant_32(x) then?
07:44 <Shiz> __builtin_bswap32
07:44 <Shiz> no _constant_ there
07:44 <Shiz> :P
07:45 <xentec> Shiz: wouldn't clang (as system cc) with lld support all alpine archs and only require --target to cross-compile?
07:45 <fcolista> oh ok
07:45 <^7heo> fcolista: what if you cast it to 'const uint32'?
07:45 <Shiz> ^7heo: won't work
07:45 <^7heo> Shiz: why?
07:46 <fcolista> so from this: ((uint32_t)__bswap_constant_32(x) to ((uint32_t)__builtin_bswap32(x)
07:46 <Shiz> fcolista: yes
07:46 <Shiz> ^7heo: because the error is that the compiler can't compute the value at compile-time
07:46 <Shiz> not that the return value is a const uint32, which is not meaningfully differet from uint32
07:46 <Shiz> :P
07:47 <^7heo> from what I can read, it's that the compiler does not find a const value
07:47 <fcolista> Shiz, thx
07:47 <^7heo> and that a check failes
07:47 <fcolista> i'm trying and let you know
07:47 <^7heo> failed*
07:47 <^7heo> but yeah I'd have to try to be sure.
07:47 <^7heo> I'm no gcc guru
07:47 <Shiz> no
07:47 <Shiz> it's that the initializer isn't constant
07:48 <Shiz> which is different from a 'const value'
07:48 <^7heo> yes
07:48 <Shiz> :)
07:48 <Shiz> const is a C keyword with very specific meaning
07:48 <Shiz> in this case constant means 'i cant determine this at compile time'
07:48 <Shiz> (since it's being embedded in a static table)
07:48 <^7heo> well, since I don't see where the initializer is used, I can't tell
07:48 <Shiz> a few lines below
07:48 <Shiz> in the file fcolista linked
07:49 <^7heo> ah he linked something?
07:49 <fcolista> ^7heo, : https://github.com/jjzhang/ocfs2-tools/blob/master/libocfs2/crc32table.h
07:50 <^7heo> yeah got it now
07:50 <fcolista> ^~~~
07:50 <fcolista> crc32table.h:11:18: error: initializer element is not constant
07:50 <fcolista> # define tobe(x) ((uint32_t)__builtin_bswap_32(x))
07:50 <fcolista> ^
07:50 <fcolista> Shiz, pathc applied
07:50 <Shiz> bswap32
07:50 <Shiz> not bswap_32
07:51 <fcolista> omg..
07:51 <^7heo> :p
07:51 <fcolista> stupid me
07:51 <fcolista> sorry
07:51 <^7heo> Shiz: from what I gathered, 'const' is mainly for compiler checks
07:52 <fcolista> Shiz, good
07:52 <clandmeter> Too much grappa
07:52 <^7heo> not yet
07:52 <fcolista> that part works.
07:52 <Shiz> brb
07:52 <^7heo> to put grappa in coffe you need coffee first
07:54 <clandmeter> I already had my Italian coffee. It's a bit too early for grappa (if you even like that stuff)
08:01 <fcolista> include/strings.h:37:1: error: unknown type name 'errcode_t'
08:01 <fcolista> errcode_t o2fsck_strings_insert(o2fsck_strings *strings, char *string,
08:01 <fcolista> ^~~~~~~~~
08:01 <fcolista> sorry
08:01 <fcolista> wrong paste
08:52 royger joined
08:59 <fcolista> I'm looking at http://bugs.alpinelinux.org/issues/7336
09:01 <fcolista> in order to avoid that mosh-server installs mosh-client, it's enough specify depends="" ?
09:02 <fcolista> why if i add mosh-client, mosh-server is not installed, while if i install mosh-server, mosh-client is installed?
09:05 <lxGzx53qO34r> ^7heo: most importantly the rap implementation is a gcc plugin, but also int overflows have been handled with a plugin, more info here https://pax.grsecurity.net/docs/PaXTeam-H2HC13-PaX-gcc-plugins.pdf
09:15 <^7heo> lxGzx53qO34r: thanks.
09:17 cyteen joined
09:28 royger joined
09:28 vakartel joined
09:32 czart_ joined
09:33 xsteadfastx joined
11:08 <awilfox> ah yes, the alpine vanilla 3.6 iso, with just enough "-ash: vgchange: not found" and "lvm: applet not found" to be completely useless in fixing my initramfs :)
11:08 <awilfox> let's try extended iso
11:12 <awilfox> nope! but at least it worked enough to let me `apk add lvm2` while booted in the iso environment
11:13 <awilfox> good thing this machine has network that does not need non-free drivers
11:23 leo-unglaub joined
11:50 <clandmeter> 3.6 vanilla iso does not have lvm2?
11:51 tmh1999 joined
11:52 rdutra joined
12:07 gromero joined
12:16 leitao joined
12:18 fabled joined
12:30 rnalrd joined
12:31 farosas joined
12:57 <rnalrd> clandmeter to=<patches@patchwork.alpinelinux.org>, relay=none, delay=420386, delays=420356/0.01/30/0, dsn=4.4.1, status=deferred (connect to patchwork.alpinelinux.org[88.159.20.184]:25: Operation timed out)
12:57 <rnalrd> are you able to fix it? ^^^^
13:18 fekepp joined
13:20 czart joined
13:20 <ncopa> rnalrd: i fixed the dnat rule for patchwork.alpinelinux.org. should work now
13:44 rdutra joined
13:57 <blueness> ncopa: ping
13:57 <blueness> ncopa: we have a common problem with respect to grsecurity, we should chat
14:01 <ncopa> blueness: pong
14:01 <ncopa> blueness: where do you want to chat?
14:01 <blueness> we can chat here
14:01 <ncopa> ok
14:01 <ncopa> you are from gentoo, arent you?
14:01 <blueness> so what is alpine's plans wrt grsecurity
14:02 <skarnet> you want kaniini to be part of this conversation too
14:03 <ncopa> the current plan is to support the current 4.9 kernel with unofficial port of grsec
14:03 <blueness> yes i do hardened gentoo and gentoo+musl and gentoo+uclibc
14:03 <blueness> that's doable, but after that?
14:03 <ncopa> we wait and see
14:03 <ncopa> spender talked about releasing testing patch regularilly
14:03 <blueness> okay here's a suggestion, it may be possible to maintain just the pax patch
14:04 <ncopa> but didnt want to promise anything
14:04 <blueness> but its a lot of work
14:04 <ncopa> so he didnt mention it in the public statement
14:04 <^7heo> do you want me to ask strcat to join the chat?
14:04 <ncopa> i think fewer participants is better at this point
14:04 <^7heo> maybe.
14:05 <blueness> well i got my answers, wait and see
14:05 <^7heo> it's just that he also has wishes and plans for grsec afaik
14:05 <^7heo> but mostly for ARM
14:05 <blueness> we can't however, depend on spengler and pipacs anymore, this was too disruptive for use in gentoo
14:06 <blueness> i spent a lot of time working on getting end-to-end xattr support in our package management system
14:06 <blueness> for xattr pax
14:06 <blueness> and i did a lot of the preliminary work in getting xattr pax into the kernel
14:06 <blueness> and now all that machinary is just sitting there dangling
14:07 <blueness> i'm not interested being dependant on a volitile team like grsecurity anymore
14:07 <ncopa> i understand that
14:07 <skarnet> I think that's the general feeling around here too
14:07 <ncopa> what are the options?
14:08 <blueness> try to maintain just pax patch might be possible
14:08 <ncopa> i stil think it iwill be difficult to jump major kernel version
14:08 <skarnet> kaniini spent a good deal of time thinking about this, you really may want his input here
14:08 <ncopa> kaniini tried to split up the pax patch to keep it separate
14:08 <ncopa> but i think he gave up
14:09 <blueness> ncopa: it would be difficult to make sure we don't miss anything
14:09 <ncopa> i have maintained unofficial patch for a while, and i know that upgrading major kernel version is non-trivial
14:09 <blueness> okay i should probably speak to kaniini before trying myself
14:09 <ncopa> and i would personally not even want to try
14:10 <blueness> whoever gets involved can expect this to be his full time job, but it would save the project
14:10 <blueness> also, it might entice pipacs and spengler to reopen their stuff
14:10 <ncopa> im hoping they will release the testing patch once in a while
14:11 <blueness> why woudl they, they've even kicked us from #grsecurity
14:11 <blueness> sounds to me like they've said fu to the community
14:11 <ncopa> "just to keep people away from KSPP"
14:11 <ncopa> and
14:12 <ncopa> "just to prove that its not possible to maintain a community fork"
14:12 <ncopa> those have been the reasons they have mentioned
14:12 <kaniini> it's not possible because they made it impossible
14:12 <kaniini> through monolithic invasive patching
14:12 <ncopa> yes
14:13 <blueness> maybe
14:13 <blueness> kaniini: how far did you get?
14:14 <ncopa> blueness: do you have patches for 3rd party modules?
14:14 <kaniini> far enough to know i am going back to bed with my phone on silent this time
14:14 <ncopa> to work with (unofficial) grsec
14:14 <blueness> ncopa: nope
14:14 <ncopa> blueness: i did spl and zfs only
14:14 <ncopa> they work with 4.9
14:15 <blueness> kaniini: okay so you gave it a serious go and its too much
14:15 <ncopa> pipacs wrote about the kspp, that they picked a patch for older kernel, and added it to newer
14:15 <ncopa> and messed up
14:15 <ncopa> and kspp complained about bugs in pax
14:16 <blueness> i saw that post
14:16 <skarnet> this drama is better than Netflix
14:16 <ncopa> i think that part kind of shows that porting pax to newer major kernels is non-trivial
14:17 <ncopa> the drama itself is good enough reason to avoid grsecurity
14:17 <kaniini> have you people considered that pax
14:17 <kaniini> legitimately has bugs
14:17 <kaniini> like we have reported pax bugs before
14:17 <ncopa> yes
14:18 <ncopa> they have had some
14:18 <kaniini> blueness: some parts are easy
14:19 <kaniini> blueness: the parts that people want in 2017: not so much
14:19 <blueness> kaniini: k
14:21 <^7heo> < blueness> sounds to me like they've said fu to the community
14:21 <^7heo> I guess that being in a position of power makes you able to do so.
14:21 <^7heo> And they wouldn't be in such a powerful position if the community didn't 100% rely ONLY on them for years.
14:21 <^7heo> so...
14:24 <kaniini> what ^7heo said really
14:24 <kaniini> i rather spend my time supporting viable efforts such as clang as system compiler
14:25 <^7heo> strcat says that he could use the help of people knowing the clang backend
14:25 <^7heo> in his linux-hardened project.
14:25 <^7heo> s/says/said/
14:26 <^7heo> I guess that such a person would also be able to implement a lot of security features in other archs too.
14:26 <skarnet> Shiz, kaniini: are we more or less set on /pkg for the non-FHS place to put Alpine packages into?
14:26 <^7heo> (since he's mostly interested in arm, as I said)
14:33 <Shiz> blueness: so here's my perspective on this as someone who has spent a bit of time on it
14:33 <Shiz> 1) PaX and grsecurity are both monolithic and short-term unmaintanable as is
14:33 <Shiz> they are massively complex and hard to understand, especially for just a few people who are not intimately familiar with their internals
14:33 <Shiz> and they touch about every area of the kernel
14:33 <Shiz> not just grsec, but PaX itself too
14:34 <Shiz> as such, I don't think it's viable right now for distros to try and forward-port even just PaX to new major kernel versions
14:34 <blueness> Shiz: obviously we'd have to separate that out if we wanted to maintain it
14:34 <Shiz> yes, but PaX on its own is huge
14:34 <Shiz> the part of grsec that isn't PaX is actually somewhat small in comparison
14:34 <Shiz> (still big, mind you)
14:35 <Shiz> a wholly unscientific size comparison:
14:35 <Shiz> grsec total is about 9mb
14:35 <Shiz> pax split up from that is ~7.7mb
14:35 <Shiz> it touches EVERYTHING
14:35 <blueness> god!
14:36 <royger> port the openbsd kernel, it's going to be easier :P
14:36 <^7heo> any BSD would be easier.
14:36 <Shiz> blueness: so i started up a repo with the effort of splitting pax into smaller, more viable things
14:36 <^7heo> but unfortunately it lacks the drivers.
14:37 <Shiz> so people can learn from it and maybe in time a community-maintained hardened kernel project can spring up
14:37 <Shiz> and that seems to be happening with strcat's linux-hardened
14:37 <Shiz> even though it's not perfect and we have to wait and see how good it will turn out, I sadly think it is the best option for hardened distros right now
14:37 <Shiz> personally
14:37 <^7heo> Shiz: but strcat's tree is aimed at arm only.
14:37 <Shiz> the sad reality is that PaX is too complicated and involved to maintain for a couple of distro maintainers like you and me
14:37 <skarnet> not sure I want anything "hardened" by a person naming themselves "strcat"
14:37 <Shiz> ^7heo: it is not
14:37 <^7heo> Shiz: I mean, he told me he would focus only on ARM
14:38 <Shiz> him personally eys
14:38 <^7heo> Shiz: but that he implemented stuff for any arch
14:38 <Shiz> but there's more contributors to that project/repo
14:38 <^7heo> anyway.
14:38 <^7heo> ah right
14:38 <Shiz> than strcat
14:40 <Shiz> kaniini: speaking of system clang, i just finished splitting up my commits
14:40 <Shiz> they could use a bit more refinement, but it's an initial patch series at least
14:40 <Shiz> gonna push them to github right about... now
14:40 <xentec> \o/
14:40 <algitbot> \o/
14:41 <xentec> oke
14:41 <xentec> wrong chat damn it
14:41 <^7heo> happens to the best of us.
14:42 <xentec> more like broken autofocus
14:42 <Shiz> my patches also touch abuild
14:42 <Shiz> heh
14:43 <skarnet> Shiz: can you please confirm we'll use /pkg for the optional non-FHS place to install stuff?
14:43 <skarnet> as in /pkg/$foobar/$version ?
14:44 <Shiz> i don't think it's been fleshed out yet, but that is my current preference yes
14:44 <Shiz> any reason you need confirmation? :P
14:44 rdutra joined
14:44 <skarnet> immediate application for a project I'm working on
14:45 <skarnet> and that absolutely wants to have its own dir because reasons
14:47 <Shiz> well if it's up to me, yes -- but it's not at my sole discretion to make
14:48 <skarnet> ok, thanks. I'll use that as a working hypothesis.
14:54 <Shiz> https://github.com/Shizmob/aports/commits/system-llvm
15:01 <^7heo> is there a way to find the best header for a combination of things?
15:01 <Shiz> hm?
15:01 <^7heo> for instance: I want the "best" header for defining NULL and size_t
15:01 <jirutka> <awilfox>: "ah yes, the alpine vanilla 3.6 iso, with just enough "-ash: vgchange: not found" and "lvm: applet not found" to be completely useless in fixing my initramfs :)" – yeah, I’ve complained some time ago that our ISOs are quite useless, b/c it does not ship even very essential packages like e2fsprogs and someone told me that ”it’s by design”… :/
15:01 <^7heo> there are multiple headers that match.
15:01 <^7heo> 1. how do I list them all without a complicated grep
15:01 <^7heo> 2. how do I chose which is the "best" one?
15:01 <^7heo> 3. does that even matter?
15:01 <skarnet> 3. no
15:01 <^7heo> huhu
15:02 <^7heo> thanks.
15:02 <skarnet> 2. for NULL and size_t, it's stddef.h. Generally, but exceptions are numerous, there's a "canonical" header that defines some type or macro
15:03 <^7heo> I used string.h
15:03 <skarnet> and you want to include that one, but there are also multiple inclusions mandated by POSIX
15:03 <skarnet> that's fine
15:03 <skarnet> string.h is canonical if you want to use stuff such as strcmp() or memmove()
15:04 <skarnet> if you want to do things "right" and "beautifully", you need to look at POSIX and get a feel for what header relates to what
15:05 <skarnet> but as a first step, don't worry about that, grab any header that defines what you want
15:05 <skarnet> you can refine later
15:06 <^7heo> yeah ok
15:06 <^7heo> Thanks ;)
15:11 <Shiz> https://github.com/Shizmob/abuild/commits/system-llvm
15:11 <Shiz> and the needed abuild commits
15:14 <Shiz> jirutka: you may be interested in the above two branches ;p
15:14 <Shiz> i need to refine the commits, add comments and rationales etc
15:14 <Shiz> but this worked for me in getting most of an LLVM system setup through aports scripts/bootstrap.sh
15:14 <Shiz> minus ghc and the kernel
15:34 <ammunta> does the kernel not build
15:36 <Shiz> not with llvm, no
15:46 <^7heo> The kernel historically only built on gcc, right?
15:52 <ncopa> how do we solve the list of architectures: http://wwwtest.alpinelinux.org/downloads/
15:53 <ncopa> when you download an alpine release, you first select flavor (Eg standard/extended/vanilla/...) and then you select arch?
15:53 <ncopa> or do you select arch first and then flavor?
15:53 <Shiz> hmm
15:53 <Shiz> flavor->arch makes more sense from an UX perspective
15:53 <Shiz> but
15:53 <Shiz> not all archs have every flavour
15:53 <Shiz> ^7heo: yes
15:54 <Shiz> there's the llvmlinux project to remedy this but it's somewhat dead now it seems
15:54 <Shiz> although most of their patches are upstream
15:54 <_ikke_> I also agree with flavor->arch
15:54 <ncopa> ok good, thats a start
15:55 <^7heo> definitely flavor arch/
15:55 <^7heo> s/\//./
15:55 <ncopa> i wonder if we should have a dropdown box for arch?
15:55 <ncopa> or if we should have a separate page for each flavor?
15:55 <^7heo> that means it's then arch -> flavor.
15:55 <ncopa> or something else?
15:55 <^7heo> dropboxes come first, UI wise.
15:56 <^7heo> because they act as a filter.
15:56 <^7heo> s/boxes/downs/
15:56 <ncopa> do we want dropdownbox at all is my question
15:56 <^7heo> well if so, it should be with the flavor.
15:56 <^7heo> not the arch.
15:57 <clandmeter> Yes css Dropbox
15:57 <^7heo> clandmeter: dropboxes are HTML actually.
15:57 <Shiz> ^7heo: i think an additional dropbox next to the listing is intended
15:57 <Shiz> not primary before showing the listing
15:57 <^7heo> Shiz: I see.
15:58 <^7heo> I fear that it's gonna be confusing tho.
15:58 <^7heo> because most people are just gonna assume 'their arch'
15:58 <^7heo> which might be possible since we have the useragent
15:59 <Shiz> ?
16:02 <skarnet> Is it possible to make abuild build a package from a git version, without first performing git snapshot + upload + redownload of the snapshot ?
16:02 <skarnet> um, abuild snapshot*
16:06 <skarnet> anyone?
16:07 <^7heo> skarnet: I do not understand the question: what is a git snapshot?
16:07 <skarnet> <skarnet>um, abuild snapshot*
16:07 <^7heo> ah sory
16:07 <^7heo> sorry*
16:07 <clandmeter> skarnet, sure, just checkout any repo in prepare
16:08 <^7heo> skarnet: abuild -r
16:08 <^7heo> skarnet: or?
16:08 <scadu> ^7heo: wut
16:08 <^7heo> scadu: wat wut?
16:08 <clandmeter> but we dont have any git magic in abuild
16:08 <skarnet> clandmeter: ok, so I need to prepare() by hand
16:08 <scadu> ^7heo: vodka
16:08 <skarnet> can I leave $url empty then?
16:09 <clandmeter> you mean source?
16:09 <^7heo> I have no clue what the question is about.
16:09 <^7heo> I never had to upload anything to build a package...
16:09 <skarnet> ^7heo: cut the noise, please?
16:09 <^7heo> skarnet: how is me trying to understand (and possibly help) noise?
16:09 <^7heo> =/
16:10 <skarnet> because if you can't understand the fucking question, there's no possible way you can help
16:10 <skarnet> clandmeter: uh, yes, source, I guess
16:11 <scadu> iirc you will need to
16:11 <^7heo> tbf I never understood the point of the abuild snapshot. If the source's available, why the heck make a snapshot of it?
16:11 <Shiz> @clandmeter │ but we dont have any git magic in abuild <-- just to checkout git repos :P
16:11 <Shiz> ^7heo: because the availability may be spotty or not provide stable tarballs
16:12 <^7heo> ok.
16:12 <^7heo> but doesn't git snapshot require the user to have the rights to upload a snapshot to start with?
16:13 <^7heo> I mean, it's basically the same as me putting the files on my local server, except that locally I have the rights.
16:13 <clandmeter> Grrr WiFi just died on me again.
16:13 <skarnet> clandmeter: prepare() is about applying patches, is there a way for me to basically do a fetch but from a git repo instead of a URL?
16:14 <skarnet> I'll checkout the branch I need in prepare(), but I kinda need the repo to be cloned before prepare()
16:15 <Shiz> skarnet: any specific reason? you can call default_prepare in your prepare() after checking the repo out
16:15 <Shiz> (imo i think snapshot() should provide a file that you can put in source=, if it doesn't right now it should)
16:15 <clandmeter> That's what we do in prepare. You can add it before default_prepair
16:16 <^7heo> in any case, if the point is to snapshot, it's totally possible to snapshot it to localhost and use that in the source=""
16:16 <clandmeter> Sorry I'm on freaking mobile now :|
16:16 <Shiz> but it's not, right now.
16:16 <skarnet> Shiz, clandmeter: my question is about fetching, i.e. is there a "git clone" performed by abuild at some point
16:16 <Shiz> yes
16:17 <skarnet> instead of a wget or curl
16:17 <skarnet> ok, then how can I access it
16:17 <^7heo> Shiz: When Oo
16:17 <skarnet> jeez, am I asking questions in Chinese or what
16:17 <clandmeter> yes, that happens before prepare
16:17 <Shiz> if you call 'abuild snapshot', it will read $giturl from the APKBUILD
16:17 <Shiz> clone the repo
16:17 <clandmeter> which is actually default_prepare
16:17 <Shiz> and tar it up into $pkgname-$pkgver.git
16:17 <Shiz> or something
16:17 <Shiz> .tar.gz
16:18 <Shiz> optionally reporev= in APKBUILD for the revision to checkout
16:18 <skarnet> ok, let me be painfully explicit
16:18 <clandmeter> you could even overide the fetch part i think
16:18 <clandmeter> but i usually just do that stuff in prepare.
16:18 <Shiz> clandmeter: yes by overriding snapshot() :P
16:19 <^7heo> clandmeter: the packages on the repo that I've seen cloning git repos are using the snapshot function for it.
16:19 <^7heo> s/on/in/
16:19 <clandmeter> correct, but that was not skarnet question
16:19 <skarnet> AIUI if I just do "abuild -r" it will only work if the sources are regular URLs, and I need to manually "abuild snapshot" if I want to get sources from a git repo.
16:19 <skarnet> Is my understanding correct?
16:19 <Shiz> yeah
16:20 <Shiz> it's not ideal i'd say
16:20 <^7heo> unless you actually use a local file in source and build that file with prepare/snapshot; right?
16:20 <Shiz> right.
16:20 <^7heo> I never tried if it actually worked, I always assumed it would.
16:20 <Shiz> that would be something like abuild snapshot && mv src/<thatfile> . and adding <thatfile> to source=
16:20 <Shiz> and running abuild checksum
16:21 <skarnet> ok. Once I've performed "abuild snapshot" and got a local copy, where do I place that copy in order to feed it to the rest of the abuild process so it's as close to a full "abuild -r" as possible?
16:21 <^7heo> the point of making snapshots is then only to get reproducible builds
16:21 <Shiz> skarnet: move it to the same dir as the APKBUILD and add the filename to source=
16:21 <Shiz> and run abuild checksum
16:21 <Shiz> after that, abuild -r should JustWork
16:21 <^7heo> $srcdir I would say?
16:21 <skarnet> yay self-modifying APKBUILDs
16:21 <Shiz> no, not $srcdir
16:21 <^7heo> ah yeah it's creating a link there.
16:21 <^7heo> crap.
16:22 <skarnet> ok, I figured out my workflow now, thanks.
16:22 <Shiz> skarnet: i'd like to fix this someday as it's not great
16:22 <Shiz> but i only knew this whole snapshot business existed like
16:22 <Shiz> two weeks ago
16:22 <Shiz> :p
16:22 <^7heo> Shiz: how would you provide reproducible builds without snapshots?
16:22 <skarnet> hm, next question: can I give a whole directory of stuff to $sources ?
16:23 <Shiz> afaics, no
16:23 <Shiz> if you're feeling daring you could sources="$(find . -type f)" though
16:23 <^7heo> Shiz: and how would you provide snapshots without requiring the rights to upload somewhere?
16:23 <Shiz> :P
16:23 <Shiz> replace . is necessary
16:23 <Shiz> s/is/as/
16:23 <skarnet> so I basically need to tar shit to feed it to abuild
16:23 <Shiz> snapshot() tars it up for you
16:24 <clandmeter> or zip :)
16:24 <skarnet> yeah but I don't want to go through abuild if I'm going to modify the APKBUILD between two invocations
16:24 <Shiz> into $srcdir/$pkgname-$verbase_git.tar.gz
16:24 <Shiz> hmm
16:24 <^7heo> Shiz: wouldn't it be enough just to change snapshot to take a sha1 btw?
16:24 <skarnet> so I'll git clone outside of abuild, make a suitable APKBUILD, and only then call abuild with fully local sources
16:24 <^7heo> Shiz: to make it work without a snapshot...
16:25 <Shiz> skarnet: in that case, yes, source= takes files
16:25 <Shiz> you can use git-archive :P
16:26 <skarnet> good idea, thanks for the pointer
16:26 <Shiz> i don't think adding git:// support to abuild directly is the worst idea, but i've also only ever once seen a package that didn't provide http uris for releases
16:26 blueness joined
16:27 <^7heo> all this would be avoided if abuild would know how to work with a RCS repo and a given version.
16:28 <^7heo> Shiz: can you specify a given version in a git:// URL?
16:28 <Shiz> sure, just abuse #
16:28 <^7heo> isn't # part of HTTP?
16:29 <^7heo> Ok HTTP refers to RFC 2396
16:30 <Shiz> its a URI fragment for local processing
16:31 <Shiz> so, exactly what this would be useful for
16:31 <^7heo> yeah I got that part.
16:31 <^7heo> I'm just wondering if git also uses that same RFC
16:31 <Shiz> it doesn't, but that doesn't mean we can't
16:32 <^7heo> Well, that also doesn't mean they can't release a git version that breaks our workflow in XXXXX packages.
16:32 <Shiz> yes it does
16:32 <^7heo> How?
16:32 <Shiz> if we interpret it before passing it to git
16:32 <^7heo> ah.
16:32 <Shiz> remove the fragment
16:32 <^7heo> yeah sure.
16:32 <^7heo> but then if git makes use of that #
16:33 <^7heo> it still breaks our workflow.
16:33 <^7heo> or we have to define a way right from the start to leave it in there.
16:33 <^7heo> (i.e. escape it)
16:34 <^7heo> Another way would be to specify another parameters for git sources
16:34 <^7heo> s/ters/ter/
16:34 <^7heo> i.e. git_source or something
16:34 <^7heo> that way you also can have git_version.
16:35 <^7heo> and that's separated right from the APKBUILD.
16:35 <^7heo> no magic happening in the source= parameter.
16:35 <Shiz> skarnet: anyway, is your use case simply a source that doesn't provide http uris?
16:36 <skarnet> yes.
16:36 <skarnet> because continuous integration, etc.
16:37 <skarnet> also, need to create a package from any branch, any commit, that kind of thing.
16:38 <Shiz> ^7heo: the *point* is that it would be together with the rest in source=
16:39 <^7heo> Shiz: why? It's not processed the same way.
16:40 <^7heo> on the other hand
16:40 <^7heo> we already use pkgver for versions
16:40 <^7heo> we could just pass the sha1 there.
16:40 <^7heo> that would work well.
16:40 <Shiz> sigh
16:41 <Shiz> it *is* processed the same way
16:41 <Shiz> not all sources get wget'd either
16:41 <Shiz> and there is not necessary just a single git repo for every package
16:41 <Shiz> or a single git version
16:41 <^7heo> what I mean is that it's not just read.
16:42 <Shiz> it certainly isn't written to
16:42 <^7heo> well, the real tar.gz *is*
16:42 <Shiz> what real .tar.gz
16:42 <Shiz> there would be no 'real' .tar.gz if there was direct git uri support
16:42 <^7heo> ah you're thinking about that.
16:42 <^7heo> well... that's true.
16:43 <^7heo> I was thinking about a simple way to make it work with the current abuild.
16:43 <Shiz> i'd like for apk to support subdirectory summing actually
16:43 <Shiz> it would solve some issues with cargo as well
16:43 <^7heo> i.e. getting the repo, creating an archive, using that.
16:43 <^7heo> Shiz: you mean, using an entire directory as source?
16:44 <Shiz> not as source, just in checksums=
16:44 <Shiz> things in source= (or the fetch() override) would create those directories
16:44 <^7heo> how would you generate the checksum of a dir?
16:45 <^7heo> cat all the things?
16:45 <^7heo> or tar?
16:45 <Shiz> checksum of a checksum list of the directory
16:45 <Shiz> would be one way
16:45 <^7heo> yeah
16:45 <Shiz> find dir -type f -exec $sum {} \; | $sum -
16:45 <^7heo> yeah yeah
16:45 <^7heo> can get verbose tho
16:45 <Shiz> ?
16:45 <Shiz> it would be a single checksum
16:46 <^7heo> aah `-`
16:46 <^7heo> right.
16:46 <^7heo> but then you're relying on what order find gives you.
16:46 <^7heo> I was thinking about doing the same thing but with a sort in the middle.
16:47 <Shiz> sure
16:47 <^7heo> that way you rely on sort, which is much more reliable than find IMHO
16:47 fekepp joined
16:47 <^7heo> but yeah that would be a great addition to abuild.
16:56 <ncopa> http://wwwtest.alpinelinux.org/downloads/
16:57 <ncopa> refresh the stylesheet too
16:57 <ncopa> i have modified the script so the flavors comes in a predictable order
16:57 <ncopa> by using lua "array" instead of hashtable
16:57 <skarnet> can a local source for abuild be a non-gzipped .tar ?
16:58 <ncopa> skarnet: yes
16:58 <ncopa> but im not sure it will automatically extract it for you
16:58 <Shiz> it will
16:58 <ncopa> ok
16:58 <skarnet> what stage will? prepare?
16:58 <Shiz> even if it didn't, you can override unpack() to extract it for you
16:58 <Shiz> unpack
16:58 <ncopa> re the downloads page
16:58 <ncopa> i made it 2 columns instead of 3
16:58 <skarnet> where does it unpack it? $srcdir ?
16:58 <ncopa> as a "quickfix"
16:59 <ncopa> yes, under $srcdir
16:59 <skarnet> thanks
16:59 <Shiz> sanitycheck -> builddeps -> clean -> fetch -> unpack -> prepare -> mkusers -> build -> check -> rootpkg -> cleanup
16:59 <Shiz> are the stages
17:05 <ncopa> the ppc64le and s390x release images are there too
17:05 <ncopa> ok nobody is complaining, i think i just push that for production
17:12 <przemoc> looks nice, but maybe putting small sha256 and gpg buttons next to arch download buttons would look even better, because now we have 2 special rows just to hold them
17:12 <ncopa> yes, i agree
17:18 cyteen joined
17:29 <jirutka> let me introduce you Luapak, the ultimate solution for building standalone, zero-dependencies, possibly statically linked binary for any Lua program! \o/ hello_world dynamically linked with musl is 146 kiB (stripped), statically linked with musl 190 kiB (stripped); https://github.com/jirutka/luapak /cc ncopa clandmeter
17:29 <algitbot> \o/
17:31 <skarnet> 190k of overhead doesn't sound too bad indeed :)
17:31 <skarnet> nice job!
17:31 <jirutka> skarnet: yeah, PUC Lua is really very small! :)
17:32 <ncopa> interesting
17:32 <TBB> the snapshot mechanism, now that I just refreshed my memory by re-reading the whole abuild script, seems quite allright to me. I currently have my own wrapper around abuild that runs a part of the command chain Shiz just wrote above to enable "local" builds
17:32 <jirutka> and even when you use LuaJIT for significantly better performance, the resulting size is still not bad (I must laugh really loud when I compare it with Go XD)
17:32 <TBB> -finally- a reason to learn Lua!
17:33 <jirutka> I’m dog fooding, so Luapak is of course built with Luapak :) https://github.com/jirutka/luapak/releases/download/
17:33 <skarnet> please keep a sane bootstrapping process :P
17:34 <Shiz> is there a way to get apk to output just the current installed version of a package?
17:35 <Shiz> ( jirutka ?)
17:42 <TBB> I suppose you need to parse no matter what, but the closest to that would be apk info -v -e pkg, I guess
17:50 faffolter joined
18:05 <skarnet> Is there a way to tell abuild that it must fetch its makedepends (for abuild -r) from edge, instead of from the current flavor? i.e. a way to tell it to run --repository somethingedgesomething in its apk invocations?
18:05 <skarnet> (don't ask why I want to do that)
18:06 <Shiz> uuuh
18:07 <Shiz> you could uh
18:07 <Shiz> do something like
18:07 <Shiz> SUDO_APK="abuild-apk --repository ..." abuild -r
18:08 <skarnet> thanks for the pointer - I'll see what SUDO_APK does :) but...
18:08 <skarnet> ... I don't want to do that for all the apks in my makedepends, only 2 of them
18:08 <Shiz> yeah i don't think that's gonna work out :P
18:08 <skarnet> I know it's not supposed to
18:08 <Shiz> you could build them yourself locally?
18:08 <Shiz> it will include your local repo for makedeps
18:09 <Shiz> so if you build from edge yourself
18:09 <Shiz> well by "not gonna work out" I mean "there's no way I know of to get this to work"
18:09 <skarnet> well I can also call apk add myself before calling abuild
18:09 <Shiz> except possibly a tagged repo in /etc/apk/repositories and doing foo@edge as makedepend
18:09 <skarnet> and conveniently omit the packages from makedepends
18:09 <Shiz> that may work
18:10 <skarnet> ah, that's interesting
18:10 <TBB> doesn't work
18:10 <Shiz> doesnt?
18:10 <TBB> tags in deps doesn't, that is
18:10 <skarnet> shame
18:10 <TBB> I ended up writing a wrapper for that as well, since I like doing things in an overly complicated way...
18:12 <skarnet> meh, I was just hoping there was a way to integrate everything into abuild, but it looks like I'll need to do a lot of the ugliness myself
18:12 <ncopa> this download page is tricky
18:13 <ncopa> also, the description is an array with 3 lines
18:13 <Shiz> skarnet: it sounds like you're doing complicated shit
18:13 <Shiz> :P
18:13 <ncopa> i want it to be a single paragraph instead of fixed 3 rows
18:15 <skarnet> Shiz: I am, but I'm getting paid for it so that's ok :P
18:23 <TBB> same thing over here, I work in a restricted environment so I've had to implement lots of silliness just to get things done
18:24 <TBB> gladly I already wrote tools for doing silly things with CentOS so I just added an Alpine library, a couple hundred lines, and Alpine support was included
18:35 <TBB> so basically I can have an extra line for deps residing in tagged repos and my tool catches that, restores a build chroot snapshot, installs those deps and after that builds in the chroot
18:38 <TBB> but then of course, the solution closest to the correct would be to untag edge...
18:58 <ncopa> what do you think about this: http://wwwtest.alpinelinux.org/downloads/
18:59 <ncopa> i think the descriptions should probably be improved
19:01 <scadu> ncopa: buttons for archs different than x86 are broken
19:01 <ncopa> huh?
19:02 <ncopa> they work for me
19:02 <ncopa> did you refresh the css?
19:02 <_ikke_> for me to
19:02 <_ikke_> too
19:02 <scadu> I mean, they are distorted
19:02 <ncopa> shift-ctrl -r
19:02 <scadu> I know ;f
19:03 <ncopa> ok
19:03 <ncopa> i see it now in firefox
19:03 <jirutka> btw assets should be hashed (hash in the name), then there would not be that problem ;)
19:15 <ncopa> ok i think download buttons are fixed
19:15 <scadu> lemme check
19:16 <scadu> ncopa: confirm
19:22 <clandmeter> ncopa, i don't like it
19:23 LouisA joined
19:23 <clandmeter> I prefer a single do button
19:23 <clandmeter> Dl....
19:37 <clandmeter> ncopa, and why move to a paragraph for selling points?
19:37 <Shiz> i think the selling points really need redoing
19:38 <clandmeter> im not discussing the content, just the layout.
19:38 <clandmeter> if its a selling point, it should be a single line.
19:39 <Shiz> well, i am discussing the content too
19:39 <Shiz> :P
19:39 <clandmeter> sure, go ahead :)
19:39 <clandmeter> i never really liked most of them
19:40 <clandmeter> but nobody at the time gave me alternatives
19:43 <clandmeter> i think a single row of DL/Release shaX GPG would be enough, when you hover/click them it would open a a menu will all arch's
19:44 <clandmeter> this way all flavours would have the same height.
19:49 <Shiz> https://txt.shiz.me/ZTJiYmFjYz
19:49 <Shiz> my proposition for selling poinst (+ changed order)
19:49 <Shiz> only thing I'm struggling with is raspberry pi
19:51 <Shiz> https://txt.shiz.me/MGRlYTEzYj updated
19:52 <clandmeter> why the , and . differences?
19:54 <Shiz> standard gets an extra line because it's the base and two commas would look awkward there
19:54 <Shiz> the rest has no dots?
19:56 <clandmeter> i mean std yes
19:56 <Shiz> although imo generic arm should just be merged with standard
19:57 <Shiz> or vanilla, maybe
19:57 <Shiz> i see no reason for them to be different
19:57 <clandmeter> its not an iso i guess
20:26 <tmh1999> ncopa : I think I get alpine s390x running on KVM. Full virtualization cat /proc/cpuinfo inside KVM the same as in the host. afaik IBM pushed KVM support really good, as good as their mainline virtualization tech (z/VM) which is the original virtualization tech since the 70s
20:27 <tmh1999> I will try to build things, when it is good enough, we might make it the builder :)
20:27 <tmh1999> *I got it runnin
20:30 <jirutka> TemptorSent: kaniini: can we already keep old kernel + modules when upgrading kernel to newer version?
20:47 <kaniini> jirutka: no
20:48 <kaniini> jirutka: the vmlinuz and so on files need to be versioned
20:48 <jirutka> kaniini: what are the blockers?
20:48 <kaniini> jirutka: and the APK itself needs to be versioned in some way (e.g. in the name)
20:52 <jirutka> kaniini: full version number in pkg name is not very nice :/
20:52 <Shiz> kaniini: i've been running into issues with apk not installing build deps properly
20:52 <kaniini> uh oh
20:52 <kaniini> a bug report
20:52 <* kaniini> vanishes!
20:53 <Shiz> i have a sneaky suspicion that abuild or apk only install makedepends for the host when they are not installed on builld yet
20:54 <kaniini> honestly the way abuild traces what deps to install is kinda odd
20:54 <kaniini> and yes
20:55 <kaniini> it checks to see what is already there and filters that out
20:55 stwa_ joined
20:55 <Shiz> but
20:56 <Shiz> i want it to install something into the host sysroot, doesn't matter if the build system already has it
20:56 <Shiz> because /usr/lib/zlib.a won't help me when i want ~/sysroot-x86/usr/lib/zlib.a
20:56 <Shiz> :P
20:57 <Shiz> and it's because get_missing_deps only operates on the system apk
20:57 <Shiz> i think?
20:57 <Shiz> gonna debug this some more
21:00 <skarnet> Shiz: does abuild officially support cross-compilation now?
21:01 <Shiz> it has for a while, it's how we bootstrap stuff
21:02 <skarnet> so I just read triples in CBUILD and CHOST?
21:04 <jirutka> ncopa: there’s another blog post (in Czech) about Alpine Linux! it’s about usage of various distributions on vpsFree, Alpine Linux is mentioned as the distro with the highest increment per year https://blog.vpsfree.cz/linuxove-distribuce-vede-debian-a-ubuntu-nahoru-se-dere-alpine/
21:05 <jirutka> could please someone review https://wiki.alpinelinux.org/wiki/Setting_up_disks_manually, fix outdated info, if any, and remove “This material is work-in-progress ...” ?
21:05 <Shiz> skarnet: that's what you set when building, yes
21:06 <Shiz> the apkbuilds need makedepends= separated into makedepends_build and makedepends_host
21:06 <jirutka> someone (IMO troll) in a discussion about article at root.cz about Alpine has complained about it…
21:08 <jirutka> ncopa: it’s also interesting that Alpine is installed on more VMs at vpsFree than OpenSUSE or even Arch Linux and it’s very close to number of Fedora installations :)
21:10 <Shiz> who would install arch on a server :p
21:10 <* Shiz> runs
21:10 <Shiz> kaniini: may have been an error on my part, disregard
21:11 <jirutka> well, I asks who would install Debian or Ubuntu on server and yet, the most ppl :(
21:11 <Shiz> hey jirutka could you test something for me if you have cpu cycles to burn
21:11 <Shiz> :P
21:11 <jirutka> Shiz: yeah
21:21 <Shiz> jirutka: great
21:22 <Shiz> jirutka: https://txt.shiz.me/MWRjMmEzNj
21:22 <Shiz> this, essentially
21:23 <Shiz> oh, uh
21:23 <Shiz> # cd main/libc++ && abuild -r && cd .. , too
21:23 <Shiz> https://txt.shiz.me/MDMxZmQ5OT
21:23 <Shiz> updated
21:24 <jirutka> Shiz: how many CPU cycles does it need? ;)
21:24 <Shiz> uuh
21:24 <Shiz> considering it will compile both llvm4 and clang? :P
21:24 <Shiz> twice, because it also will cross-compile it in bootstrap.sh
21:25 <jirutka> you’ve missed dependencies ;) abuild-tar.c:20:25: fatal error: openssl/evp.h: No such file or directory #include <openssl/evp.h>
21:27 <jirutka> hm, it wants to overwrite some of my system files
21:27 <jirutka> so I should run it in a separate container
21:27 <Shiz> yeah
21:27 <Shiz> what apkbuild is that?
21:27 <Shiz> or do you mean the abuild repo
21:27 <Shiz> because yeah that needs libressl-dev and something else
21:30 tmh1999 joined
21:32 gromero_ joined
21:38 <Shiz> hmm, issue in the go package
21:38 <jirutka> burn it, burn it with fire!
21:40 <Shiz> no, it was my own doing
21:41 <jirutka> nevermind, still burn it, just for sure :P
21:42 tmh1999 joined
22:25 hanez joined
22:54 dfs joined
22:57 <tmh1999> Since syslinux is only supported on x86*, how would we do fresh installation (running setup-alpine, setup-disk) on disk (choose sys in sys, data, lvm) on other arches ? https://git.alpinelinux.org/cgit/alpine-conf/tree/setup-disk.in#n811
22:59 rdutra joined
23:00 <Shiz> I'm not sure if other arches have a unified booting method
23:00 <Shiz> ARM sure doesn't
23:01 <Shiz> which leaves ppc64le and s390x, if they do it would be useful to add :)
23:02 <Shiz> jirutka: https://txt.shiz.me/NjQ0ZjFkMT
23:02 <Shiz> easy script you can just run
23:02 <Shiz> in a container as root
23:02 <Shiz> :P
23:02 <Shiz> correction: https://txt.shiz.me/ZTc2ZDdiY2
23:04 <tmh1999> Shiz: So aarch64, armhf maintainers don't install on disk ?
23:04 <tmh1999> I am wondering how leitao installed the ppcle64 builder
23:04 <tmh1999> for now I boot s390x using the kernel + initfs along with a modified minirootfs
23:05 <tmh1999> it "looks" like a disk (sys) installation.
23:31 <tmh1999> aarch64 uses gummiboot ? hum...
23:33 <Shiz> i guess aarch64 can be efi booted yes
23:41 <awilfox> some aarch64 SoCs do use EFI
23:41 <awilfox> one being the HTC One M9 phone
23:41 <awilfox> the rpi3 and pine64 use uboot though