<    March 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 _2_4 25  
26 27 28 29 30 31
00:26 <jirutka> uff, I’m dead; I hoped that I’ll respond to the email about Soft commits right today (actually yesterday, it’s AM), but must to postpone it
00:28 <jirutka> just tl;dr here: I disagree with that idea for multiple reasons; one of them is that it does not actually solve the root problem; and we can already solve it in a better, more automated way
00:31 <jirutka> we already have integration with Anitya, so we get notified when package is outdated and should be bumped; so instead of emailing maintainers that the they should manually run abump, we can automatically bump it, open PR, let CI build it and then send email to maintainer to check it out
00:32 <jirutka> IIRC that’s what Fedora currently do
00:34 <jirutka> there are still some missing pieces; we need to improve the script that checks version of .so libs to really compare them instead of just printing diff, then we can also automatically bump dependent packages
00:37 <TemptorSent> jirutka: Essentially something looking like lddtree paired with apk info -W?
00:38 <jirutka> few weeks ago we’ve added support for check() into abuild; eventually we can let *some* pkgs automatically bump and merge without human intervention; I see this as final target
00:38 <jirutka> TemptorSent: yes
00:38 <jirutka> TemptorSent: currently we have https://github.com/alpinelinux/abuild/blob/master/checkapk.in
00:38 <TemptorSent> jirutka: Okay, I'm becoming painfully familiar with that o late :)
00:39 <TemptorSent> (lddtree, not checkapk)
00:39 <jirutka> TemptorSent: but it’s far from being really useful for any automation
00:39 <jirutka> TemptorSent: great, I would be happy if you can take care of this :)
00:40 <TemptorSent> jirutka: I'm currently able to extract the deps for a given set of files in a script easily enough, but the issue is on the apk side -- there's no easy way that I know to feed it a list of files and get a string of packages back.
00:40 <jirutka> TemptorSent: Travis runs this checkap script at the end of build, but currently one must read the log and understand what is ABI breakages and what is not
00:41 <jirutka> TemptorSent: actually there is, for so libs
00:41 <TemptorSent> jirutka: At least the easy cases should be able to be handled with some heuristics on the version numbers and possibly hashing the old/new function definitions.
00:42 <jirutka> TemptorSent: IMHO version number of so lib should be good enough
00:42 <TemptorSent> jirutka : Where is the hidden flag to feed libnames and get packages?
00:43 <TemptorSent> jirutka: I mean for determining if a given bump breaks the api/abi
00:43 <jirutka> TemptorSent: this is output of checkapk https://travis-ci.org/alpinelinux/aports/builds/212898578#L1939
00:43 <jirutka> TemptorSent: and here you can see that abuild detects dynamic links https://travis-ci.org/alpinelinux/aports/builds/212898578#L1825
00:44 <jirutka> TemptorSent: you can `apk search so:libglib-2.0.so.0` → glib-2.50.3-r0
00:45 <TemptorSent> jirutka: Well that's damn useful to know!
00:46 <TemptorSent> jirutka: Can I feed it multiple .sos and get a list of all packages required to meet that dep?
00:46 <jirutka> TemptorSent: "possibly hashing the old/new function definitions" … how difficult and reliable is this?
00:47 <jirutka> yes
00:47 <TemptorSent> jirutka: A simple sanity check should be straightforward, real analysis is another story, but would be worth while long term for both versioning and security auditing.
00:47 <jirutka> TemptorSent: `apk search so:libglib-2.0.so.0 so:libintl.so.8` → libintl-0.19.8.1-r1 glib-2.50.3-r0
00:47 <TemptorSent> Excellent!
00:48 <TemptorSent> And does that query the APKINDEX, or does it only work against installed packages?
00:48 <jirutka> TemptorSent: it queries APKINDEX
00:48 <jirutka> TemptorSent: these so:xxx are "provides"
00:48 <jirutka> TemptorSent: eh, pardon
00:49 <jirutka> TemptorSent: this list of so:xxx on Travis are tracked dependencies
00:50 <jirutka> TemptorSent: and e.g. so:libglib-2.0.so.0 is specified in glib-2.50.3-r0 as "provides"
00:50 <TemptorSent> Okay, what I'm wondering is where they are coming from where apk search is finding them.
00:50 <jirutka> TemptorSent: must go sleep, too tired
00:50 <TemptorSent> jirutka: Alright, thanks for the tip!
00:50 <jirutka> TemptorSent: they are detected during build and stored in APKINDEX
00:51 <TemptorSent> jirutka: Got it, thank you! Are the files indexed anywhere except on the web interface?
00:51 <jirutka> TemptorSent: you mean complete files list of the pkg?
00:51 <TemptorSent> jirutka: Yes.
00:52 <TemptorSent> If so, I could look up which packages I need for not just my lib deps, but my kernel modules, firmware, and userspace too.
00:52 <jirutka> TemptorSent: unfortunately no, this is currently only in aports-turbo (pkgs.a.o); but if fabled hasn’t changed his mind about it, there should be index for them in new apk
00:53 <TemptorSent> jirutka: Okay, I suspected it was something like that.
00:54 <jirutka> TemptorSent: this ABI breakage is basically only for C/C++ stuff with dynamic linking
00:54 <TemptorSent> jirutka: If we could store that index as a git tree or similar, it would take care of both the versioning issue and security auditing.
00:54 <TemptorSent> jirutka: Right, that should be detectable either through function fingerprints on the front side or looking at the symbol definitions on the output.
00:55 <jirutka> TemptorSent: btw is it possible to somehow detect what libraries are statically compiled in some binary?
00:57 <TemptorSent> jirutka: You could probably get it with a run through strings against a list of known fingerprints.
00:58 <jirutka> TemptorSent: this would be also awesome for auditing :)
00:59 <TemptorSent> jirutka: At least some idea of when things are likely to break or have changed in unexpected ways.
00:59 <jirutka> going sleep, good night :)
01:01 <^7heo> Say
01:01 <TemptorSent> jirutka: the --save-temps CFLAG + find + strings + awk should do the heavy lifting.
01:01 <TemptorSent> jirutka: Goodnight!
01:01 <^7heo> how does alpine knows where to load the apkovl from in the case of an LBU setup?
01:02 <^7heo> I found LBU_MEDIA=usb in /etc/lbu/lbu.conf
01:02 <^7heo> but I don't see how it's enough
01:03 <TemptorSent> Actually, even better is probably running things through readelf if appropriate
01:03 <TemptorSent> That takes care of linktime issues too
01:04 <TemptorSent> ^7heo : init looks for it in a few places, and if ONE overlay is found on the media root, loads it.
01:05 <TemptorSent> (at least that's what I was able to find... I'll have to poke at that when I get into init)
01:05 <^7heo> yeah ok but if there are many
01:05 <^7heo> the loading order might be totally random
01:06 <^7heo> anyway
01:06 <^7heo> time to hit the hay
01:19 <TemptorSent> jirutka: When you wake back up, take a look at gccxml
01:21 <TemptorSent> jirutka: I guess that's now CastXML
01:40 <TemptorSent> Random query, but has transitioning to llvm/clang sprung up in discussion?
01:40 <TemptorSent> Much of our static analysis and auditing needs would be more easily met using that architecture I believe.
01:45 <kaniini> jirutka: there's other motivations than just abump
01:47 <kaniini> jirutka: the goal is to get more people directly involved in the distribution as proper developers, instead of just maintainers
01:50 <TemptorSent> kaniini: It seems that fixing the git server logic to deal with ACLs in a sane manner is the best approach.
01:50 <TemptorSent> It almost begs for ldap, but that idea makes me a bit queezy.
01:51 <kaniini> jirutka: another motivation is, well, frankly, what happens when the VCs call on their github options and github goes out of business? while github is a good contribution channel, it should not be the only channel
01:52 <TemptorSent> kaniini: That is a major concern, and one which will take significant effort to mitigate considering the number of projects using the resource.
01:53 <kaniini> right, but we do not need to put ourselves in the same trap
01:53 <TemptorSent> kaniini: Would following github's user framework style be a viable option?
01:54 <TemptorSent> kaniini: Right, I'm more looking at how many deps would be involved as well.
01:54 <kaniini> but the point overall is
01:55 <kaniini> there needs to be an intermediate step for those who are 70-80% of the way to becoming a proper dev
01:55 <kaniini> that allows them to become more familiarized with the core infrastructure
01:55 <TemptorSent> Teach our infrastrucure to understand git://git.alpinelinux.org/USERNAME/...
01:55 <TemptorSent> And allow users to manage their ssh keys similar to how github does.
01:56 <kaniini> that's an infrastructure concern, i am mainly trying to advance the policy side of it right now
01:56 <TemptorSent> Then the acl becomes on a local user who can authenticate using ssh or whatever we might need in the future.
01:56 <kaniini> i'm the last person on the planet you would want to ask about infrastructure concerns around here ;)
01:57 <TemptorSent> policy and infrastucture are so closely tied it's almost impossible to split.
01:57 <TemptorSent> If your infrastructure can't do it, your policy demanding it is useless :)
01:57 <kaniini> in this case, it is possible, because the policy question is
01:58 <kaniini> should we have an additional step in the process where the system treats a maintainer as having full rights to their packages
01:58 <kaniini> it's already established that gitolite can do this through subtree policy configs
01:59 <TemptorSent> kaniini: That's the highlevel question, the deeper question is can a package maintainer sanely have full rights to their package, which depends to some extent on the systems ability to detect errors.
02:00 <kaniini> sure, but i cite that even normal alpine devs fuck up and introduce errors from time to time
02:02 <TemptorSent> *lol* Of course. The hopes is that a system capable of detecting most breaking errors would save the devs too :)
02:04 <TemptorSent> But if a handfull of devs can bring down the world in a matter of minutes, just imagine what several hundred maintainers making subtle errors could do LONG TERM.
02:05 <TemptorSent> If the devs could restrict themselves to the same sandboxe except when they need to deal with a specific breakage, the whole ball of wax would be more stable and reliable.
02:07 <TemptorSent> In other words, all pushes staging through a CI process before being committed, and doing some symbol auditing to make sure we're not breaking rdeps
02:10 <kaniini> i don't disagree with that, but it's not directly related to the policy proposal in question :p
02:12 <kaniini> in other news, congrats to leitao and tmh1999 who should have push access soon if not already :P
02:19 <TemptorSent> kaniini: I guess the s390x project is moving apace then?
02:20 <awilfox> I thought the first person was doing ppc64le, though I could be confused
02:20 <TemptorSent> awilfox: I believe you are correct.
02:21 <kaniini> yes
02:22 <kaniini> it is very likely that s390x will meet the 3.6 cutoff
02:23 <TemptorSent> Excellent! It's already in mkimage whenever someone wants to throw me the details for what it needs in way of modules/kernel/etc.
02:23 <kaniini> tmh1999: ^
02:24 <TemptorSent> He's in a discusion on -linux
02:24 <TemptorSent> tmh1999: *ping* -- see -devel :)
02:24 <kaniini> he's the guy to ask :)
02:25 <TemptorSent> Yeah, he's not paying attention here right now it looks like ;) Quick, while he's not looking, give him another project!
02:30 lucybun joined
02:31 lucybun joined
02:33 <tmh1999> TemptorSent : no...
02:33 <tmh1999> kaniini : Thanks :)
02:33 <tmh1999> I was debuging a bug in ocaml, possbily in musl
02:34 <TemptorSent> tmh1999: I guess that qualifies as project! What did you end up at, bad definition?
02:34 <tmh1999> kaniini : Yes I was expecting s390x packages to be online on 3.6. ncopa was setting up the s390x builder today after he finished the ppc64el
02:35 <tmh1999> TemptorSent : the s390x musl porter merged some struct, which was supposed to be split out to match kernel struct
02:35 <TemptorSent> tmh1999: What will be needed to populate a s390x image?
02:35 <TemptorSent> Oops. Yeah, that'll break things on a rather different arch.
02:35 <tmh1999> s390x image is another story, and tbh, I am discovering too.
02:35 <tmh1999> no it's in arch/s390x/bits so no worry
02:36 <tmh1999> I am not sure if I can give you the exact answer right now for you so you can implement mkimage :(
02:36 <TemptorSent> Yeah, that's what I mean - hardware dependent structs do bad things when you expect them to work on a different platform.
02:36 <* kaniini> idly wonders where to get sh2/j2 hardware
02:37 <TemptorSent> tmh1999: No problem, I just want to give you what you need to work on the s390x stuff easier ASAP.
02:37 <tmh1999> *me look up the sky and mumble something
02:38 <tmh1999> TemptorSent : I cant think of some way to say thanks to you. Next time I am in west coast, probably this summer, I will buy a lunch or dinner :)
02:38 <TemptorSent> kaniini: Been a while since I looked, digikey/avnet probably have something, but prices might hurt :)
02:38 <tmh1999> * I will buy you
02:39 <kaniini> although sh4/j4 may be a better arch to support
02:39 <TemptorSent> tmh1999: I'll take you up on that if you're in the area - there are some great local eateries.
02:40 <tmh1999> TemptorSent : I am looking to it :)
02:40 <TemptorSent> When'd they come out with the sh-5 stuff? Is that part of the STM portfolio?
02:41 <TemptorSent> Or is it actually dead-on-arrival with no succession?
02:46 <TemptorSent> My SuperH experience goes back to the SH-1/SH-2 in appliances and automotive applications mostly.
02:46 <tmh1999> kaniini : I am wondering why people make so much hw arch ? Like, "Oh I make new arch because I can !"
02:47 <tmh1999> is that that much application fields out there to make so much arch ?
02:47 <TemptorSent> tmh1999: IP is a lot of it, the rest is application-specific needs.
02:48 <TemptorSent> tmh1999: Yes, especially when you get into VLSI and SoCs.
02:49 <TemptorSent> tmh1999: When you have a specific process you need to do as fast/reliably/low-power/whatever as possible, you tailor you entire architecture to that operation. Look at digicams for a good example.
02:50 <tmh1999> TemptorSent : I see. That's a lot of engineering hours.
02:50 <TemptorSent> tmh1999: That 4 bit, 6 pin microprocessor with a dozen registers might not look like much, but there are millions of them in use.
02:50 <tmh1999> looking for young programmers working on that must be hard
02:51 s33se_ joined
02:51 <tmh1999> young < 25, or < 30
02:51 <tmh1999> like, looking for young kernel programmers ...
02:52 <TemptorSent> tmh1999: Its a dying art -- now you have people using a rpi to do the same function I used to do on write-one chips.
02:53 <tmh1999> TemptorSent : haha
02:53 <TemptorSent> tmh1999: I don't think most new 'kernel programmers' would know a kernel if it bit them in the ass! Device drivers are nice, yes, thank you, move along.
02:54 <tmh1999> TemptorSent : yes it's actually dying art. I agree with your biting in the ass argument.
02:55 <tmh1999> TemptorSent : looks like our veterans already got bitten all
02:55 <kaniini> of course
02:55 <kaniini> i want an alpine vax port someday :p
02:56 <TemptorSent> while(1) { for task in task list, load context, run task, handle result}
02:56 <TemptorSent> Add anything to that, and you've got yourself a kernel :)
02:57 <tmh1999> I am actually laughing lol
02:57 <* tmh1999> laughing
02:57 <TemptorSent> Seriously, that's it.
02:57 <tmh1999> and guess what ? that's exactly what some college kids got educated in CS
02:58 <TemptorSent> And most never get it.
02:59 <TemptorSent> When you used to have to type your kernel AND monitor in each time you booted (or flip switches if you were really hard-core on a blue-box CDC), the concept of a kernel was pretty painfully clear.
02:59 <tmh1999> speaking of young programmers I pretty admire awilfox and her team
03:00 <TemptorSent> I've seen her on, but I'm afraid I haven't gotten to know her or anyone else particularly well as of yet.
03:00 <tmh1999> you must be around 40 or 50 TemptorSent ? You have a history with yourself
03:01 <TemptorSent> Still doubting I'll make 40, although it's getting damn close.
03:02 <awilfox> tmh1999: thanks for the flowers :) we are the last of the old generation maybe. in our late 20s now, old enough to appreciate the Old Days and embedded programming, but young enough to appreciate most people have evolved beyond "programmable ICs" (for lack of a better term) and towards running tiny Linux where a simple assembler "kernel" would have worked just two decades ago.
03:02 <TemptorSent> I got started early and got straight into electronics and programming.
03:02 <TemptorSent> Good evening awilfox, how are you doing?
03:02 <awilfox> I started at 4 years old, on my grandfather's PC XT clone, dabbling in ROM BASIC
03:03 <* tmh1999> hands down, we have all hardcore players here
03:03 <awilfox> TemptorSent: feeling better. was a bit sick yesterday due to overheating (30 C outside, with no cooling, and my desktop being on, made it near 40 C inside)
03:03 <TemptorSent> awilfox : Yep, similar age, a generation older hardware.
03:03 <awilfox> TemptorSent: how are you?
03:04 <TemptorSent> awilfox: I'm surviving anyway -- the years of being invincible catch up to you sooner than you might think :)
03:05 <awilfox> TemptorSent: as life-long diabetic, I have never known the feeling of 'being invincible', but I hear it's better for me in the longer run not to have known it.
03:05 <TemptorSent> awilfox: Ug, don't do that! I've had heat stroke, and it's nothing to laugh at -- it'll mess up your heat tollerance for life.
03:05 <awilfox> TemptorSent: heh, that ship sailed long ago. lived in Florida for a few years, what a mistake. now I sweat at even 25 C
03:06 <TemptorSent> awilfox: Yeah, I can't do the heat + humidity at all. I'm in northern Califonria up in the mountains, which is just about right most of the time.
03:07 <awilfox> mmm. nice! I'm in the foothills of the Ozarks, eastern Oklahoma.
03:07 <TemptorSent> Anyway, I'm glad you're feeling better.
03:07 <awilfox> thankfully, it is rarely humid. but it does get quite oven-like in summer.
03:07 <TemptorSent> awilfox: That's not anywhere near Sweetwater, is it?
03:08 <TemptorSent> Hmm, shall we take this to -offtopic perhaps?
03:08 <awilfox> 400 miles northeast, per maps
03:28 <kaniini> tmh1999: s390x is pretty hardcore
03:29 <tmh1999> kaniini : I am 1 year old in s390x
03:29 <tmh1999> kaniini : and yes s390x is super hardcore
03:30 <TemptorSent> *lol* gotta love those random epochs
03:37 <kaniini> i remember when this channel had approximately 5 people on it
03:37 <kaniini> and we had basically
03:37 <kaniini> no plan or clue what we were doing
03:37 <kaniini> okay maybe that hasn't changed
03:37 <kaniini> :D
03:37 <kaniini> i am kidding
03:38 <TemptorSent> *lol* I remember when #linux had 5 people on it logging on from a shell account on netcom :P
03:40 <TemptorSent> It's amazing just how far this whole industry has come in the past 20 years or so.
03:41 <TemptorSent> And it seems it's always the small groups of inividuals passing traffic or lurking irc who end up pushing real innovation.
03:43 <kaniini> oh, my involvement in this started out when i wanted a run from ram hypervisor environment and i had become sufficiently pissed off at debian
03:43 <kaniini> that was a decade ago
03:43 <TemptorSent> kaniini: That couldn't have taken long :)
03:44 <TemptorSent> kaniini: I moved to gentoo pretty much as it came into existence since I couldn't stand debian already by that pont.
03:44 <kaniini> TemptorSent: i used to maintain lilo in debian, i tried to propose a plan to retire it in a sane way
03:44 <kaniini> TemptorSent: this turned into an amazing shitshow
03:44 <TemptorSent> 'LI '
03:45 <TemptorSent> 'nuff said :)
03:45 <awilfox> http://i.imgur.com/OVbRg39.png http://i.imgur.com/GZQoe5r.jpg
03:45 <kaniini> TemptorSent: lilo in debian was taken away and given to a guy who basically blindly applied patches from other distributions without knowing what they did
03:45 <awilfox> that was first alpine box for me. well, first hardware. tried in a VM some months before.
03:46 <awilfox> hard to believe that was more than six years ago
03:46 <kaniini> TemptorSent: so after i decided i had enough debian for a lifetime, other people had told me about alpine
03:46 <kaniini> TemptorSent: so i decided to come see what ncopa had cooked up
03:47 <kaniini> and it was pretty good for at the time literally 2 guys
03:47 <kaniini> enough to convince me to do the original x86_64 port anyway :)
03:48 <TemptorSent> nice awilfox! I was on the leading edge of SMP linux with an early PPRO 200 dual processor configuration.
03:48 <awilfox> my first dual processor was Pentium 4. missed out testing that.
03:48 <awilfox> I did have a very early AMD64 box in 2005, the Venice Athlon64, and got to see suse snd fedora throw up on it...
03:49 <awilfox> suse and fedora*
03:49 <awilfox> the mainline kernel was okay, so that's around the time I stopped thinking distros know best for kernel config.
03:49 <kaniini> the irony being
03:49 <kaniini> if i didn't do that x86_64 port, alpine probably wouldn't have ever been known by anyone doing virtualization
03:50 <kaniini> because it wasn't really on the radar at the time
03:50 <TemptorSent> awilfox: Yeah, I was playing around with the DEC21264 and early amd64 as well when I got out of the business for the most part.
03:50 <kaniini> haha
03:51 <TemptorSent> kaniini: Good work - it's nice to see a distro that actually pays attention to details and can still move quickly.
03:51 <tmh1999> kaniini : so you and ncopa was the first 2 ?
03:51 <kaniini> no
03:51 <tmh1999> *were
03:51 <kaniini> ncopa and fabled were the first 2
03:51 <awilfox> TemptorSent: mmm, the Alpha 7? that was one of the first chips with OOE iirc
03:52 <kaniini> i guess i was the third person to start doing really heavy core stuff, like the x86_64 port, and the initial xen packaging
03:52 <kaniini> :P
03:52 <awilfox> ah, not the first with OOE, but a very early example of having large deep pipelines
03:52 <TemptorSent> awilfox: Yup, superscalar pipelines, out of order execution, matrix math, 64 bit VM space - yes please!
03:53 <TemptorSent> kaniini: Oh, and my appologies for what I did to xen in mkimage ;)
03:53 <awilfox> matrix math on die is crazy, but really, AXP in general is crazy
03:54 <kaniini> TemptorSent: xen support these days is mainly maintained by the xen people themselves
03:54 <awilfox> oh, that's right... the 21264 had dedicated rename registers
03:54 <kaniini> you see, the xen community needed a run from ram hypervisor solution, and alpine as dom0 solves that quite nicely
03:54 <TemptorSent> awilfox: I added ppc/ppc64le to the known archs for you (as well as s390x for tmh1999 ) in my branh of mkimage, so please let me know what you need to support building functional images for ppc64le
03:55 <tmh1999> TemptorSent : I noted that :)
03:55 <kaniini> i'm not sure adelie will use mkimage and friends or not
03:55 <kaniini> that is up to awilfox of course
03:55 <awilfox> mkimage is for?
03:55 <awilfox> never even used it / read about it myself
03:55 <tmh1999> I am finalizing my musl/ocaml patch atm
03:56 <kaniini> it's the new system image building tools for alpine
03:56 <kaniini> it leverages apk more properly than the old stuff
03:56 <TemptorSent> awilfox: Yeah, it was rather revolutionary at the time -- intel was trying with itaniaum and SGI, HP, and some of the other big HW companies at the time made a play that failed.
03:56 <kaniini> meant to be more generic, too
03:56 <awilfox> TemptorSent: and what of ppc64 non-LE?
03:56 <kaniini> apk-tools calls that ppc64
03:57 <awilfox> not that musl is necessarily letting me target it
03:57 <kaniini> so adding it to mkimage should be easyish
03:57 <TemptorSent> It's only recently that the tech that was common on DEC/MIPS R-Series/Cray is becoming available.
03:57 <TemptorSent> oh, didn't see any kernel for ppc64, sorry - let me ad thta.
03:57 <kaniini> there is no alpine ppc64 support except ppc64le, musl only supports ppc64le
03:57 <awilfox> TemptorSent: still snuggling my octane to sleep every night XD never got an O2, they are still going for absurd money
03:58 <awilfox> kaniini: musl supports ppc64, the problem is they use a broken ABI
03:58 <kaniini> doesn't sound supported to me! :p
03:58 t0mmy joined
03:58 <awilfox> it manages to fork and exec busybox
03:58 <awilfox> but a lot of low level packages get confused
03:58 <awilfox> such as binutils
03:59 <awilfox> and elfutils, and paxutils
03:59 <kaniini> paxutils is trash tho
03:59 <kaniini> i wouldnt worry about that one :p
03:59 <awilfox> and unfortunately you need those things to build an adelie or an alpine
03:59 <awilfox> kaniini: scanelf is unfortunately necessary
04:00 <awilfox> unless you are aware of an alternative that accomplishes the same task
04:00 <TemptorSent> Pushed :)
04:00 <awilfox> TemptorSent: thanks. I will look this weekend probably, maybe I can replace adelie-build-cd with mkimage.
04:01 <kaniini> it would enable you to have the run-from-ram stuff for free
04:01 <awilfox> which is this -> https://code.foxkit.us/adelie/image/tree/master if you have not yet seen it
04:01 <TemptorSent> awilfox: Yeah, I'm ticked that I didn't pick up an O2 when I had the chance - my aunt worked for SGI in their hayday and I got to play with a lot of cool hardware, but never plonked down for it.
04:02 <awilfox> terrible hacky shell
04:02 <awilfox> portable to bash/ksh/zsh/busybox sh though!
04:02 <awilfox> but still terrible...
04:02 <awilfox> so, I will investigate mkimage as a replacement
04:03 <TemptorSent> mkimage should be almost entirely portable (it uses a couple bashisms suppored by BB such as ${var//s/re/}, but not too ugly
04:03 <TemptorSent> I also did my best to actually comment the code and format it in a logical manner, so hopefully it's usefull even without docs yet.
04:05 <TemptorSent> The adelie-build-cd stuff doesn't loo too horrible.
04:06 <awilfox> TemptorSent: I come from the land of thoroughly OCD C code (my last project had a 100% doxygen rating) and Python so meticulously formatted that pylint reports a perfect 10/10 score.
04:06 <awilfox> TemptorSent: all shell is terrible and hacky :(
04:07 <awilfox> well that is not true. parts of abuild and ebuild both have elegance.
04:07 <TemptorSent> awilfox: *LOL* Oh, you missed the bad old days of the bourn shell/csh/ksh wars.... you had to write just about everything at least three ways, more if you were trying to target both BSD and SYSV
04:07 <awilfox> but I am not up to that standard yet.
04:07 <awilfox> TemptorSent: I came in on the tail end of that. csh was mostly dead, but bash and ksh were still vying.
04:08 <TemptorSent> awilfox: Yeah, I still have a bit of work to do with removing the vestigal traces of the doner utilities and get everything consistent.
04:09 <TemptorSent> bash and ksh will mostly interoperate if you're careful, and tcsh was much more compatible than csh, so it got better.
04:10 <awilfox> people always yell at me for testing in zsh saying who needs a fourth type.. not realising it's almost bug compatible woth ksh 92.
04:10 <TemptorSent> awilfox: But the only part that actually does anything important is the plugin loader, the rest is mostly braindead
04:10 <awilfox> with*
04:10 <TemptorSent> Yeah, zsh is a funny one.
04:11 <TemptorSent> It'll catch you sleeping when everythign is working otherwise normally, usually when it comes to signals.
04:13 <awilfox> TemptorSent: it was a battle at first trying to pick the system shell for Adélie. we had the people yelling for busybox because lightweight, bash for compatibility, and zsh for speed and features.
04:13 <awilfox> finally I just said let's let the user choose in the installer.
04:13 <awilfox> then it became a battle of what would be default.
04:13 <TemptorSent> awilfox: Yeah, support the minimum configuration and let the user choose the rest.
04:14 <TemptorSent> Let them pick their flavor, who cares :) That's why we have build-bots.
04:14 <awilfox> unfortunately it ended up bash selected by default. I was firmly not in that camp, but to corrupt a pop culture reference... users gonna use.
04:15 <TemptorSent> *lol* Ouch, yeah -- bash is good for big, heavy, user-interactive stuff mostly, not good for anything even remotely light weight.
04:16 <awilfox> I managed to get bash to squish down into 800K RAM
04:17 <awilfox> but the main case for Adélie is desktops and end user systems like kiosks. not necessarily light weight servers like Alpine
04:17 <awilfox> the whole of a KDE desktop fits in just 106 MB RAM in Adélie thanks to the beautiful musl libc.. and the hard work of the Alpine devs making a lot of the libs work (though porting KDE to musl was a joy I got to experience alone)
04:18 <TemptorSent> There are a couple featues I'd really like to see available in bb in a bash-light type flavor, with the rest of the pattern matching, the basic arrays, and ESPECIALLY the += operator :)
04:18 <awilfox> I guess it depends on use case. for me, I like to try and go for lowest common denominator - but my shell stuff is usually bootstrap related
04:21 <TemptorSent> awilfox: *wince* I was running my entire business with hundreds of hosted clients, a database server, news, mail, ftp, web, php/fi (and later php), a high performance X server, and sundry on the aforementioned dual PPRO-200 with *128MB* of total RAM, and only hit swap when I really swampped the database with a stupidly high transaction load.
04:23 <awilfox> TemptorSent: the P II above had 192 MB RAM and no swap
04:23 <awilfox> managed to have pidgin and midori running with a few tabs each
04:23 <awilfox> and enough left over for mrxvt
04:23 <TemptorSent> awilfox: Yeah, in the bootstrap environment, I aim for pretty much posix-compliant or universally available.
04:23 <awilfox> TemptorSent: https://bpaste.net/show/58506994410c this is my first bootstrap shell script ever
04:23 <awilfox> 2009, suicide.sh
04:24 <awilfox> named because that is what you want to do when you run linux cross compiler on OS X Leopard
04:24 <awilfox> it all worked though :)
04:24 <TemptorSent> awilfox: Yeah, I wasn't taking it easy on the X-server, I was running Number9 Imagine128 backing Viewsonic's top of the line at the time.
04:26 <awilfox> mmmmm
04:26 <TemptorSent> *lol* Nice, I like the comment for the workdir :)
04:26 <awilfox> I remember those. gorgeous displays.
04:27 <awilfox> was it XFree86 or were you running something like Xsun?
04:27 <TemptorSent> Yeah, I was looking at 1600x1200 in the rear-view-mirror when I wanted to push a lot of text. My eyes were MUCH better then :)
04:27 <awilfox> I know Solaris ran on those ppros
04:27 <awilfox> heh. I have severe astigmatism so I have to wear glasses anyway.
04:27 <TemptorSent> XFree86 -- I was on the bleeding-edge dev team working on accelerating it at the time (DRI/DGA)
04:28 <awilfox> maybe I am a cheater but I end up with 9pt ProFont on 1080p display
04:28 <awilfox> without glasses I struggle at 14pt
04:29 <tmh1999> kaniini, TemptorSent : would you mind a minute ? http://tpaste.us/oZPR. Should I send to musl ml first ?
04:29 <TemptorSent> awilfox: Yeah, I was running 8pt font at 2048x1536 on at 20" display.
04:30 <awilfox> TemptorSent: I would have killed for that res back then! I always ran my 19" trini at 1800x1050 or whatever that fancy mode was.
04:30 <awilfox> maybe 1600x1050?
04:30 <TemptorSent> tmh1999: looking at it.
04:31 <TemptorSent> awilfox 1600x1200 was a standard high-resolution-modeline
04:31 <awilfox> it was a bit different aspect ratio. long long time ago.
04:31 <TemptorSent> at 60-90hz depending on your bandwidth.
04:31 <awilfox> had to write custom modelines for XF86 3.3 to make it drive my mach64 at that res.
04:31 <TemptorSent> 1856x1392 perhaps?
04:31 <awilfox> very likely
04:32 <awilfox> yes, I think that was it. it pushed the very limit of the 32MB VRAM
04:32 <awilfox> and that seems to be 11 MB of raw framebuffer (texture memory was included in the 32 back then iirc)
04:33 <TemptorSent> Yup, I think I had to resort to 24BPP packed buffers to actually have backing store at full res.
04:35 <TemptorSent> It took the fixing of the damage exentsion and some early compositing before it was actually comfortable even though it had the hardware. XF86 was a mess around then, with about as much broken as not.
04:36 <TemptorSent> Mostly because it wasn't just xfree86, but the entire xfree tree, incuding every platform known to man.
04:37 <awilfox> and yet it still had fewer segfaults than modern mesa :D
04:38 <tmh1999> TemptorSent : Well technically the musl patch is no need. Then in ocaml patch we just need 'sc_mcontext' instead of 'context->sc_mcontext'.
04:39 <tmh1999> hah $ ocamlcp segfault
04:44 <TemptorSent> Okay, so one less layer of pointer indirection replacing the sregs?
04:45 <tmh1999> yep I am building
04:46 <TemptorSent> And the local struct definition? Is there an ifdef protecting that definition to avoid conflicts if you run into an os implementation?
04:46 <tmh1999> which one ?
04:46 <TemptorSent> the struct sigcontext, is the a #ifndef SOMEDEFINE before that else?
04:47 <tmh1999> seems not. btw I am trying to remove the musl patch.
04:47 <tmh1999> let me fix
04:47 <tmh1999> the one I sent you build ok but segfault.
04:47 <tmh1999> nvm :)
04:47 <tmh1999> thanks btw :)
04:48 <TemptorSent> awilfox: Yeah, and it might take out my x-server, but the worst I had to do was ssh in from another box and clean up after myself, then reboot when all was quiet.
04:51 <TemptorSent> tmh1999: Follow the local convention, but it's generally good practices to put a #ifndef _SOME_SYMBOL_\n#define _SOME_SYMBOL_ ..struct.. #endif wrapper anywhere you might have conflicts, and possibly do a #ifdef on the struct itself, depending on your exact environment.
04:53 <TemptorSent> so what would be sregs on normal archs are virtual gregs on s390x then?
04:53 <tmh1999> TemptorSent : I understand
04:54 <tmh1999> sregs are defined on asm/sigcontext.h
04:54 <tmh1999> glibc includes asm/
04:55 <tmh1999> then ocaml dev follows the order/layout in asm/sigcontext.h
04:55 <TemptorSent> This is via sys/ucontext.h?
04:55 <tmh1999> Yeah the idea is to include libc's ucontext rather than include asm/
04:55 <TemptorSent> Double check the pointers there, I can't put my finger on it, but something seems off.
04:56 <tmh1999> Yeah, I keep musl as is. only change ocaml. still segfault
04:57 <tmh1999> I guess I am gonna do my school work and take a nap ...
04:57 <tmh1999> see you tmr TemptorSent
04:57 <TemptorSent> Okay, so we've got a 4 bit register mask here it appears, 0-15
04:58 <TemptorSent> What are those addresses actually pointing at and how are they assigned? It looks like something is missing.
05:00 <tmh1999> TemptorSent : I will gdb it tmr
05:01 <TemptorSent> Did you check features.h as well?
05:02 <TemptorSent> In other words, is everything defined to get a consistent build?
05:02 <tmh1999> I suppose so
05:02 <tmh1999> let me #include <signal.h> instead of <sys/ucontext.h>
05:03 <TemptorSent> And does it follow /usr/include/asm-generic/ucontext.h?
05:05 <tmh1999> no #include <sys/ucontext.h> includes /usr/include/sys/ucontext.h
05:05 <TemptorSent> uc_flags(long) struct uc_link(struct *ucontext) uc_stack(stack_t) uc_mcontext(struct sigcontext) uc_sigmask(sigset_t) is what Im seeing in asm-generic...
05:05 <tmh1999> which in turn includes /usr/include/ucontext.h
05:06 <TemptorSent> So do all types at least line up?
05:06 <tmh1999> Yeah I suppose. Where do you get the above code ?
05:07 <tmh1999> asm-generic.h ?
05:07 <TemptorSent> on x86_64, /usr/include/asm-generic/ucontext.h
05:07 <TemptorSent> I typed the summary, take a look at the def.
05:08 <TemptorSent> It looks strange using the sc_mcontext in the manner it's being used.
05:09 <TemptorSent> so make sure that sigcontext actually matches what you've assigned.
05:10 <tmh1999> I guess /usr/include/asm/ucontext.h is the one
05:10 <TemptorSent> on x86 it's just a single define and an include to asm-generic/ucontext.h
05:11 <tmh1999> http://tpaste.us/jenq
05:11 <TemptorSent> UC_FP_STATE -> 0x1
05:12 <TemptorSent> do you get a bt?
05:13 <TemptorSent> But that looks like ti might be a symbol table issue?
05:13 <tmh1999> http://tpaste.us/DkMq
05:13 <tmh1999> lol
05:14 <TemptorSent> Okay, that's a bit better. Looks like the vector is wrong since the SP is stuck.
05:15 czart__ joined
05:16 <TemptorSent> Is 0x3ffffffbf0 a magic or is that top of address - stack?
05:18 <TemptorSent> Regardless, it's getting a 0 written to the SP, which is what's giving the segv
05:19 <TemptorSent> No security features enabled like stack-smash-protection or anything, right?
05:19 <tmh1999> no
05:20 <tmh1999> probably I screw up the definitions
05:20 <tmh1999> of structs
05:20 <TemptorSent> My bet is bad defs, not necessarily your fault.
05:21 <TemptorSent> Let's see if the redbook sheds any light on it right off
05:22 <TemptorSent> Not so much
05:24 <TemptorSent> I'm looking at the kernel tree in arch/s390/include/uapi/asm/ucontext.h -- it looks like the defs in the headers are bogus.
05:25 <tmh1999> how so ?
05:26 <tmh1999> _sigregs is defined in arch/s390/include/uapi/asm/sigcontext.h, fyi
05:26 <TemptorSent> Note the extended context.
05:28 <TemptorSent> Where is gregs coming from
05:30 <TemptorSent> It looks like it should be sregs->regs->gprs
05:30 <tmh1999> http://git.musl-libc.org/cgit/musl/tree/arch/s390x/bits/signal.h#n31
05:30 <tmh1999> yeah that's the idea if you include <asm/sigcontext.h>
05:31 <tmh1999> which is a bad idea
05:31 <tmh1999> well I have to say the s390x porter cooked up some part
05:31 <tmh1999> he merged 2 struct in the kernel and make them into the bits/signal.h
05:32 <TemptorSent> Yeah, if your lib doesn't reflect your actual kerenel, it won't work.
05:32 <tmh1999> technically the structure are the same, but the names are diff
05:32 <tmh1999> yes, so the lib actually reflect the kernel
05:32 <tmh1999> technically,
05:32 <tmh1999> chances are, I might mix up some of his mix ...
05:33 <TemptorSent> unsigned long, unsigned, double... WTF?
05:35 <TemptorSent> Yeah, I think this one is going to take some real goign over to fix right.
05:35 <tmh1999> s390x musl port had some holes before lol
05:36 <tmh1999> I might just report this bug
05:36 <TemptorSent> tmh1999: Yeah, I don't really need to get into the reg layout on another arch right now in depth :)
05:36 <TemptorSent> Damn, too late.
05:37 <tmh1999> told ya :)
05:37 <tmh1999> we better stop here lol
05:37 <TemptorSent> Where is this sc_mcontext from (vs uc_mcontext)?
05:37 <tmh1999> oh I just made that up to match : https://github.com/torvalds/linux/blob/master/arch/s390/include/uapi/asm/sigcontext.h#L76
05:38 <tmh1999> Okay let me summarize :
05:38 <TemptorSent> Check your defs, I'm only seeing uc_mcontext.
05:39 <tmh1999> that sc_mcontext is just like a holder, nothing more
05:40 <TemptorSent> The problem is the struct it's presumably standing in for appears to be misdefinied in the musl version of signal.h
05:41 <TemptorSent> The signatue doesnt' match any of the kernel structs I'm seeing.
05:42 <TemptorSent> Nothing matches unsigned long, long, double as members
05:42 <TemptorSent> So I'd say all of those structures are suspect.
05:44 <tmh1999> mcontext_t is usigned long, unsigned and fpregset_t
05:45 <tmh1999> mcontext_t (in musl bits/signal.h) is _s390_fp_regs in kernel arch/s390/include/uapi/asm/sigcontext.h
05:45 <tmh1999> the porter cooked them up
05:45 <TemptorSent> Program status word, unsigned long, unsigned, fpregset -> unsigned, fpreg -> union double, float.
05:46 <TemptorSent> vs the kernel def that looks like PSW, long gprs, int acrs
05:47 <tmh1999> _s390_regs_common and _s390_fp_regs in the kernel are "flatten" out.
05:48 <tmh1999> _s390_regs_common is : _psw_t, unsigned long, unsigned int
05:48 <tmh1999> right
05:48 <tmh1999> there is one unsigned int fpc;
05:48 <tmh1999> which makes no sense
05:49 <tmh1999> so technically _sigregs is _psw_t, unsigned long, unsigned int, unsigned int, <pad>, double
05:50 <TemptorSent> which looks like ucontext->uc_mcontext(_sigregs)->regs(_s390_regs_common -> psw(psw_t),gprs[](unsigned long), acrs[](unsigned int)), fpregs(fpc(unsigned int), pad(unsigned int), fprs[](double))
05:50 <tmh1999> mcontext_t is _psw_t, unsigned long, unsigned (int), unsigned (int), union (double, float). hum the same lol
05:51 <TemptorSent> floating point program counter I believe?
05:51 <TemptorSent> the pad is there to align the following double.
05:51 <tmh1999> yeah pad
05:52 <TemptorSent> fpc is a 16 bit hardware counter.
05:52 <TemptorSent> the FPU runs independent of the main CPU
05:54 <TemptorSent> notices the arrays, the __NUM_GPRS, __NUM_ACRS, __NUM_FPRS will be somewhat important.
05:54 <tmh1999> I checked them
05:54 <TemptorSent> 16 regs long for each.
05:55 <TemptorSent> With a total frame size of 96.
05:56 <TemptorSent> Actually, past the first indirection, it should be . addressed, not ->
05:57 <TemptorSent> I'm not at my best for analyzing this right now, can we look at it again tomorrow perhaps?
05:58 <tmh1999> Yeah
05:58 <tmh1999> I mean you don't have to do this anw :)
05:58 <TemptorSent> Somewhere, a structure is screaming silently :)
05:58 <tmh1999> :)
05:58 <tmh1999> let it live for a while
05:58 <TemptorSent> Solving weird problems is what I do.
05:59 <tmh1999> our devs are about to be waking up lol
05:59 <TemptorSent> In this case, musl looks to be buggered and ocaml not necessarily any better.
06:01 <tmh1999> I will give it a try again tmr if things dont go well I just post all on musl ml ...
06:01 <TemptorSent> I'm going to spend a few more hours poking at cleanups on mkimage I think, and contemplate the requirements to generate initramfs-init from fragments rather than relying on the monolithic script.
06:02 <tmh1999> sorry I took your last 2 hours :)
06:02 <tmh1999> it's about midnight over there ?
06:02 <TemptorSent> Sounds like a plan, the basis of the problem is pretty clear, the stack pointer is getting smashed with a 0 or overwritten.
06:02 <TemptorSent> nah, only just 2300, which is early by my usual standars.
06:02 <TemptorSent> I've just had a rough week.
06:03 <tmh1999> I mean, you just stay on alpine for the whole ? You don't work ?
06:03 <tmh1999> *whole day
06:03 <TemptorSent> looks like awilfox called it a night.
06:04 <TemptorSent> I'm somewhat forcibly retired (a really FUBAR back that takes you out for a month+ at a time at random will do that)
06:04 <TemptorSent> So work is what I can do when I can do it.
06:05 <tmh1999> I see :)
06:05 <TemptorSent> Right now, my paying work would go much better with a sane means of distributing lights-out configurations to clients, and alpine happened to fit the bill better than anything else I could tweak.
06:06 <TemptorSent> The sad part is that the actual project for the client has been done for several months now, but they don't have anyone that can even hope to install a linux system to run it on site, nor does their windoze only IT firm.
06:07 <TemptorSent> All for a couple hundred lines of awk and some carefully crafted SQL.
06:07 <tmh1999> that's sad
06:08 <tmh1999> hope things go well for you over there ;)
06:08 fabled joined
06:08 <tmh1999> morning fabled :)
06:12 <fabled> morning tmh1999
06:18 <fabled> tmh1999, i think we managed to handle all patches from you so far. or did we miss anything?
06:24 <tmh1999> fabled : Yes, they are all handled. Thank you. I have some patches for community s390x too, but it might take me some more days.
06:28 TemptorSent joined
06:29 <TemptorSent> ....and we're back.
06:30 <TemptorSent> Was that a general net-split, or did my ISP hose me again?
06:31 <kaniini> it was you
06:32 <TemptorSent> Bugger. I've got to get on them to replace the hardware at their DSLAM remote.
06:34 <TemptorSent> When we were actually in the middle of a thunderstorm, I understand harware disruptions, but I think something got a bit fried somewhere, as it's been dropping sync at random since.
06:38 <TemptorSent> kaniini - btw, try 'find -type f -name '*.[ch]' | xargs ctags -x --c-kinds=fp' for fun.
06:41 <TemptorSent> preferably from the top of a build source dir.
06:43 <TemptorSent> Anyway, I think I'm going to try to call it an early night and pop on earlier tomorrow. Take care.
07:03 vakartel joined
07:26 <fabled> TemptorSent, i've been giving a look at for the mkimage work... is it missing files? i could not find definition of ovl_* functions
07:26 <fabled> oh
07:26 <fabled> github suppressed it
07:26 <fabled> too big file to be shown by default
07:26 <fabled> :)
07:30 blahdodo joined
07:30 <fabled> TemptorSent, few preliminary comments
07:30 <fabled> lots of stuff in it, i do like many things in it
07:31 <fabled> this said, i think there's few cases that there's a bit of extra abstraction (that is defining helper functions that do very simple things)
07:31 <fabled> in some cases it's understable, in some cases it's causing slowness and not improving the readability at all
07:31 <fabled> e.g. ovl_get_root function
07:32 <fabled> also
07:32 <fabled> mkimage plugin profile functions were originally written to be declarative
07:32 <fabled> that is, to contain variable assignments only
07:32 <fabled> now they are a mix of function calls, and assignments which is slightly confusing
07:32 <fabled> i'd do one or the other, but not a mix
07:33 <fabled> i assume things like 'add_apks_flavored' require function calls
07:33 blueness joined
07:34 <fabled> so i'm wondering if it's simpler convert it all to function calls
07:34 <fabled> also it's getting big and complicated enough to be a separate project, not just a collection of scripts in aports/scripts
08:05 royger joined
08:37 tty` joined
08:41 t0mmy joined
09:05 Alex_______ joined
09:10 t0mmy joined
09:12 shadoo joined
09:20 stwa joined
09:31 stwa joined
09:35 blahdodo joined
09:49 stwa joined
09:49 fekepp joined
11:04 blueness joined
11:42 <jirutka> kaniini: if github goes out of business, then we can always move into our infra… and meanwhile prepare it; the proposed flow does no require GH per se, it’s just an easier option for now that is already ready and we can use it
11:44 <jirutka> kaniini: the main problem is that the proposed ACL change would bypass review process, that’s really not a good move; it may be acceptable for pkgs in testing, but definitely not pkgs in main and community; it’s not true that updates don’t need review, it’s not always just a bump of pkgver (this should be ideally handled automatically)
11:46 <jirutka> kaniini: I’d really like to improve QA and I believe that it’s very needed, this proposal as step backward
12:03 dfs joined
12:13 rrx joined
12:16 farosas joined
12:18 gromero joined
12:18 leitao joined
12:26 <rrx> i'm trying to debug a segfault in v4l-utils (v4l2-ctl), but need some guidance on how to proceed. recompiled with debug symbols and have got some basic debug info so far: http://pastebin.com/8v6DHnsV
12:27 <rrx> any thoughts on that?
12:27 dfs joined
12:33 ferseiti joined
12:37 atmoz joined
12:52 scadu joined
13:04 scadu joined
13:08 scadu joined
13:10 <^7heo> where to find the right sequence that `abuild` executes?
13:10 <^7heo> like, 'unpack prepare ...'
13:11 <yGweSm1OzVHe> i don't know where to find it, but my guess is this: deps fetch clean checksum unpack prepare build rootpkg undeps
13:12 <^7heo> /usr/bin/abuild: POSIX shell script, UTF-8 Unicode text executable
13:12 <^7heo> that's where to find it I guess.
13:22 vakartel joined
13:32 blueness joined
13:33 <fabled> ^7heo, http://git.alpinelinux.org/cgit/abuild/tree/abuild.in#n1403
13:33 <^7heo> thanks fabled
13:34 atmoz joined
13:34 <^7heo> fabled: I think there should be a way to output that from abuild
13:34 <^7heo> fabled: like abuild -h -v or something
13:34 <^7heo> also I'd advise for using -C for color output
13:35 <^7heo> for compatibility with some other stuff.
13:43 leitao joined
13:49 atmoz joined
14:25 leo-unglaub joined
14:26 atmoz joined
14:39 tmh1999 joined
15:06 fabled joined
15:15 <^7heo> I feel that something is off with not having the organizations in the APKBUILD files.
15:27 <jirutka> ^7heo: ?
15:28 <^7heo> Well, many github URLs are using the $org/$package naming scheme
15:28 <^7heo> they're not the only ones
15:29 <^7heo> and defining that as a variable might be:
15:29 <^7heo> 1. semantically richer
15:29 <^7heo> 2. making it easier to override said variable if we need to test something against our own repo, if we "fork" it on github
15:30 <jirutka> ^7heo: I don’t like that, b/c then I can’t simply click on the URL in abuild to get to the page
15:30 <jirutka> ^7heo: I do this quite often when working with abuilds
15:31 <^7heo> you mean, that because your text editor is recognizing the links as such, you want them to remain links?
15:31 <^7heo> can't you teach your text editor substitution?:D
15:33 <^7heo> I mean, I get the use case, but it looks a bit like "please don't change your website from tables to CSS, my script relies on <table> tags"
15:34 <^7heo> it was just a suggestion, and as such, it's calling for comments OFC, but of all feedbacks, I didn't expect that :D
15:35 <jirutka> ^7heo: not my text editor, but my terminal ;)
15:36 <^7heo> Oh I see.
15:36 <^7heo> and a terminal doesn't know how to substitute variables?!!!
15:36 <^7heo> that sounds unlikely.
15:36 <jirutka> is nathanejohnson here?
15:36 <jirutka> ^7heo: my terminal emulator, not shell… obviously, terminal emulator doesn’t know anything about variables
15:37 <jirutka> ^7heo: iTerm2 recognizes text that looks like a URL
15:37 <^7heo> right
15:37 <^7heo> well
15:37 <^7heo> let's not add features because apple was there before us then ;)
15:38 <^7heo> gosh I don't like apple, it's really handholding users.
15:38 <^7heo> I mean, I would probably the same as you if I was using a mac, right now.
15:38 <jirutka> iTerm2 is not from Apple
15:38 <jirutka> and it doesn’t matter at all, gosh
15:38 <^7heo> ofc not, but it's the whole "UX perfection" thing.
15:38 <^7heo> it goes a bit too far imho.
15:39 <jirutka> I think that it’s not the only terminal emulator that is not totally stupid and provides this feature
15:39 <^7heo> I mean, I could have the same problem for all I know
15:39 <^7heo> since I just need to double click in my term emulator to select the text
15:39 <jirutka> sorry, but I don’t have time nor mood for this discussion
15:39 <^7heo> and the middle click in my browser
15:39 <^7heo> yeah I don't have the time much either.
15:39 <^7heo> I didn't expect that answer
15:39 <jirutka> how’s that different? it will does not work too
15:39 <jirutka> with variables in url
15:39 <^7heo> it won't.
15:39 <^7heo> that is EXACTLY what I was saying
15:40 <^7heo> < ^7heo> I mean, I could have the same problem for all I know
15:40 <jirutka> why to make developer’s live harder?
15:40 <jirutka> aha, sry
15:40 <jirutka> I’m rushed
15:40 <^7heo> All good.
15:40 <^7heo> and because, we could very easily correct that url with a filter
15:41 <^7heo> but we can't easily change the repo without modifying the file.
15:41 <^7heo> so yeah that was my idea.
15:43 <^7heo> for instance make(1) knows how to use user-supplied variables intead of the ones in the Makefiles.
15:50 <Ganwell> I've submitted few patches and new packages, there are now all in testing/. I just wonder what happens next?
15:51 <Ganwell> they are..
15:51 <jirutka> Ganwell: where, to GitHub?
15:53 <Ganwell> jirutka: aports list http://git.alpinelinux.org/cgit/aports/commit/?id=1eea863cda80b1f9d78b5764e509f94df01c3a6c for example
15:54 <jirutka> Ganwell: aha, so it’s already pushed into aports
15:54 <jirutka> Ganwell: so what’s the problem?
15:55 <Ganwell> jirutka: no problem. I just wonder whats next step in the workflow?
15:55 <jirutka> Ganwell: it depends on what you wanna achieve?
15:55 <Ganwell> jirutka: I suppose things shouldn't stay in testing forever
15:55 <ncopa> probably get it to community or main
15:55 <Ganwell> jirutka: I'm happy, but I wonder if I have more duties.
15:56 <jirutka> Ganwell: that’s true, once you verified that it really works and the pkg has mantainer, you can propose it to be moved to community
15:56 <ncopa> Ganwell: if the package built by the official builder works
15:56 <ncopa> and is packaged good
15:56 <ncopa> eg files are where they should
15:56 <jirutka> yes
15:56 <ncopa> default config is ok
15:56 <ncopa> no missing init.d script etc
15:56 <ncopa> and there is a maintainer
15:56 <ncopa> then you can request to move it to community
15:56 <jirutka> I’ve skimmed the apkbuild and I see few problems here
15:57 <jirutka> like defining global variables when not needed
15:57 <Ganwell> jirutka: it one of my first. I cloned an existing one.
15:58 <Ganwell> jirutka: today I use newapkbuild
15:58 <jirutka> Ganwell: if you wanna move it to community, pls move it, create commit, push to your branch and open pull request on http://github.com/alpinelinux/aports
15:58 <ncopa> + # ocamlopt doesn't know -Os nor -fomit-frame-pointer
15:58 <ncopa> + export CFLAGS="-ccopt -Os -ccopt -fomit-frame-pointer"
15:58 <ncopa> i wonder if we shoudl do something like: for i in $CFLAGS; do _cflags="$c_flags -ccopt $i"; done
15:59 <ncopa> or maybe simply unset CFLAGS if it has different meaning
15:59 <jirutka> why not just ${CFLAGS/-OS/} ?
15:59 <Ganwell> ncopa: good idea
15:59 <jirutka> correction: ${CFLAGS/-Os/}
16:00 <ncopa> jirutka: it looks to me that ocaml uses CFLAGS for its own flags
16:00 <jirutka> aha
16:00 <ncopa> which is not compatible with $CC flags
16:00 <jirutka> then it’d be better to unset CFLAGS
16:00 <^7heo> wait
16:00 <^7heo> how do you define $CC flags?
16:00 <jirutka> abuild defines default CFLAGS, CXXFLAGS etc.
16:00 <ncopa> via CFLAGS :)
16:01 <ncopa> $CC was just instead of saying gcc
16:01 <^7heo> ah
16:01 <Ganwell> we have to prefix all CFLAGS with -ccopt
16:01 <^7heo> it's not even shorter :D
16:01 <^7heo> (but it's more correct ok)
16:02 <ncopa> Ganwell: yes, thats what i suspected
16:02 <^7heo> Ganwell: what does that change?
16:04 <Ganwell> ^7heo: ocaml has a to-C compiler, but it doesn't now all gcc flags, so if you want to pass something directly to gcc you have to use -ccopt or ocamlopt will complain
16:04 <Ganwell> now -> now
16:04 <^7heo> s/now/k&/
16:04 <Ganwell> yes
16:04 <^7heo> here, fixed ;)
16:04 <^7heo> Ganwell: ok ;)
16:05 <Ganwell> So we agreed on ncopas for i in $CFLAGS; do _cflags="$c_flags -ccopt $i"; done right?
16:06 <ncopa> im ok with that or unset CFLAGS
16:06 <ncopa> would probably be nice to pass over the -Os in case ocaml runs gcc
16:06 <Ganwell> ncopa: but then it will be built with CFLAGS ocamlopt chooses is that ok?
16:07 <ncopa> that depends on what ocamlopt chooses :)
16:07 <Ganwell> jirutka: what was the global variable you where refering to.
16:07 <ncopa> but i assume its ok
16:07 <ncopa> i guess he means ui and _docdir
16:07 <ncopa> local ui
16:07 <ncopa> local _docdir
16:08 <Ganwell> ncopa: I think its -O2 and definitly no omit-frame-pointer
16:08 <ncopa> i think -Os is nicer
16:08 <ncopa> but -O2 is acceptable
16:09 <Ganwell> ncopa: I guess the for loop would work well too
16:13 <^7heo> fabled: `abuild help` returns a very amusing output.
16:15 <Ganwell> ncopa: Since you're here. :) There is still this bug-report, I should have create a patch to aports for, but still is hanging, I would be glad if we could resolve it either way: http://bugs.alpinelinux.org/issues/6696
16:17 <ncopa> ah
16:17 <ncopa> yes that would be nice
16:17 <ncopa> i will apply
16:28 <^7heo> ncopa: where is your symlink for /etc/apk/cache, again?
16:32 <tmh1999> ^7heo : /var/lib/apk
16:32 <^7heo> thanks tmh1999
16:39 <^7heo> there's a problem with the apk cache and abuild
16:40 <^7heo> ah no sorry
16:40 <^7heo> I was missing an apk update
16:44 blueness joined
16:50 <TemptorSent> fabled: the add_*s calls are aliases to var_list_add $var $values.
16:52 volleyper joined
16:53 <TemptorSent> fabled: I'm working on replacing the declarations with function calls werever practical to accomodate error handling and odd conditional requirements (arch, flavor, whatont).
16:54 <TemptorSent> fabled: The other reason for using the function calls is they prevent some of the more common errors and will bail rather than silently assigning to the wrong var and failing strangley later.
16:55 <^7heo> TemptorSent: seen the query? :)
16:55 <TemptorSent> fabled: There are probably several instances where functions could be replaced by aliases, reducing the overhead somewhat -- I'll look at that today.
16:56 <fabled> TemptorSent, right. and yes, with 'set -e' function calls are a lot safer
16:57 <TemptorSent> fabled: And yes, it was already discussed that it's eventual fate would be up somewhere in it's own repo rather than remaining a script in aports, as it has a much more general application now.
16:58 <fabled> yeah
16:58 <pickfire> Bugs: git-email depend gone wrong in 13
16:58 <fabled> i guess my summary message is "good work. there's some details we need to iron, and figure out way to push it out"
16:58 <pickfire> Probably in my commit
16:58 <pickfire> Bye, need to sleep.
17:00 <TemptorSent> fabled: Most of the slowdown is probably related to the list handling, which is currently running through sort -u each time an item is added. There is lots of room for speed improvements in various places, but since they're function calls, those changes can be addressed later pretty much transparently.
17:03 <TemptorSent> fabled: And yes, plugin-overlays should probably have the helpers split off into their own file :)
17:03 <pickfire> >>> google-talkplugin*: Tracing dependencies...
17:03 <pickfire> >>> ERROR: google-talkplugin*: libanl.so.1: path not found
17:03 <pickfire> What does that mean?
17:04 <tmh1999> pickfire : set -x in APKBUILD or /usr/bin/abuild to see
17:07 <tmh1999> pickfire : looks like that application is written for glibc
17:22 <TemptorSent> fabled: Thank you for the feedback, and I'll working on cleaning it up and adding some basic documentation on what does what.
17:23 atmoz joined
17:23 <TemptorSent> ^7heo: That's what I get for sleeping :)
17:23 <^7heo> :D
17:23 <TemptorSent> ...a LONG scrollback to catch up on :)
17:24 <^7heo> :D
17:24 <^7heo> I don't catch up on things no more.
17:24 <^7heo> I just ask people to HL or repeat.
17:25 <scadu> >try to catch up 500 lines of backlog
17:25 <TemptorSent> ^7heo: Yeah, except some of it was directed to me and some was stuff I was poking at.
17:25 <scadu> >another 200 at the time when you "finish"
17:26 <^7heo> scadu: yeah exactly.
17:26 <^7heo> scadu: so fuck that shit, I hardly scroll.
17:26 <^7heo> IRC is real time, for real men.
17:26 <* ^7heo> hides
17:26 <scadu> where's is the bear fighting :<
17:26 <^7heo> (kaniini and skarnet please understand that this was a joke, for the love of dog)
17:27 <* scadu> hides at -offtopic
17:27 <TemptorSent> scadu: Yeah, I'm used to that :) In another world, I have a single fb chat that we had tens of thousands of messages a week at one point.
17:27 <kaniini> yes you need a beard of at least 15cm in order to use irc
17:27 <^7heo> (and like a joke joke, not even something worth lobbying me for :D)
17:27 <^7heo> kaniini: and to drink beer and eat pizza
17:28 <kaniini> nah girls can drink beer and eat pizza too
17:28 <TemptorSent> kaniini: And it must contain at least 20% grey hairs to be a qualified beard.
17:28 <scadu> tfw no beard
17:28 <kaniini> gotta keep things interesting you know
17:29 <^7heo> ok I'm outta here, let's troll in -offtopic.
18:22 minimalism joined
18:36 freedomrun joined
19:03 <jirutka> I’ve almost missed it, few minutes ago I’ve closed 1.000th pull request in aports on GitHub!
19:04 <jirutka> PR number 1000 has been submitted 13 days ago, it’s this one https://github.com/alpinelinux/aports/pull/1000
19:07 <_ikke_> nice
19:08 <_ikke_> technically algitbot closed it :P
19:08 <jirutka> yes :P
19:10 <^7heo> jirutka: gg
19:10 <jirutka> also I should wrote “has been closed”, b/c of course I haven‘t closed all of them personally (not even algitbot behalf of me)
19:10 <_ikke_> jirutka: I was refraining myself stating that :P
19:11 <^7heo> yeah it's ncopa who closed it ;P
19:12 <jirutka> yeah
19:14 <^7heo> and it's for toybox.
19:14 <^7heo> that is very cool
19:14 <asie> yes indeed
19:17 <jirutka> toybox?
19:18 BitL0G1c joined
19:19 <^7heo> jirutka: a BSD-licensed busybox alternative.
19:19 <^7heo> https://github.com/alpinelinux/aports/pull/1000/files
19:19 <^7heo> which is freaking cool
19:20 <jirutka> ^7heo: how’s that different from busybox, except the license?
19:20 <^7heo> I didn't check much tbh
19:21 <^7heo> but the license part alone makes me happy.
19:24 <kaniini> jirutka: toybox has better quality implementations verses the busybox ones in many cases
19:25 <kaniini> jirutka: busybox is mostly amalgamated from coreutils and other places, while toybox is a clean from-scratch implementation
19:26 <jirutka> hmm, what about compatibility?
19:35 <kaniini> that part is yet unknown. i do not personally believe 100% compatibility is necessary to switch the implementation, but we haven't gotten to that stage anyway
20:17 fekepp joined
20:21 blueness joined
20:52 <jirutka> ^7heo: are you more happy with the wget example? ;) https://github.com/alpinelinux/alpine-chroot-install#usage
21:02 scadu joined
21:06 letoram joined
21:09 scadu joined
21:14 vakartel joined
21:22 <^7heo> jirutka: it's better yes
21:22 <^7heo> jirutka: but the real issue comes from the fact that you're basically just authoring one more script "downloaded from the internet and executed as root"
21:23 <skarnet> yeah, the instructions are exhibiting a serious lack of curl | bash
21:23 <jirutka> ^7heo: like every other software on the world…
21:25 <^7heo> jirutka: yeah... I dunno.
21:25 <^7heo> jirutka: that still is a problem to me.
21:25 <^7heo> jirutka: but I'm not sure it's here and now that we should care about it.
21:25 <jirutka> ^7heo: then you have to stop using computers :/
21:26 <^7heo> Let alone solve it.
21:26 <^7heo> jirutka: no this has nothing to do with stopping and starting to use computers.
21:26 <^7heo> jirutka: it has to do with the trust being totally different when it comes to computer, at least so far.
21:26 <jirutka> ^7heo: it has, it’s all about using software that someone else wrote
21:26 <^7heo> jirutka: if you have a friend you trust, you'd leave the keys of your flat to him no problems right?
21:27 <jirutka> ^7heo: yes, if I really trust him
21:27 <jirutka> or her
21:27 <^7heo> exactly.
21:27 <^7heo> yeah them.
21:27 <^7heo> now that is the real issue
21:27 <^7heo> because
21:27 <^7heo> you actually have NO way of giving someone YOU trust a preferred access to your computer software.
21:28 <^7heo> it's all made by "unknown people on the internet"
21:28 <^7heo> like us.
21:28 <jirutka> have you heard about signed binaries? ;)
21:28 <^7heo> are you even reading me?
21:28 <jirutka> I am :)
21:28 <^7heo> So I'm not sure how signed binaries have anything to do with your friends.
21:28 <awilfox> I believe ^7heo is saying "how do you trust that signature if you don't know the people signing it"
21:29 <^7heo> it's pretty clear I'm saying that.
21:29 <^7heo> Isn't it?! oO
21:29 <awilfox> theoretically, if everyone with a computer used PGP, you could have a line of trust
21:29 <^7heo> exactly.
21:29 <^7heo> my point in one sentence.
21:29 <awilfox> but nobody does so :/
21:29 <^7heo> well
21:29 <^7heo> we have the technology.
21:29 <^7heo> now it's up to us to educate the people and go for the right goal.
21:29 <^7heo> so again, jirutka.
21:30 <^7heo> jirutka: but I'm not sure it's here and now that we should care about it.
21:30 <^7heo> Let alone try to solve it ;)
21:30 <jirutka> ^7heo: to be honest, I really don’t understand what exactly do you mean…
21:30 <^7heo> (it == the problem I have with trust over the network)
21:31 <^7heo> jirutka: ok, I'll try again then. If I can't convey my point to a fellow developers, we're gonna have a hard time conveying it to joe average...
21:31 <^7heo> s/developers/developer/
21:31 <jirutka> ^7heo: as you can see, I’m signing all git release tags with my GPG key, so anyone who now me can ask me to give them my GPG key and they can verify that the script is really from me
21:31 <^7heo> jirutka:
21:31 <awilfox> at adelie, all four of us devs signed the distro gpg key, and all of us have large social networks in PGP, so there's a good chance if you have any connection to Linux or BSD you can end up with a moderate level of trust of our keys.
21:31 <^7heo> I met you remember?
21:31 <^7heo> In Brussels
21:31 <awilfox> I dunno if alpine has GPG keys for the distro itself
21:31 <^7heo> Was cool and stuff.
21:31 <awilfox> would be cool if it did
21:31 <^7heo> I trust you a little more since then, because we're animals primarily
21:32 <^7heo> and I got to know you better
21:32 <^7heo> just a little
21:32 <^7heo> but better.
21:32 <^7heo> and I trust you a little more since then, since I know you better.
21:32 <^7heo> and the same goes for everyone.
21:32 <^7heo> if you know someone, you trust the person, if you don't, you shouldn't.
21:32 <jirutka> awilfox: hm, I guess we does not have, we have just GPG keys for builders, all packages are signed by one of the builder’s GPG key
21:32 <^7heo> (hence the example with the flat)
21:33 <^7heo> so now, imagine the person you trust most in your contacts
21:33 <^7heo> and let's admit that they trust someone "most" who isn't you
21:33 <jirutka> yes, but I really can’t know personally every developer of every software that I use
21:33 <^7heo> then we have a chain of trust.
21:33 <^7heo> not personally no.
21:33 <^7heo> that's the whoooooole point if networks.
21:33 <awilfox> jirutka: a "someday" goal for me is to add GPG key signing to APKINDEX, we already have package signing with RSA keys but if we could use GPG to sign the RSA keys and package index, it would be very easy to web-of-trust the entire distribution
21:33 <^7heo> it's peer-to-peer
21:33 <jirutka> yeah, chain of trust…
21:33 <^7heo> yeah.
21:33 <^7heo> chain.
21:34 <^7heo> exactly.
21:34 <^7heo> I trust YOU, for example, jirutka, to make the right decision when it comes to google and my privacy.
21:34 <^7heo> actually, not necessarily privacy, but reliability.
21:34 <jirutka> to be honest, it doesn’t make me very confident when I know A that knows B that knows C and C has written the software that I use
21:34 <^7heo> that you wouldn't use google as "100% online ever"
21:34 <^7heo> because I read your tweets ;)
21:34 <^7heo> so because of that, I would trust you for THAT in particular.
21:34 <skarnet> "the friends of my friends are sometimes assholes."
21:34 <^7heo> yeah
21:35 <jirutka> skarnet: exactly
21:35 <^7heo> and that's when you have to use your brain.
21:35 <^7heo> I'm not saying it's 100% error-proof
21:35 <^7heo> definitely not so.
21:35 <^7heo> and mistakes will be made
21:35 <^7heo> and people will learn.
21:35 <^7heo> BUT
21:35 <jirutka> to be honest, I see much bigger threat in trusting companies (especially big companies)… and that’s exactly what almost everyone do todays
21:35 <^7heo> it's DEFINITELY better than trusting henry.random@debian.net PGP FA91919195BB012031CD
21:36 <^7heo> jirutka: companies are people.
21:36 <awilfox> (actually, companies are 'groups' of people)
21:36 <skarnet> with diluted responsibility, which is the whole problem
21:36 <awilfox> (though in the US... companies are a distinct person too)
21:36 <^7heo> jirutka: making the difference between companies and random people is valid when we talk about means at people's disposal
21:36 <jirutka> I trust more random developers on GH that I follow for some time and see their work than to e.g. Google; exactly, companies are people and there’s too many people behind Google (or any other company)
21:36 <^7heo> jirutka: not about personal agendas.
21:36 <^7heo> if the head of a company has a very rotten personal agenda, that makes him harmful as a person.
21:37 <^7heo> not necessarily the company, as he might have to deal with more resistence via the company as in person
21:37 <^7heo> but the company might also be a problem
21:37 <^7heo> so yeah
21:37 <^7heo> it's just "more complex than that" ™
21:37 <awilfox> ^7heo: you could even rate companies based on how trustworthy they are in your social graph, if everyone used PGP
21:38 <^7heo> but I know that I'd really like to see a chain of trust instead of "just blindly trusting developer X"
21:38 <^7heo> awilfox: exactly.
21:38 <awilfox> "google has 3 people in your web-of-trust that you trust, and 1000 people that are marked untrusted"
21:38 <awilfox> "ok, maybe google can't be that trusted"
21:38 <^7heo> awilfox: when you do this stuff you can do a LOT more.
21:38 <jirutka> yeah… if it would be a real thing, companies like G and FB would somehow make people to add them to their GPG network to be able to use their software…
21:38 <^7heo> jirutka: well
21:39 <^7heo> jirutka: that's where the physical proximity is important.
21:39 <^7heo> if people use those PGP keys
21:39 <^7heo> and open hardware
21:39 <awilfox> oh, believe me, I think PGP and web-of-trust solutions in general are a very good first step towards a solution for these problems.
21:39 <awilfox> but nobody will adopt it :/
21:39 <^7heo> we can physically revoke the Google/Facebook access
21:39 <^7heo> awilfox: don't be so pessimist about it
21:39 <jirutka> we can’t… because then crowd of people would stone you…
21:40 <^7heo> Well
21:40 <jirutka> because they can’t share pics of cats on FB!!!
21:40 <^7heo> maybe you live in a country of retards.
21:40 <jirutka> that’s really a big deal!
21:40 <jirutka> btw we should move into offtopic
21:40 <^7heo> but I know that my friends in Berlin would be very happy if I can "remove the google out of their phone"
21:40 <^7heo> if it would be "that simple"
21:40 <^7heo> it's not.
21:40 <awilfox> ^7heo: I got my key in 2007. ten years ago. I'm still waiting for anyone outside of my open source projects to even have a client capable of PGP.
21:40 <^7heo> awilfox: I'm not even bothering with a key atm
21:40 <jirutka> yes, I’d be also very happy for it… to avoid google at my phone
21:40 <^7heo> awilfox: because nobody would ever use that.
21:41 <jirutka> but they have almost monopoly now…
21:41 <^7heo> not true
21:41 <^7heo> apple is also very present
21:41 <^7heo> :P
21:41 <jirutka> yes
21:41 <awilfox> ^7heo: I have two people that I have sometimes exchanged encrypted email with. but pretty much nobody I know outside of OSS projects uses PGP
21:41 <^7heo> well, I take that my gf would be able to use PGP to talk to me
21:41 <^7heo> but we hardly ever use mails
21:42 <^7heo> so I guess TOX would make more sense for us ;)
21:42 <jirutka> I consider Apple as more trustworthy, but I just don’t wanna pay more than 300 EUR for a stupid phone without usable keyboard
21:42 <awilfox> ^7heo: I think my favourite, favourite, favourite thing
21:42 <awilfox> was when I sent a PGP signed message - not encrypted, just signed - to PayPal customer service
21:42 <awilfox> ^7heo: they claimed my message was "broken" and "unreadable" and "mangled"
21:42 <jirutka> lol
21:43 <awilfox> and they "could not help me" unless I "used a standards-compliant email client like Outlook or Gmail"
21:43 <TemptorSent> awilfox: Oh, that's rich.
21:43 <awilfox> come ON, you're a financial institution, don't you know what security even means - or you know, the /ability to click 'plain text view'/?
21:43 <scadu> am I on -devel or -offtopic? XD
21:43 <jirutka> awilfox: maybe if it was in the time when GPG signed email means signature directly in the text of the message… nowadays it’s just an attachement that you can ignore if don’t use GPG
21:44 <scadu> or it's called -offel now? XD
21:44 <jirutka> yes, please move to offtopic
21:44 <^7heo> scadu: as written on -offtopic, trust is a major thing. Very much related to -devel imho.
21:45 <jirutka> ^7heo: no, this discussion is just philosophizing, it really should not be in devel channel
21:45 <^7heo> I don't know what part you're referring to. The PGP annecdotic part, sure :P
21:45 <scadu> ^7heo: I don't see any direct relation with Alpine, so
21:46 <scadu> ^7heo: we could link everything with Alpine
21:46 <^7heo> scadu: bits don't have a "strict" relation with alpine then.
21:46 <^7heo> scadu: not more than trust.
21:46 <^7heo> scadu: I think that "trust" has a liiiiiiittle more to do with a distribution that has "security" in its website headline.
21:48 <jirutka> ^7heo: yes, of course, but be a little more realistic, we’re currently trying to “save the world”, it’s like discussing about solving the poverty… unrealistic
21:48 <jirutka> ^7heo: so we should not spam the main devel channel with it
21:50 gromero joined
21:51 <awilfox> I mean this did start with me legitimately suggesting that I would love to see apk support gpg signing of package indexes
21:52 <awilfox> because at least in adelie (and I assume alpine too), we ship the apk keys as a package itself, bootstrapping security in the following way:
21:52 <awilfox> - SHA512 + whirlpool sig of ISO
21:52 <awilfox> - GPG signature of sig file
21:52 <awilfox> - ISO contains the keys
21:52 <awilfox> - ISO uses the keys to initialise /etc/apk in the target, and install a key package
21:53 <awilfox> if we could bring GPG signatures to APK itself, then you could get that same bootstrapped trust using apk in a chroot
21:53 <jirutka> awilfox: don’t know if you know about the offtopic channel, it’s #alpine-offtopic, just fyi
21:54 <jirutka> awilfox: eh, apk is of course using GPG
21:54 <awilfox> I didn't know talk about APK is offtopic, also I replied to you /on/ that channel.
21:54 <jirutka> awilfox: all pkgs are signed
21:54 <jirutka> awilfox: no, talk about APK is not offtopic :)
21:54 <scadu> \o/
21:54 <algitbot> \o/
21:55 <jirutka> awilfox: but maybe I don’t understand what you mean, Alpine packages are already signed using GPG and apk verifies the signatures
21:55 LongyanG joined
21:55 <TemptorSent> awilfox: What about counter-signing the apk sigs against a signed checksum for the base of the root?
21:55 <jirutka> awilfox: and APKINDEX is also signed
21:56 <awilfox> jirutka: as of the last time I looked, they are signed using RSA, which is a bit different from actual GPG signing
21:56 <jirutka> awilfox: or do you mean to embed GPG public key into apk binary?
21:56 <TemptorSent> jirutka: Thie issue is I believe there's no way to know that the FS is actually made up of only signed packages.
21:56 <awilfox> you can share the key, but they are not GPG signed
21:57 <awilfox> jirutka: it would be nice to be able to add public key to GPG trust store and then have apk trust those packages.
21:57 <awilfox> sort of like /etc/apk/keys
21:57 <jirutka> to be honest I don’t remember details, I thought that they are signed using GPG, but can’t put my hand to fire for it
21:57 <awilfox> but using a trusted keyserver
21:58 <TemptorSent> awilfox : Are you considering a fully hashed trusted filesystem?
21:58 <jirutka> TemptorSent: that’s appealing idea
21:58 <TemptorSent> awilfox: Or just packages?
21:59 <jirutka> awilfox: what would be the benefit of using keyserver instead of just pubkeys as files on FS?
21:59 <jirutka> awilfox: keyserver implies remote keyserver, right?
21:59 <TemptorSent> jirutka: Trusting the FS hasn't been tampered befoe it got to you.
22:00 <awilfox> jirutka: ^ yes, what TemptorSent said
22:00 <awilfox> another layer of verification
22:00 LongyanG joined
22:00 <awilfox> TemptorSent: that's pretty much what I've already done with the ISO and overlayfs.
22:00 <awilfox> TemptorSent: it is verified before it is booted.
22:01 <TemptorSent> So an image claims to be built by a@b.com, if it's not signed by a@b.com, we have an issue and reject it (or at least require the end-user to very explicitly override it)
22:01 <awilfox> correct
22:01 <awilfox> it would be lovely to have more tool support for this
22:01 <awilfox> because then we could even take it to installed systems
22:02 <TemptorSent> awilfox: That's doable -- in fact, I was doing something similar way back in the late '90s.
22:02 <awilfox> of course, there will always be holes in any system, but I feel like this kind of verification could make systems more secure.
22:03 <TemptorSent> awilfox: checksum all files, and ls -lR /, sign that, repeat, signing deltas against previous and current.
22:04 <^7heo> we could actually sign stuff and make overlay fs
22:04 <^7heo> so we wouldn't have to re-sign existing content
22:04 <TemptorSent> awilfox: Everythign got written to WORM drives.
22:04 <^7heo> just the diff
22:05 <awilfox> TemptorSent: that's the kind of thing I want to make possible.
22:05 <awilfox> exactly.
22:05 <TemptorSent> ^7heo: Exactly, that's essentially what we used to do - send signed deltas that could be recreated on the remote end and the whole system verified.
22:05 <^7heo> yeah
22:06 <awilfox> ^7heo: now imagine you have / and /home,/tmp,/srv on separate partitions. if the only thing touching / is APK and you, you can *easily* verify the entire root system with something like etckeeper+git-gpg.
22:06 <TemptorSent> ^7heo: Granted, this was mostly for stupid embedded servers and the like, but we didn't have overlayfs and easy diffs either then.
22:06 <^7heo> awilfox: yeah
22:06 <^7heo> TemptorSent: yeah.
22:07 <TemptorSent> awilfox: Actually, that's what initially got me started on mkimage -- I need to run an imutable boot system that I can upgrade through fixed images.
22:08 <^7heo> well, alpine is able to run with RAM-only root
22:08 <^7heo> that is pretty immutable.
22:08 <TemptorSent> jirutka: Did you see the trick I mentioned to kaniini about running 'ctags -x --c-types=fp `find -type f -name '*.[ch]'` against an apk build directory?
22:08 <jirutka> TemptorSent: no, I missed this, what’s that about?
22:09 <TemptorSent> ^7heo: Right, that's what I'm using. Then apply overlays on top of that.
22:09 <TemptorSent> jirutka: The complete list of function prototypes :)
22:09 <^7heo> nice.
22:10 <TemptorSent> jirutka: Helping to solve the ABI breakage question and making kaniini's suggestion something we can mostly work around for bumps at least.
22:11 <^7heo> "work around for bumps"
22:12 <^7heo> out of context, this is weird.
22:13 <TemptorSent> ^7heo: *LOL* Yeah, version bumps can be mostly automated if we can check that there are no obvious ABI/API breakages and have good CI testing of the results.
22:18 <kaniini> there is already a tool
22:18 <kaniini> to compare packages for abi breaks
22:18 <kaniini> thats not the problem
22:24 <jirutka> kaniini: if you mean checkapk, then it’s far from be really usable for automatic checks
22:24 <jirutka> kaniini: or do you mean some different tool?
22:25 <kaniini> abi-compatibility-checker or whatever it is
22:25 <kaniini> it's not from us
22:25 <TemptorSent> Can anyone shed some light on the background of lbu by the way?
22:25 <jirutka> kaniini: this one? https://github.com/lvc/abi-compliance-checker
22:25 <kaniini> it's for run from ram setups
22:26 <kaniini> jirutka: yes
22:26 <kaniini> https://github.com/lvc/pkg-abidiff
22:26 <kaniini> this, actually.
22:26 <^7heo> also
22:26 <^7heo> do I need the || return 1 in APKBUILD files now?
22:26 <kaniini> it supports apk
22:26 <TemptorSent> Cool tools!
22:27 <^7heo> or is that history?
22:27 <jirutka> and it’s also already in aports https://pkgs.alpinelinux.org/packages?name=abi-compliance-checker&repo=all&=&arch=x86_64&=&maintainer=all&=
22:27 <jirutka> ^7heo: ncopa prefers to keep them until next release, for simpler backporting
22:27 <kaniini> yes, it is, because i packaged them :P
22:27 <jirutka> :)
22:27 <kaniini> and then fab took it over
22:28 <kaniini> and then upstream added APK support to abidiff
22:28 <kaniini> so we need package abidiff
22:28 <^7heo> jirutka: thanks
22:28 <kaniini> i looked into trying to do automatic bumps 5 years ago
22:28 <kaniini> then i got busy and never finished looking into it
22:28 <kaniini> :/
22:29 <kaniini> but i think it is important that the automatic bumps if they are autocommitted be opt-in
22:29 <jirutka> kaniini: could you please transfer your know-how about it to TemptorSent? :)
22:29 <jirutka> kaniini: ofc
22:29 <TemptorSent> Take a look at abidiff and/or abi-compliance-checker vis interpackage breakage.. if they already do that, we're set!
22:30 <jirutka> kaniini: there are more potential problems, not just ABI breakages; and also this is relevant only to C/C++ stuff, not for all pkgs
22:30 <kaniini> indeed
22:30 <kaniini> however people missed the point on why i proposed the ACL thing
22:30 <TemptorSent> Right, the idea would be to whitelist packages that could be bumped by minor revs without intervention.
22:30 <kaniini> abump was one usecase
22:31 <jirutka> kaniini: I don’t think that I missed it, I just see another problems
22:31 <TemptorSent> kaniini: Once you remove the abump use case, you probably cut the number of 'maintainers' by 70% or better.
22:31 <kaniini> jirutka: my real point was that providing positive enforcement (by way of being able to push to your own packages) could help streamline onboarding more des
22:31 <kaniini> devs*
22:31 <jirutka> kaniini: and/or decrease quality…
22:32 <kaniini> TemptorSent: yes and no. a maintainer is still responsible for fixing bugs in the package.
22:32 <jirutka> I believe that it’s better to have less good pkgs than a lot of broken pkgs
22:32 <kaniini> jirutka: a maintainer is still responsible for their package, and obviously such access would only be given to people who are likely to become proper devs in the near future anyway
22:32 <kaniini> i am *not* proposing we just give it to anyone -- you still have to earn even that access
22:32 <TemptorSent> kaniini: Right, but you don't start having every person who bumps versions get whatever you want to call the limited access.
22:33 <kaniini> no, and i am not proposing that
22:33 <jirutka> I believe that we need to improve our QA and giving more ppl option to push their changes without need anyone else to review it is directly against it
22:34 <TemptorSent> kaniini: So now you have just the pool of individuals who are actually writing code to consider, which is a much more tractable sized group to work with.
22:34 <jirutka> ideally even we should not push non-trivial changes without peer review, but that’s currently not possible, we don’t have enough resources even to review contributors’ patches
22:34 <TemptorSent> jirutka: We *could* force staging builds and CI before a push goes to the main repo though, right?
22:35 <kaniini> you have to give people something in order to make them want to get more deeply involved
22:35 <jirutka> TemptorSent: yes, but then we have this Patchwork thing here…
22:35 <kaniini> that is my point
22:35 <jirutka> kaniini: I understand that point
22:36 <jirutka> kaniini: and I agree that we really should think about it
22:36 <kaniini> we also cannot be afraid of fuckups going into edge
22:36 <jirutka> kaniini: that’s not true
22:36 <TemptorSent> kaniini: Yes, but if you can give them a web front end or cli tool to report a version bump rather than having to get the aports tree and edit and apk, you'd have both more user involvment, and less users who just want the latest version getting mired in trying to figure out the development world.
22:37 <jirutka> kaniini: it’s quite unrealistic to review all changes in edge before releasing
22:37 <TemptorSent> kaniini: Yeah, I'm runnig edge on my live system, it hurts if it goes FUBAR.
22:37 <jirutka> if we don’t review it right before pushing, it would not be reviewed at all
22:37 <kaniini> TemptorSent: automatic bumps do not need user involvement, that is not what i am talking about
22:37 <TemptorSent> Like I can't actually load any modules until I reboot because my previous update fed me a different kernel version from the modules it installed somehow.
22:38 <kaniini> this isn't about abump, it's about giving people more incentive to be more involved
22:38 <kaniini> without just giving them the keys to everything
22:38 <kaniini> because obviously we don't want to do that
22:38 <jirutka> TemptorSent: no, the real solution is to automate this process
22:38 <TemptorSent> kaniini: Right, but the abump issue is currently probably the largest in terms of numbers.
22:39 <kaniini> yes, but we are working on that either way -- that's not the actual reason for my proposal and i regret using it as an example
22:39 <TemptorSent> jirutka: Where that's easy, that's great -- not all packages are easy to discover versioning on.
22:39 <kaniini> because now everyone will just obsess over abump
22:39 <kaniini> really, it's not about abump
22:39 <jirutka> TemptorSent: what do you mean with “discover versioning on”?
22:40 <TemptorSent> kaniini: If you look only at the NON abump related issues, the problem set size is much reduced, and it may lead to different conclusions.
22:40 <TemptorSent> jirutka: Automatically check for newer versions of a package to bump.
22:40 <TemptorSent> jirutka: or previous versions in some cases.
22:40 <kaniini> it's about striking a balance between giving trusted maintainers (the keyword here being trusted) more freedom, but only to their own packages, and only in edge where if they fuck it up it can be fixed
22:41 <jirutka> TemptorSent: we have 60 % of pkgs in main and community tracked by release-monitoring
22:41 <kaniini> the developer who is working with the maintainer would still be responsible for whatever that maintainer does
22:41 <jirutka> TemptorSent: I’ve done this few months ago
22:41 <TemptorSent> jirutka: Essentially, it would be advantageous if a user could submit a version number for a package and it get packaged.
22:41 <jirutka> TemptorSent: so we know when new upstream release is available and pkg should be bumped
22:41 <TemptorSent> jirutka : That's awesome!
22:42 <TemptorSent> jirutka : How are the remaining 40% handled? Is a large portion of that possible to automate as well?
22:42 <kaniini> so if for example ncopa were to arrange for vakartel to have that access to his own packages, and then he pushed crap consistently, it's still on ncopa just as much as it is on vakartel
22:42 <jirutka> TemptorSent: why should user submit version number? that’s what we have used before (and still use), it’s https://pkgs.alpinelinux.org/flagged
22:42 <kaniini> (this is just an example, i have not much opinion on vakartel's work, some of it looks good, other work doesn't look good)
22:43 <kaniini> that is what the proposal is about
22:43 <^7heo> my dog, I'm tired.
22:43 <jirutka> TemptorSent: the rest is not monitored, b/c no one mapped it or added the project on release-monitoring
22:43 <^7heo> I will go home now.
22:43 <^7heo> I can't posibly finish that package today.
22:43 <TemptorSent> jirutka : Okay, I'll definitely have to look at that a bit closer.
22:44 <TemptorSent> jirutka: Do flagged packages automatically get bumped and updated?
22:44 <vakartel> Hi, im online.
22:45 <jirutka> TemptorSent: I mapped most of the pkgs (semi)-automatically, the rest are projects that are not on release-monitoring yet and adding new project is a manual process, b/c there’s no registry of all software in the world and many times there’s no other option than to parse version from some obscure HTML pages of projects
22:45 <vakartel> want to finish with php-extensions migration
22:45 <TemptorSent> jirutka: Yeah, exactly the problem I was considering in allowing users to submit version numbers/urls to pull.
22:46 stwa_ joined
22:46 <jirutka> TemptorSent: no, currently does not, that’s the next step; when the pkg is flagged, the maintainer get email that (s)he should bump the pkg
22:46 <TemptorSent> jirutka: Okay, but no producing an updated APKBUILD for them to review yet?
22:47 <jirutka> TemptorSent: my idea is to automatically create a pull request for pkg bump, let CI build it and then inform maintainer to check it
22:47 <jirutka> TemptorSent: this is not the final goal, just next step
22:47 <TemptorSent> jirutka: That sounds both workable and simple enought to actually be maintained.
22:48 <jirutka> TemptorSent: yeah
22:48 <TemptorSent> jirutka: At some point, a better integrated system would be nice, but if it can eliminate say 70% of manual work, its a big win in the short term!
22:48 <jirutka> TemptorSent: maybe I should write about my “master” plan somewhere, it’s currently just in my head :P
22:49 <TemptorSent> jirutka: At least sketch it out in broad strokes perhaps.
22:49 <skarnet> yessss... masssster plansssss...
22:49 <TemptorSent> narf
22:49 <jirutka> TemptorSent: reliable ABI breakage detection is one of the next pieces
22:50 <jirutka> TemptorSent: yet another one is tool for checking dependencies of lua/ruby/python pkgs
22:50 <TemptorSent> jirutka: It looks like we can do that with a combination of existing tools and some creative scripting.
22:50 <TemptorSent> Those each tend to use their own package management tools, so perhaps figuring a way of hooking those rather than generating a multitide of packages would be a good bet?
22:51 <TemptorSent> In fact, we could probably hook them and run introspection to get what we need, but I'm afraid I'm not an internals expert on any of the above.
22:52 <jirutka> back to kaniini’s idea… he’s right about the motivation of contributors and getting them more involved, I know it myself that it was very demotivating when I couldn’t push ebuilds to Gentoo repository and must wait even months for someone to finally review my change and get it merge
22:52 <jirutka> but still, there’s the QA problem
22:52 tty` joined
22:52 <kaniini> my goal is to return the process back towards, in part, an actual recruiting process
22:53 <TemptorSent> jirutka: Right, which is where a staging repo would be of great use, so everything can be done and testers can access it directly if they want, then give the thumbs up once it's verifiied working.
22:53 <kaniini> we don't really want maintainers who have like 3 packages, we want people more involved than that
22:53 <jirutka> TemptorSent: that’s what’s the testing repo is for ;)
22:53 <jirutka> TemptorSent: we already have it
22:53 <TemptorSent> kaniini: It depends on the packages!
22:53 <kaniini> in general
22:54 <TemptorSent> jirutka: Testing is for general consumption, I mean staging before it goes out to general use where individual testers could add the particular package repo.
22:54 <jirutka> I’d agree to automatically give push access to their own pkgs in testing, that should be okay, BUT it’d need to pay more attention when moving pkgs from testing to main/community
22:55 <TemptorSent> jirutka: For instance, I'm working on GIS related packages, so it would be very useful if I could get a group of GIS users who need the new features in the packages I'm working on AND understand what breakage lookslike.
22:56 <TemptorSent> jirutka: If I make breaking changes, I don't want it to bite everyone using testing in the ass, I want feedback from the half-dozen users.
22:56 <jirutka> kaniini: hmm, maybe I misunderstood your proposal; so it’s more about granularity of rights then giving push access to almost anyone who push some pkg?
22:57 <TemptorSent> jirutka: That's what I got out of it, along with streamlining the process of getting packages promoted so they don't sit and languish with nobody looking at them.
22:57 <kaniini> jirutka: correct
22:57 tty` joined
22:58 <kaniini> jirutka: so for example, if vakartel is doing a good job maintaining PHP7, we could give him access to push to PHP7 packages without giving him access to anything else
22:58 <jirutka> kaniini: I know about some contributors that I think that we can give access at least for subset of pkgs, for example Andy who maintain many php stuff
22:59 <TemptorSent> If you can mostly mitigate the sloppy committer problem with automated sanity checks, it should be sane.
22:59 <kaniini> jirutka: yes, it is possible to do, and it has been arranged on a special basis in the past. my proposal is about enabling the devs who are working with these maintainers to actually facilitate this
23:00 <kaniini> there is no procedure or policy to determine where and how to do something like that, that's the goal of the proposal ultimately
23:01 <TemptorSent> kaniini : Essentially acls that give a set of maintainers full (or mostly full) access to a subset of packages that are all part of a given 'project' for lack of a better term?
23:01 <kaniini> basically, what i want is the ability for a dev to be able to set an acl on a package
23:01 <kaniini> you are adding semantics that aren't relevant
23:01 <kaniini> if a maintainer is doing a good job maintaining php7-imagick and say, xmonad
23:01 <kaniini> these aren't part of the same 'project'
23:02 <vakartel> Don't think it's a good idea to allow me to push. I really nub in git and github. I learn it while I do something.
23:02 <kaniini> :D
23:02 <kaniini> vakartel: i am just using as an example of someone who contributes a lot of patches
23:02 <TemptorSent> kaniini: Okay, but it seems in many cases you'd have a set of several related packages that a single maintainer (or group) would take ownership of.
23:03 <^7heo> like the erlang "group"?
23:03 <kaniini> lets not use the erlang packaging situation as a success story ;)
23:03 <TemptorSent> kaniini: I'd say that would be the general case in fact, as opposed to maintainers who work on isolated packages.
23:03 <kaniini> i hear it is quite fucked
23:03 <^7heo> that only works when you install all 51 of them?
23:03 <^7heo> kaniini: :p
23:04 <TemptorSent> ^7heo: Yeah, or for that matter postgres and several of it's extensions
23:04 <kaniini> TemptorSent: group maintainership is something else i want to tackle, but that comes later
23:04 <TemptorSent> kaniini: It might be simpler to implement it straight off and do "roles" to use DB speak.
23:05 <TemptorSent> kaniini: So a role maintains the package, and both individuals and groups can have that role.
23:05 <^7heo> as I wrote as an answer to your mail, kaniini, I am 100% behind you.
23:05 <vakartel> just in case - for now we have a totally broken php7 to those who use edge/testing -- 3rd party extensions still from 7.0.x but core is 7.1 now
23:06 <TemptorSent> vakartel Awesome! I love phps's entrirely self-consistent extensions ;)
23:06 <jirutka> kaniini: aha, I think that I finally understand whole point; for example I’d like to give push access to mitchty for Haskell packages, he done really great and huge job here
23:06 <kaniini> jirutka: exactly
23:06 <kaniini> jirutka: now you get it
23:07 <kaniini> jirutka: and then we also want mitchty to become more involved and eventually become a full dev, so onboarding him with ACLs is a good middle step
23:07 <kaniini> :)
23:07 <TemptorSent> ( vakartel, for context, I started back when PHP/FI was a few thousand lines of code and wouldn't dream of being extended)
23:07 <kaniini> i think ^7heo got where i was going with this
23:08 <kaniini> i don't propose giving everyone who sends us a patch that kind of access, it's more for the people who will likely be devs in 6 months to a year anyway
23:08 <kaniini> to become more familiar with the process
23:08 <TemptorSent> kaniini: That makes sense, and hopefully will help people figure out the quirks before it bites too many people in the ass at once ;)
23:09 <jirutka> TemptorSent: yeah, can’t even image in worst nightmares… it’s like trying to build a house just from mud… that’s PHP :P
23:09 <kaniini> using abump as an example obfuscated the point i was trying to make
23:09 <jirutka> kaniini: yeah, it really did
23:09 <TemptorSent> jirutka: Yeah, it was really entertaining in the pre-zend days, when the api changed daily.
23:10 <jirutka> kaniini: now I see it as a good step
23:10 <kaniini> jirutka: BitL0G1c is also possibly a good candidate
23:11 <kaniini> most of what he does is sane
23:11 <vakartel> TemptorSent - I installed Linux 1.x (sco openlinux) ))))
23:11 <TemptorSent> kaniini: yeah, the whole proposal makes much more sense once you dispose with the most common maintenance issues.
23:11 <jirutka> kaniini: what’s his username on GitHub?
23:11 <kaniini> jirutka: it offshore
23:11 <kaniini> or something
23:11 <jirutka> kaniini: aha
23:11 <TemptorSent> vakartel Ahh, you were playing with it early too then, glad to hear I'm not entirely alone in here!
23:11 <jirutka> we should make some address book, some people have totally different nickanem on IRC, GitHub and bugs.a.o
23:12 <kaniini> something something LDAP
23:12 <TemptorSent> vakartel: Nobody believes me when I say I had a printout of the entire linux source that's less than half an inch thick. (And I got Linus to sign when he still thought it was mostly a lark)
23:12 <kaniini> i do not wish to give clandmeter that much of a stroke so i will not propose that
23:12 <kaniini> ;)
23:13 <jirutka> iirc itoffshore wanted to remove `need net` from a runscript just because it doesn’t work inside LXC container with specific network setup… or remove dependency on openjdk8 from maven pkg just b/c someone wanted to install it along with totally hacked oracle jdk
23:13 <TemptorSent> Actually, LDAP would be ideal, and if the damn servers didn't try to include the kitchen sink, might actually live up to the 'Lightweight' portion of LDAP
23:13 <kaniini> jirutka: i did not say everything he proposes is sane :)
23:14 <TemptorSent> jirutka: We could support multiple runscript versions of modificaitons automatically if we want...
23:14 <kaniini> TemptorSent: the actual solution is to get rid of openrc
23:14 <vakartel> TemptorSent: guys from neigbor inet-provider tyy to teach me FreeBSD, but I select a hardcore
23:14 <TemptorSent> jirutka: I'm already doing it.
23:14 <kaniini> TemptorSent: we have outgrown what openrc can do
23:14 <jirutka> kaniini: no, we can solve it even with OpenRC, http://bugs.alpinelinux.org/issues/7038
23:15 <TemptorSent> kaniini: Hmm, how so?
23:15 <jirutka> kaniini: it already handles platform specific stuff very well using keywords
23:15 <kaniini> sure
23:15 <TemptorSent> vakartel: Those were fun times! ftp.cs.hut.fi was bogged to hell in the middle of the night for some odd reason ;)
23:17 <TemptorSent> vakartel: But Linus's own box was down more than it was up, so you had to use the 'mirror'.
23:17 <kaniini> jirutka: i think the situation there is largely that BitL0G1c is not a stakeholder and therefore has not really memorized what alpine policy is on everything
23:17 <jirutka> kaniini: I didn’t want to blame him here, I meant that just as an example why it’s important to have reviews; not everyone see bigger perspective, his solution was the easiest and straightforward, but not really solving the root problem, just a symptom, and breaking correct functionality
23:18 <kaniini> if you turn someone like him into an actual stakeholder then he would likely care more about that policy
23:18 <kaniini> yes
23:18 <kaniini> just saying :)
23:18 <jirutka> kaniini: he noticed real problem that we need to solve, just needed a guiding to open a bug report for it instead of workarounding specific pkg
23:19 <kaniini> right. that's what i mean by someone who is 70-80% of the way there
23:19 <TemptorSent> kaniini: It would help to have a document where design descisions are explained so people trying to solve their problen can understand where they are going to cause problems for others.
23:19 <kaniini> TemptorSent: right
23:19 <kaniini> my goal is to eventually have a tool like
23:19 <kaniini> where you could have
23:19 <kaniini> policy=1.2.3.4
23:20 <kaniini> in your APKBUILD
23:20 <kaniini> and it would scan for policy violations of that specific revision
23:20 <jirutka> that’s very complicated
23:20 <TemptorSent> kaniini : That would be nice, but would likely not catch the real insideous cases.
23:20 <jirutka> but yes, better linter is one of the pieces we need
23:21 <TemptorSent> kaniini: Actually, just some more detailed comments in code would go a long way -- I know I was jumping to the wrong conclusion about how abuild worked because the call was confusing as hell.
23:21 <jirutka> I’m really bored of pointing to mixed tabs and spaces all the time for example, this can be easily automated; or using of local vs. global variables and other things
23:22 <TemptorSent> jirutka: Agreed, and probably autocorrected with user confirmation.
23:22 <kaniini> anyway i have other things i am thinking on
23:22 <kaniini> the ACL is just part of it
23:22 <jirutka> but there’s quite large set of problems caused just by lack of declarative support of common usage, like pkgs for two python versions
23:23 <TemptorSent> jirutka: Although there are some very specific cases when I can think of that I explicitly mix tabs and spaces to get the proper result. HEREDOCs being one good example.
23:23 <jirutka> currently we have just set of recommended examples how it should be solved, it’s very error prone and hard to maintain
23:23 <kaniini> at the end of the day, we need to have a workflow with patch acceptance, PRs, etc, that leads to recruiting more devs
23:23 <jirutka> TemptorSent: yes
23:24 <kaniini> i would rather have 1 dev than 10 maintainers
23:24 <kaniini> in general
23:24 <jirutka> TemptorSent: that’s why it’s not so easy to check it; and that’s one of many reasons I’m working on sh-parser :) so I can detect if spaces are used just in heredoc or not
23:24 <TemptorSent> jirutka: One of the things I did in mkimage to reduce my error rate significantly was replace most variable assignments with functional assignments, so a bad name bails out rather than silenent assigns a variable to a wrong name and drives you insane for days trying to find.
23:25 <jirutka> TemptorSent: set -eu…
23:25 <jirutka> TemptorSent: then you’ll now when you have a typo in variable name
23:25 <jirutka> TemptorSent: I hope that you already use this in mkimage… :)
23:27 <kaniini> then there's the matter of haivng devs outside of package maintenance
23:27 <TemptorSent> jirutka: Yeah, I certainly do. The one that got me was where I was trying to REDEFINE a variable (actually, append to it) and had misspelled it.
23:27 <kaniini> i'm not sure how to approach that
23:27 <TemptorSent> kaniini: I give you code and run :)
23:27 <kaniini> like
23:28 <kaniini> you go to say
23:28 <kaniini> ubuntu.com
23:28 <kaniini> and they have an actual marketing team
23:28 <jirutka> kaniini: yeah, devs are really needed
23:28 <kaniini> we need people to do stuff like *that*
23:28 <jirutka> b/c ubuntu is commercial distribution
23:28 <kaniini> it's not just because it's commercial
23:29 <TemptorSent> jirutka: And I rely on undefined variables in a couple odd places still, most of which I plan to get rid of with a function call instead.
23:29 <kaniini> it's largely because someone sat down and bothered to write copy
23:29 <TemptorSent> jirutka: Function calls return errors, variable assignments not so much ;)
23:29 <jirutka> it’s about people and time, and so about money
23:29 <kaniini> not necessarily money, but yes, people and time
23:30 <kaniini> we have people who come into #alpine-linux all the time asking in what ways they can contribute that are not code
23:30 <kaniini> and we don't have answers
23:30 <jirutka> for example I’d love to work on Alpine for full time, but can’t really do that without being paid, so I can pay for my living
23:30 <TemptorSent> jirutka: I've also replaced mkdir -p in most places with mkdir_is_writable, which will fail if the the directory happens to already exist, but not be readable/writable/executable
23:31 <jirutka> and I have many hobby projects, so can’t afford to give even all my free time to Alpine
23:31 stwa_ joined
23:31 <kaniini> jirutka: my point is we are turning people away who could be doing this sort of stuff because we don't have any answers for them
23:31 <TemptorSent> kaniini: Speaking of which, did the guy looking to do translations drop back by? I don't now what the I18N L10N landscape on alpine is at all.
23:31 <jirutka> kaniini: yes, I get these questions even in emails and I also don’t know what to answer :/
23:32 <jirutka> kaniini: but the reason I don’t have an answer is that it would require time to think about it, write some suggestions what to do and lead the people
23:32 <kaniini> indeed
23:33 <kaniini> i'm trying to think on that
23:34 <kaniini> in regards for alpine as a paid gig, i have thoughts on that too. alpine has commercial derivatives (such as Docker's OS), but the derivatives themselves aren't really about alpine itself
23:35 <jirutka> kaniini: and since it’s uncertain, maybe it’d really bring bright people who would do good things, maybe it’d not, and also that I like developing more than leading people, I usually choose to rather develop something
23:35 <kaniini> what is needed is a commercial derivative of alpine, something like RHEL vs Fedora
23:36 <jirutka> kaniini: I don’t think so to be honest
23:37 <kaniini> there's demand for it
23:37 <jirutka> kaniini: Alpine is widely used in Docker containers (unfortunately it looks like 98 % of usage is this :/), Docker use it in their “official” images, build other solutions on it, so Docker is quite important for them; and Docker is one of these overrated companies with absurd market value, so they can afford to give some many to Alpine project
23:37 <kaniini> well
23:37 <kaniini> jirutka: i agree
23:37 <jirutka> kaniini: it’d be nothing for them and it’d help us a lot… and eventually even them
23:37 <kaniini> they should hire some devs
23:38 <jirutka> kaniini: not “hire”
23:38 <jirutka> kaniini: not like they hired ncopa
23:38 <kaniini> well, true
23:38 <kaniini> sponsor some devs maybe
23:38 <kaniini> :)
23:38 <jirutka> kaniini: b/c as he explained to me, he’s not hired exclusively to work on Alpine
23:38 <kaniini> he's hired to work on Alpine for docker ;)
23:38 <kaniini> i.e. Docker OS or whatever they call it
23:39 <jirutka> kaniini: docker wants more devs, but also not Alpine devs, just devs that they will allow to work even on Alpine on work time, but also on their producs
23:39 <kaniini> although docker is starting to give back (such as the selinux support)
23:39 <kaniini> so i am happy about that
23:39 <jirutka> yeah
23:39 <jirutka> the point is that IMO they can (and should!) do more for us
23:39 <TemptorSent> Query (which may or may not get me shot), has there been any discussion on moving to LLVM/clang?
23:40 <kaniini> yes, there has
23:40 <jirutka> then just hire some ppl as regular employees to work on their stuff and meanwhile also on Alpine
23:40 <TemptorSent> kaniini: Can you give me the oneliner sysnopsis?
23:40 <jirutka> but I guess that’s up to ncopa to arrange this
23:40 <kaniini> jirutka: yes, they are much like ubuntu in that regard
23:41 <kaniini> TemptorSent: ultimately we would like to do so, but right now clang does not support building everything we need (such as kernel)
23:41 <^7heo> I need a bot
23:41 <kaniini> TemptorSent: probably next year
23:42 <kaniini> TemptorSent: it is possible to install clang and even build APKs with clang if you want to
23:42 <TemptorSent> kaniini: I'd be almost tempted to run a gcc-prefix-env or something for the gcc requiring packages.
23:42 <^7heo> for reading the log properly
23:42 <jirutka> kaniini: my idea is to use something like https://www.bountysource.com/
23:42 <kaniini> jirutka: ah you mean like how i am paying for ldso improvements in musl out of pocket
23:42 <kaniini> ;)
23:42 <TemptorSent> kaniini: What I would see ther real win there as is instrumenting the build and being able to do security and quality audits.
23:42 <kaniini> (why isn't docker picking up the tab for that one?)
23:43 <jirutka> kaniini: we and our users would write what they need, docker and maybe other companies would support specific tasks
23:43 <jirutka> so they can pick what they think that it’s important even for them, or more their users
23:43 <jirutka> and see what they get for it
23:43 <kaniini> for what it's worth
23:43 <kaniini> the CTO of docker is hiding in here
23:43 <jirutka> WHAT?!
23:44 <jirutka> I hope not
23:44 <TemptorSent> Relax, as long as it's not the CFO ;)
23:44 <jirutka> because of what I regulary write about docker… maybe that’s why ncopa told with me about it… oh fuck
23:44 <kaniini> see PM ;)
23:45 <kaniini> maybe i should just show up with a bag with
23:45 <kaniini> $ on it
23:45 <kaniini> and be like
23:45 <kaniini> hii yes
23:45 <kaniini> alpine fundraising time
23:46 <jirutka> heh, yeah :)
23:46 <kaniini> the OS that made you multi-billion $ company would like some $ of it's own
23:47 <jirutka> I wanted to do something with that, but really I’m not the right person for this business stuff, I don’t like it, don’t have skills in it and even don’t feel very competent in this
23:47 <skarnet> so would I, when do I start
23:47 <jirutka> so I’ve just talked about it with ncopa and clandmeter
23:48 <TemptorSent> I'm good at either doing the technical side right and ignoring the business, or doing business right and avoiding the details, but I can't do both at the same time.
23:49 <TemptorSent> A business analyst who can't manage his OWN business - how ironic is that?
23:50 <jirutka> TemptorSent: I’m hard-core engineer, I’m trying be as far from “business stuff” as I can :)
23:51 <TemptorSent> jirutka: Yeah, good luck with that -- the problem is that engineering is at least half business details, usually more.
23:51 <awilfox> I've done both technical and business at the same time. it's draining. don't do it.
23:51 <jirutka> TemptorSent: yeah, I already know that this is the thing I can’t do alone, need someone to take care about this “boring” business stuff
23:52 <awilfox> it can be done. but don't do it. it is sort of like running your CPU 1 GHz beyond its clock speed. it might even work for a few seconds! then there is fire and death
23:52 <jirutka> heh
23:52 <TemptorSent> awilfox: Yeah, I can't handle having to have intense focus on the details and doing everything RIGHT at the same time as having to keep track of schedules, budgets, resources, meetings, etc. One has to go.
23:52 <awilfox> establishing a NPO for steering alpine and paying devs for certain high-value projects would be a good way and that's what, say, FreeBSD does.
23:52 <awilfox> but it's also very legal nightmare and needs full-time lawyer just to keep up with all of it.
23:53 <TemptorSent> awilfox: Yeah, once you get into that sort of funding, you're under scruitiny from so many sides it's not worth it IMHO.
23:54 <skarnet> not worth it for whom?
23:55 <skarnet> because for the devs, for the users, and ultimately for the good of the project, it's definitely worth it
23:55 <TemptorSent> You don't want to be held individually, jointly, and severally liable when someone getting paid fscks up and gets sued.
23:56 <TemptorSent> skarnet: And the overhead in legal and accounting fees is quite overwhelming unless you're brining in big bucks.
23:57 <awilfox> yeah, FreeBSD is doing somewhere around 1-2 million US$ per year
23:57 <TemptorSent> skarnet: You're talking a full time book-keeper, regular CPA reviews, a lawyer on retainer to review EVERYTHING you do, and someone auditing everything 2-4 times a year.
23:58 <TemptorSent> awilfox: Yeah, and I suspect their overhead out of that is enough to hurt.
23:58 <kaniini> not really
23:58 <kaniini> they have like 2 full time people for it
23:58 <jirutka> TemptorSent: fortunately most of us is from EU, not USA… you can’t sue company for *anything* you imagine here as in USA
23:58 <jirutka> TemptorSent: also there are not software patents
23:59 <awilfox> don't know european NPO laws, but I think possibly Germany is the one that has pretty good laws (sane enough that it isn't restricting you so much like USA, but strict enough that it isn't worthless to be an NPO)
23:59 <TemptorSent> kaniini; Which translates to how much a year in salaries? 60-100k each?
23:59 <awilfox> or maybe that was Spain
23:59 <kaniini> yes
23:59 <kaniini> probablt
23:59 <awilfox> I really don't remember, been years.
23:59 <kaniini> TemptorSent: a majority of the freebsd foundation $ goes to freebsd projects