<     May 2017     >
Su Mo Tu We Th Fr Sa  
    1  2  3  4  5  6  
 7  8  9 10 11 12 13  
14 15 16 17 18 19 20  
21 22 23 24 25 26 _2_7  
28 29 30 31
00:00 <TemptorSent> kaniini: How does apk currently handle cyclical constraints?
00:01 <awilfox> Shiz: kaniini: jirutka: my point was I wanted to make one specifically for xen, because I don't like nor do I care about KVM
00:01 <Shiz> ah
00:01 <awilfox> the performance is abysmal
00:01 <awilfox> back when I actually ran servers for a living, that mattered
00:02 <kaniini> TemptorSent: error
00:02 <Shiz> idk, worked fine for me
00:02 <awilfox> Shiz: postgresql had about a 30% performance increase putting it on xen, and apache was able to serve about 150 req/s more under xen
00:02 <awilfox> like I said, it mattered when I ran servers for a living
00:02 <awilfox> I don't any more so I probably don't need xen's speed and decency
00:03 <Shiz> not doubting your abilities of course, you did use all the kvm pv drivers?
00:03 <skarnet> awilfox: gandi switched from xen to kvm for performance reasons, they say they gained 20% ^^'
00:03 <awilfox> but I got used to it so I still use it
00:03 <Shiz> virtio and the like
00:03 <kaniini> cache=writeback & virtio gets you a very long way
00:03 <awilfox> Shiz: yes, it was using virtio
00:03 <awilfox> Shiz: without virtio I doubt apache would have worked at all >.>
00:03 <Shiz> lol
00:04 <TemptorSent> kaniini: Okay, I have one solver that can resolve all forward deps, including cycles, while the revdep based solver will not resolve them.
00:04 <awilfox> skarnet: they were probably using hvm instead of pv, not going to try and say xen is faster than kvm for hvm crap like openbsd or NT
00:04 <awilfox> skarnet: but freebsd and linux are what I run, and those perform much better under xen
00:05 <awilfox> at least, in my experience
00:05 <kaniini> TemptorSent: i think it will try to bring both deps in with equal weight if it is a trivial cycle
00:05 <skarnet> yeah, they weren't using pv
00:05 <TemptorSent> kaniini: The revdep solver should be orders of magnitude faster at large scale because it only visits each node once per dep.
00:05 <kaniini> awilfox: yes, PV is obviously faster than full virtualization
00:05 <skarnet> but afaik they're using Linux
00:05 <awilfox> kaniini: well, kvm can do pv too, which is what I was using
00:06 <kaniini> awilfox: not like xen pv
00:06 <awilfox> true :)
00:06 <xmux> what does kvm pv mean?
00:06 <Shiz> kvm with pv drivers
00:06 <awilfox> xmux: virtio and I think it may have dynamic CPU scaling
00:06 <Shiz> probbly?
00:06 <kaniini> awilfox: xen itself is a microkernel, it starts a domain up as if it were just another process
00:06 <xmux> ah ok
00:06 <TemptorSent> kaniini: A better question is what is the desired output of the solver given a cycle in the dep-tree?
00:06 <skarnet> https://en.wikipedia.org/wiki/Paravirtualization
00:06 <kaniini> awilfox: the real thing to compare kvm to is vmware, not xen pv
00:07 <Shiz> ugh vmware
00:07 <xmux> Yes I know what paravirtualization is, and kvm doesn't do it according to the general definition
00:07 <Shiz> i ran esxi on a box for years
00:07 <Shiz> worst time of my life
00:07 <awilfox> kaniini: hmm, then I think I take vmware's ability to not STOP windows.. or did they fix that yet in kvm? lol
00:07 <awilfox> it was pretty awful back in 2011-2014
00:08 <Shiz> esxi's half-ass ssh
00:08 <Shiz> :P
00:09 <Shiz> i remember it randomly stopping the ssh service
00:09 <TemptorSent> kaniini: As it is, I can build both fully resolved and broken dep chains with both solvers, and I've built-in a set of tests.
00:09 <awilfox> regularly got https://msdn.microsoft.com/en-us/library/windows/hardware/ff557211%28v=vs.85%29.aspx
00:09 <Shiz> which means i had to boot up my win7 vm to use their windows-only gui management tool
00:09 <Shiz> to get ssh running again
00:09 <awilfox> like, every 2-3 days, under kvm
00:09 <TemptorSent> The cyclic deps is the only place they differ in resolving.
00:09 <Shiz> also, contrary to what vmware says you can perfectly fine reset esxi root passwords without reinstalling (and losing your data)
00:10 <kaniini> Shiz: trust me i know
00:10 <Shiz> you just gotta boot into a livecd, mount the correct partition (out of 7 or 8), untar a file, edit the etc/passwd in there and tar it back up
00:10 <Shiz> a fun experience
00:10 <kaniini> Shiz: we have to do it every week
00:10 <kaniini> Shiz: because there is some ESXi worm
00:10 <Shiz> lol
00:10 <kaniini> Shiz: we eventually just locked out the ESXi machines at network edge
00:10 <awilfox> I never received such an error under kvm, or xen hvm
00:10 <awilfox> err
00:11 <awilfox> I never received such an error under vmware or xen hvm
00:11 <awilfox> I received the error under kvm :P
00:11 <kaniini> xen sucks for running windows at high density
00:11 <kaniini> evtchn flooding is a serious problem
00:11 <kaniini> in fact, xen hvm sucks in general
00:12 <awilfox> not even that, it can't use KSM
00:12 <awilfox> you can *seriously* overcommit windwos using KVM + KSM
00:12 <awilfox> windows*
00:12 <Shiz> you don't want to use KSM...
00:12 <kaniini> i do not need KSM
00:12 <kaniini> i have 512GB of RAM
00:12 <kaniini> ;)
00:12 <Shiz> KSM + rowhammer = cross-VM tampering
00:13 <awilfox> Shiz: I didn't say it was a good idea, I simply said it was possible
00:13 <awilfox> and ridiculously easy
00:13 <Shiz> https://www.vusec.net/projects/dedup-est-machina/
00:13 <Shiz> :)
00:14 <Shiz> wrong link, i think
00:14 <Shiz> https://www.vusec.net/projects/flip-feng-shui/
00:14 <Shiz> it was this one
00:15 <awilfox> Shiz: life sucks and then you enable ptrr and stop thinking about this stuff
00:16 <awilfox> and anyway, sometimes that is acceptable, consider a developer just doing testing across a bunch of configurations
00:16 <awilfox> if you don't care about the integrity of the windows VMs because they're just throwaway things, who cares about owning? it can squeeze more into a single computer without needing RAM upgrades
00:17 <awilfox> and considering manufacturers like apple and lenovo are starting to solder memory to the boards instead of using sockets...
00:17 <Shiz> what makes you think this is limited to vm-to-vm
00:17 <awilfox> that will continue to be a thing
00:17 <Shiz> it's just as easy applicable to vm-to-host
00:17 <Shiz> :)
00:17 <awilfox> Shiz: if I cared about vm-to-host security, I would be using hardware solutions like powerpc lpars
00:17 <awilfox> xen and vmware and kvm and qemu and all of them fail very badly at making me feel like the vm can't own the host
00:18 <Shiz> i'm sure you'll get a lot of customers offering ppc machies :p
00:19 <awilfox> didn't know I had customers that cared about the architecture of my mail/web/database servers... lol
00:19 <awilfox> that reminds me, I need to see if musl/ppc64 actually works on not-power8
00:20 <awilfox> or if I need to spend my weekend rewriting it
00:20 <skarnet> awilfox: speaking of which, please tell me when I can use georgie again
00:21 <Shiz> awilfox: i can give you an answer to that: no
00:21 <Shiz> it's only ppc64le
00:21 <Shiz> afaik
00:22 <awilfox> Shiz: no, they have a big endian port, but it uses the v2 ABI
00:22 <awilfox> Shiz: and IBM says that ABI requires either "power8 features to be available, or emulated by the system"
00:22 <Shiz> oh, hm
00:22 <awilfox> Shiz: and dalias says "well I make up the ABI and I say it doesn't require power8 to be available"
00:23 <Shiz> maybe i was confusing some old ML post then
00:23 <awilfox> Shiz: and repeated attempts to tell him "that isn't how it works" have failed, so I need to prove it; and that will require me building a toolchain and showing it spectacularly crashing on my power4e+
00:23 <awilfox> skarnet: booted, though it seems to think it has an Apple OHCI Root Hub, despite it having USB disabled and not running on an Apple computer.
00:23 <kaniini> these are literally "i need a browser" environments for auditing
00:24 <skarnet> awilfox: no rush, I'm soon going to sleep anyway - I'll just need it some time next week
00:24 <awilfox> skarnet: ah, okay. well, in that case I will go ahead and update it later tonight
00:24 <awilfox> unless you need it to remain on 5.7
00:25 <skarnet> it's your machine, do whatever you need with it
00:25 <awilfox> well it is mainly a machine to test porting
00:25 <awilfox> but none of my projects currently need portability to BSD
00:25 <awilfox> I dunno if you need to remain compatible with the 5.x release line
00:26 <skarnet> honestly, if I need a POSIX feature and 5.* breaks because of it, I'm not going to shed a tear
00:26 <awilfox> 6.0 rewrites substantial parts of the libc to be more in line with POSIX 2015
00:26 <skarnet> 6.0 is good
00:27 <skarnet> at the very last they decided that maybe self-contained headers was a good thing
00:27 <awilfox> well 6.1 is just released in last weeks, was just saying, I left it at 5.x because it is more effort to port to.
00:27 <awilfox> it is more of an 'exercise' for the code, to be sure it works fine on it
00:28 <skarnet> if you want to upgrade it, be my guest - technically I'm your guest
00:29 <skarnet> if I can answer "just upgrade your shitty OS" to BSDers whining "doesn't build", all the better
00:30 <awilfox> hmm, I just realised: I DO have a project that needs to be portable to BSD
00:30 <awilfox> so having 6.1 available may be worth it
00:30 <awilfox> "Highlights include GCC 4.9.4, KDE 3.5.10, and Firefox 52.0.2"
00:30 <awilfox> openbsd still ships KDE 3, lmao
00:31 <Shiz> trinittyyyyy
00:32 <skarnet> how about BIND 4
00:36 <awilfox> bind 9.10.5
00:38 <skarnet> that was a trick question, the correct answer is "don't ship BIND"
01:20 blueness joined
01:46 s33se joined
01:59 blueness joined
02:12 <kaniini> so
02:12 <kaniini> windows is reporting -4 billion packets received
02:12 <kaniini> quality is job #1 at microsoft or qemu or i don't even know
02:17 <awilfox> virtio is a red hat production
02:17 <Shiz> xentec: my mostly untested POSIX sh/tools port of wg-quick https://txt.shiz.me/MzUzZWM2Y2
02:17 <Shiz> expect breakage
02:18 <Shiz> where 'port' means 'rewrite the bash script line-by-line to take out bashisms'
02:20 <Shiz> small correction: https://txt.shiz.me/YmY1NjJmYW
06:16 <TemptorSent> kaniini: -4x10^9 sounds about right for Windowz - after all, it's a black hole for time, money, data, and anything else you let near it.
06:18 <skarnet> reminds me of a certain IRC channel
06:20 <TemptorSent> skarnet: Only one? ;)
06:21 <skarnet> only one I'm foolish enough to frequent LO
06:21 <skarnet> :P, not LO
06:21 <TemptorSent> Fencepost error.
06:23 <TemptorSent> (Don't worry, my fingers forget where they are more and more as I get older - it's normal. *twitch*)
06:27 <TemptorSent> skarnet: Any thoughts on implementing a minimal graph-structured database (n-tuple store) for use by apk? Do you have anything in your bag of tricks that might be of use?
06:29 <skarnet> how many fields can be keys?
06:29 <skarnet> all of them?
06:29 <TemptorSent> Arbitrary.
06:30 <skarnet> that means "all of them"
06:30 <TemptorSent> Edge properties differentiate the relationships, not node properties.
06:30 <skarnet> example?
06:31 <TemptorSent> package a --depends on--> package b ; package a --provides--> file
06:32 <skarnet> --provides should be a virtual capability, not a file
06:33 <TemptorSent> It's a relationship, allowing looking up packages by file directly.
06:33 <skarnet> you want a complete relational db
06:33 <TemptorSent> And determine conflicts by airity.
06:33 <TemptorSent> No, not at all.
06:34 <TemptorSent> Graph-structured database, not RDBMS
06:34 <skarnet> you do. A table of packages, a table of dependencies, a table of virtual thingies...
06:34 <TemptorSent> Nope, I want a set of nodes and multiple sets of nodes.
06:34 <skarnet> you don't only have packages here, there are more data types
06:34 <skarnet> you want more than one table
06:34 <TemptorSent> then edges to connect them.
06:35 <TemptorSent> No tables involved.
06:35 <TemptorSent> Tree structures.
06:36 <skarnet> idc about the data structure, that's an implementation detail
06:36 <skarnet> the fact is that you have several types and you want to be able to query them all
06:36 <TemptorSent> n-linked-2-linked lists is one way to do it.
06:37 <skarnet> again, idc about implementation at this point
06:37 <skarnet> cart before the horse, etc.
06:37 <skarnet> first get the model right
06:37 <TemptorSent> Given a list of files, a set of deps, and some metadata, I want to be able to walk the tree.
06:37 <skarnet> what tree?
06:38 <skarnet> there's no tree at this point, I want to know what kind of data you're handling
06:38 <skarnet> brb
06:39 vakartel joined
06:40 <TemptorSent> Pick a root node, draw an edge from that node to each node referencing it, rinse, repeat :)
06:40 <TemptorSent> The edges are tagged with the type of relationship, the nodes themselves are keys and optionally metadata.
06:42 <TemptorSent> So the relationship could be "depends on", and it could exist between different packages, between files (executibles/libraries), init scripts, whatever -- it's a generic relationship.
06:42 <awilfox> polymorphic RDBMS is still RDBMS
06:43 <TemptorSent> binary:'/sbin/apk' -- depends on --> 'libz.so.1'
06:44 <TemptorSent> awilfox: No, it really isn't. Please take a look at graph-structured databases vs. RDBMSs, it's quite different.
06:45 <TemptorSent> Its much closer to a direct linked-list than a RDBMS, with traversals being the primary operation, not query by keys.
06:46 <TemptorSent> Think DAGs, not tables.
06:48 <TemptorSent> Essentially, a set of DAGs (possibly generalized to include semantically acyclic cyclic directed graphs), with multiple independent sets of edges connecting them
06:49 <TemptorSent> Each edge is an annotated set of pointers, each node gets a UUID, a name, a data pointer, and a set of incoming and outgoing edge pointers.
06:50 <TemptorSent> No tables (except possibly for backing-store, but that's and implementation choice)
06:52 <TemptorSent> take a look at the output of 'apk dot', which gives the nodes and edges for packages and their deps.
06:53 <TemptorSent> I'd like to generalize that functionality, and more importantly, be able to interact with it in graph-structred form.
06:57 <TemptorSent> Bonus points for handling generic vs. specific nodes (package:packagename vs package:packagename=pkgver or package:packagename=:hashtype:hash:)
06:58 <TemptorSent> So the only index we need is a simple hash index and key index, no table indexing needed since we already have all information in the graph.
06:58 blahdodo joined
07:00 <skarnet> why the heck do you ask questions if you're already made up your mind and won't budge
07:00 <skarnet> you've*
07:01 <TemptorSent> i.e. binary:'/sbin/apk' --(depends on)--> libso:'libz.so.1', while binary:'/sbin/apk':sha512:<hash> --(depends on)--> libso:'libz.so.1.2.11':sha512:<hash>
07:01 <skarnet> if you're going to ask for my input, then please 1. describe the problem you want to solve, in accurate terms; 2. don't confuse me with your implementation details or choices; 3. let me think about it the way I see fit, i.e. model first and implementation second
07:01 <TemptorSent> I haven't made up my mind about anything other than what I'm trying to accomplish.
07:01 <skarnet> you haven't done 1. yet
07:01 <skarnet> you've jumped right into 2.
07:01 <skarnet> and 3, well, let's not even talk about it
07:04 <TemptorSent> 1. I am trying to create a generic, generally useful graph-database that is appropriate for use in system-level tools. It may be used for multiple purposes, including (but not limited to) providing dependency resolution, maintaining hashsets, storing configuration history, other generally graph-like operations.
07:04 <skarnet> if you want to have { files, packages, virtual capabilities } and relations between them, that's exactly what a RDBMS does, so you need to narrow down exactly what it is you want
07:05 <TemptorSent> I want nodes, edges, and the ability to annotate them.
07:05 <TemptorSent> A RDBMS requires HUGE overhead by comparison to a graph database for traversals.
07:06 <TemptorSent> A graph database is explicitly designed to work for highly recursive operations.
07:06 <TemptorSent> Which is one of the places most RDBMSs suck.
07:07 <skarnet> you are, again, talking about implementation
07:07 <TemptorSent> Not to mention wanting to use a few hundred k, not a few hundred megs.
07:07 <skarnet> I'm asking you to step away from the implementation
07:07 <TemptorSent> No, I'm talking about model.
07:07 <skarnet> and to talk about what you WANT
07:08 <TemptorSent> I'm not sure what I was unclear about what I WANT -- a minimilistic graph-structured database that allows for multiple sets of edges with annotations.
07:10 <skarnet> that's as clear to me as "I want a system to manage our workflow"
07:10 <TemptorSent> http://whitedb.org/ is a much larger version of the kind of database I'm referring to.
07:11 <TemptorSent> I don't need full-on RDF, just MINIMAL graph-structure and the ability to traverse it based on the content of nodes/edges.
07:11 <skarnet> you're obviously either not listening, or not understanding what I'm expecting
07:12 <TemptorSent> I'm afraid I'm not understanding what you're after.
07:12 <skarnet> I don't care about the data structures and I don't want to hear about nodes, edges, lines, circles or easter bunnies
07:12 <skarnet> I want to hear about the tool you're designing and the functionality you want to have
07:12 <skarnet> what command do you want to be able to do
07:12 <skarnet> what are you writing
07:12 <skarnet> what functionality can users expect
07:13 <TemptorSent> All I WANT is the data-structures, nodes, edges, and the ability to read/write/modify/traverse them.
07:13 blahdodo joined
07:13 <skarnet> bzzzzt! you said nodes and edges again
07:14 <skarnet> I'm out
07:14 <TemptorSent> It doesn't matter if it's storing keys, packages, users, filenames, or whatever!
07:14 <skarnet> of course it does matter
07:14 <skarnet> but it's too late, you blew your joker
07:14 <skarnet> try again next month!
07:14 <TemptorSent> Sorry, I don't know how to describe a generic data storage tool more specifically.
07:15 <skarnet> that should give you a clue
07:15 <skarnet> "don't try and write a generic data storage tool"
07:15 <TemptorSent> Which use do you want?
07:15 <skarnet> that was free consulting
07:15 <skarnet> my usual fare is 450€/day
07:15 <skarnet> always happy to help, have a nice day!
07:15 skarnet left
07:16 <TemptorSent> That's like saying 'don't write a generic regex parsing tool' rather than writing sed.
07:16 <TemptorSent> Hmm, I thought this was unix land, where small, generically usefull tools were ENCOURAGED.
07:17 <TemptorSent> I guess either I design, write, and test it by myself, or just give up on trying to improve the tools.
09:23 <martanne> jirutka: thanks, by now all needed packages have static versions. Only some pkg-config related issues remain. I extracted the two configure checks from vis which should illustrate the problem (or my wrong expectations).
09:23 <martanne> 1) the termkey.pc does not reference unibilium, causing a linker error:
09:23 <martanne> http://sprunge.us/NFCd
09:23 <martanne> 2) lpeg.a should probably be named liblpeg.a and the Lua package path /usr/lib/lua/5.3 should be added to lua5.3.pc?
09:23 <martanne> http://sprunge.us/eAOK
10:28 fekepp joined
10:34 scadu joined
10:47 D630 joined
10:55 <tmh1999> jirutka : I guess we just disable binaryen on s390x for now. we would want s390x ready by monday for rc1. if upstream has something sound, we add it back again ?
10:56 <tmh1999> thank you :)
10:58 jnettlet joined
10:59 <jirutka> fabled: could you please help me move testing/ghc to community?
11:10 <jirutka> what the heck is so hard to understand about implicit return values in shell functions?!
11:36 minimalism joined
11:36 <scadu> hi, I tried to build LXC container using following template: https://github.com/lxc/lxc/blob/master/templates/lxc-alpine.in that's the result: http://sprunge.us/hDWF
11:37 <scadu> it seems that dl-cdn mirror is still affected. after changing to nl.a.o or cz.a.o this issue does not occur
11:45 <jirutka> Shiz: kaniini: could please someone look at https://github.com/alpinelinux/aports/pull/1399 ? tbh I have no clue what is this change doing
11:52 <tmh1999> jirutka : man 2 posix_fadvise : POSIX_FADV_DONTNEED attempts to free cached pages associated with the specified region. What I understand is the builder is userspace lxc, thus it does not have permission to free the data
11:54 <jirutka> tmh1999: but how will it affect the program? is it okay to change it just because this feature is not allowed under LXC?
11:55 <tmh1999> in fact it does not affect at all. the POSIX_FADV_DONTNEED only differs POSIX_FADV_NORMAL in the sense that the latter does not tell the kernel to free the pages/cached data.
11:55 <tmh1999> ioping measures the IO perf, then does tell or does not tell the kernel to free the data.
11:57 <jirutka> then why ioping use POSIX_FADV_DONTNEED instead of POSIX_FADV_NORMAL ?
11:58 <tmh1999> http://ix.io/tAL : it fails in the $ make test
11:59 <tmh1999> jirutka : in fact the same purpose can be achieved with -C option passed to ioping https://github.com/koct9i/ioping/blob/master/ioping.c#L319
11:59 <tmh1999> I can do -C just find
12:00 <tmh1999> *fine
12:00 <tmh1999> but, what I understand is -C and POSIX_FADV_DONTNEED are different
12:00 <tmh1999> not same purpose, same goal.
12:34 mir4ndaX joined
12:34 <mir4ndaX> hello
13:06 Mr_H joined
13:12 <arch3y_> so far I have had the devs of netsniff-ng build over 6 patches to fix the source to work on apline
13:58 ppisati joined
14:00 vakartel joined
14:08 ppisati joined
14:23 blueness joined
14:44 Mr_H joined
15:15 <arch3y_> Shiz: thanks for helping with the netsniff-ng stuff I was thinking it didnt have fopencookie support but I wasnt 100% sure
15:15 <Shiz> :p
15:16 <arch3y_> with any luck they will implement a few more changes and it will be done
15:20 czart_ joined
15:24 rfs613 joined
15:28 <ashb> Anyone who knows POSIX sh better than I know of a way to deal with this case? https://github.com/alpinelinux/aports/pull/1325#discussion_r115966885
15:30 <TemptorSent> ashb - use ${pkgver%%.*} perhaps?
15:31 <ashb> That removes everything after the first period, result is "2"
15:32 <TemptorSent> ashb - what are you trying to get, the first two?
15:32 <ashb> 2.2 is the result I want
15:33 <TemptorSent> Go at it the other direction then, trim it off the front, then play the game to remove the suffix
15:34 <Shiz> ashb: it's probably fine to just use cut, imo
15:34 <ashb> @Shiz that was my thought too :)
15:35 <Shiz> with the varying number of dots it's a pain to do through shell syntax
15:35 <TemptorSent> _pkgvermajor="${pkgver##*.*.}" && _pkgvermajor="${pkgver%$_pkgvermajor}"
15:35 <ashb> I can do a horrible version involving ${#x} and %{x:0:...} but that only works in bash (and is not understandable)
15:36 <TemptorSent> oops, forgot a dot in the second.
15:37 <jirutka> ashb: this is quite tricky… in this case it’ll be better to just hardcode _pkgvermajor=2.2
15:37 <Shiz> hardcoding is fine too imo
15:37 <jirutka> ashb: it’s not changing very often anyway
15:37 <Shiz> as long as it's close to the pkgver, it should be easy to detect
15:37 <Shiz> :P
15:37 <ashb> seems fair. I'll go for that
15:38 <jirutka> ashb: but to avoid mistakes, simple check in prepare() would be handy
15:38 black_ant joined
15:38 <ashb> and set up a proper APKBUILD chain so I can actually test it once I'm back home and have my charger
15:38 <ashb> @jirutka if it's wrong the download would fail. Is that enough of a check?
15:38 <Shiz> ^that's fine by me
15:38 <jirutka> ashb: ah, right, that’s enough
15:39 <ashb> Will update it later today
15:39 <TemptorSent> If that doesn't tell you somethings wrong, something's wrong :)
15:39 <Shiz> ashb: if you're fixing the APKBUILD anyway, could I ask you to remove the || return 1 stanzas too?
15:39 <Shiz> they're not needed anymore
15:39 <ashb> sure okay. same commit or different (squashing all the other update ones into one anyway)
15:39 <Shiz> it's fine to just squash it all into one commit
15:41 <jirutka> ashb: preferably in separate commit (in the same PR)
15:41 <Shiz> jirutka's opinion supercedes mine :p
15:42 <jirutka> Shiz: it’s usually better when contributors does not squash commits, it’s harder to identify what has been changed since the last time you’ve looked at it and we can always easily squash if if needed when merging ;)
15:43 <ashb> One commit to update versions, one to update apk.
15:43 <Shiz> add it, apk update, and try again
15:43 <Shiz> whoops wrong chan
15:44 <jirutka> Shiz: also some ppl don’t know git enough and may create quite big mess when using --force
15:48 <jirutka> Shiz: it’s even in https://github.com/alpinelinux/aports/blob/master/.github/CONTRIBUTING.md: "Add your file(s) to git and commit (we will squash your commits if needed)." ;)
15:48 <Shiz> alright
15:48 <Shiz> i will stop asking for that then
15:48 <Shiz> :P
15:51 <Shiz> jirutka: what do you use to merge PRs on the command line?
15:54 <jirutka> Shiz: curl -L https://github.com/alpinelinux/aports/pull/<PR-NUM>.patch | git am
15:54 <Shiz> also, https://github.com/alpinelinux/aports/pull/1402 LGTM if the commit message is changed to `main/darkhttpd`
15:54 <Shiz> i thought it was in community thanks to that message and tried to merge it
15:54 <Shiz> :D
15:55 <jirutka> Shiz: there’re messed whitespaces https://github.com/alpinelinux/aports/pull/1402/files#diff-5a6267b392b6870ca51bc70b1755e2acR26
15:55 <jirutka> Shiz: I’ll fix it when merging
15:55 <Shiz> any messy whitespace was already thereb efore
16:02 <jirutka> hm, storm is coming, I’ll be probably w/o electricity soon :/
16:03 <jirutka> (I’m not in Prague now)
16:13 <Shiz> oh dear
16:13 <Shiz> that bad over there?
16:18 <arch3y_> to be honest Ive held off on my prs becuase I was a bit nervous about squashing stuff lol
16:19 <arch3y_> I knew Id mess it up
16:19 <Shiz> it's okay, i can squash it too
16:19 <Shiz> it's no big issue
16:23 Mr_H joined
16:36 <jirutka> hm, IIRC removing `|| return 1` should be postponed until branching v3.6, to make backporting fixes easier
16:39 <Shiz> what do you mean?
16:39 blueness joined
16:39 <Shiz> 3.6 would have the version of abuild that does set -e too, no?
16:40 <jirutka> yes
16:40 Mr_H joined
16:41 <jirutka> tbh i don’t know reason behind this, imo it doesn’t matter, just remembering that ncopa mentioned it few times
16:41 <TemptorSent> Hmm, perhaps a simple fail() function would be wise for semantic and possibly logging purposes?
16:42 <jirutka> no
16:42 <jirutka> it’s not needed since we run abuild with `set -e`
16:42 <TemptorSent> I mean for explict failure cases, not failed commands.
16:43 <jirutka> like where for example?
16:43 <jirutka> explicit failure case is when command returns non-zero status
16:43 <TemptorSent> test_for_condition || fail "Condition blah not satisfied, try ..."
16:44 <jirutka> yeah, that may be useful
16:44 <TemptorSent> So useful debugging information can be provided when -v is set.
16:44 <jirutka> but that’s different issue
16:45 <TemptorSent> Agreed, just one that comes up with removing the || return 1 in terms of semantics anyway.
16:45 <jirutka> yes
16:45 <TemptorSent> Tests with no action are semantically confusing.
16:46 <TemptorSent> '[ -e "$file" ]' vs '[ -e "$file" ] || return 1' for instance.
16:48 <TemptorSent> Better would be '[ -e "$file" ] || fail "File $file doesn't exist, try creating it (see example...)"
16:48 <jirutka> I don’t remember any case like this in apkbuilds ;)
16:49 <jirutka> there’s usually soma command that itself prints error message
16:49 <TemptorSent> Yeah, those cases don't need it if they're already semantically correct on failure.
16:49 <jirutka> so I’ve looked into abuild; there’s error command for logging error
16:50 <jirutka> and die command for that logs error and exits 1
16:50 <jirutka> and calls cleanup before existing
16:50 <TemptorSent> right, fail would log error and return 1, not exit 1
16:51 <TemptorSent> die-light :)
16:51 <jirutka> it depends on how is trap set in abuild script
16:51 <jirutka> maybe it’s good idea, maybe it’s contraproductive, don’t know now :)
16:52 <jirutka> *counterproductive
16:52 <jirutka> what the hell English? I thought that contra is from Latin… like against… so why counter-…?
16:52 <TemptorSent> Well, for semantic purposes I think it would be useful, even if it does nothing more than return 1 with optional message.
16:53 <TemptorSent> Contra is diametric opposite.
16:54 <jirutka> hm, yeah
16:54 <Shiz> TemptorSent │ Better would be '[ -e "$file" ] || fail "File $file doesn't exist, try creating it (see example...)"
16:54 <TemptorSent> contrapositive for instance being the set exclusive the set of positive.
16:54 <Shiz> even better would be a checkpath helper
16:54 <Shiz> ;p
16:54 <jirutka> so it’s even in English, then I really don’t understand counter-productive
16:54 <TemptorSent> Agreed, that's what I do in my scripts.
16:54 <TemptorSent> Counter-productive is against productivity, not the diametric oppositie of productive.
16:55 <jirutka> aha
16:55 <TemptorSent> At least that's my understanding of it.
16:56 <TemptorSent> loosely counter ~= against, contra ~= opposite
16:56 <TemptorSent> and against ~= opposing, so it's less than clear in some cases.
16:57 <TemptorSent> But that's advanced semantics extraction for NLP, not Alpine build systems ;)
16:59 <TemptorSent> Shiz: What would you say to helping to define a set of appropriate helpers and putting them in a single common location for use by all alpine scripts?
17:00 <TemptorSent> File/directory check/create/delete, archive handling, url handling, and apk helpers?
17:00 <Shiz> i don't think it's generally needed
17:01 <Shiz> i am way of a 'libalpine' as it would just devolve into being the kitchen sink
17:01 <Shiz> wary*
17:01 <jirutka> afk
17:03 <TemptorSent> Nearly every script needs some subset of the functionality, usually it ends up being reimplemented in each one.
17:04 <TemptorSent> See msg/warn/error etc.
17:04 <TemptorSent> Also file/dir checks are often done wrong, checking for existence, but not readablity for instance.
17:06 <TemptorSent> So having a consistent, known correct (or at least meeting tests), clear, and common set of utilities would reduce errors, improve readability, and make debugging much easier.
17:15 <TemptorSent> We can unit-test and regression-test individual utilities for correct behavior, while testing the scripts is much more difficult.
17:19 <TemptorSent> "file_is_readable "$file" || fail "Can't read '$file'" or "file_is_readable "$file" || cat "$file.example" | sed ... > "$file""
17:21 skarnet joined
17:29 minimalism joined
17:41 agb joined
17:48 fekepp joined
17:56 <ashb> https://github.com/alpinelinux/aports/pull/1325 updated and actually working this time :)
18:24 <TemptorSent> Hmm, working out the math on deps leads to the conclusion that we really need a way of distinguishing cyclic dependencies from mutual-inclusion dependencies semantically.
18:26 <TemptorSent> if packages a,b,c are all mutually interdependent, there needs to be a way of distinguishing that from the case where package a requires package b to install, which requires package c to install, which in turn requires package a, thus can not be successfully installed (aka: bootstrapping required)
18:27 blueness joined
18:29 <agb> ls
18:30 <skarnet> bin boot dev etc home lib lost+found mnt opt proc root run sys tmp usr var
18:31 <TemptorSent> Semantically, it may make sense to have the first case use a self-reference to indicate an inclusive set (a:a,b,c b:b,a,c c:c,a,b)
18:31 <TemptorSent> *lol* skarnet
18:31 <skarnet> TemptorSent: what you want is different sets of dependencies: install-time and run-time
18:31 <agb> skarnet: thanks.
18:32 <TemptorSent> skarnet: Not necessarily, but that is one case.
18:33 <skarnet> well those are different kinds of dependencies, that must be addressed separately, so they need to be in the tool anyway
18:34 <skarnet> and bootstrapping should be solved at package creation time, the tool doesn't have to handle it
18:34 <skarnet> i.e. if your packages have circular deps, you packaged them wrong
18:34 <TemptorSent> The ability to explicitly specify mutual dependency eliminates all semanticly acyclic cycles
18:35 <TemptorSent> A good example is one component of package a depends on a component in package b, while a component in package b depends on a component in package a.
18:36 <skarnet> packages a and b suck, send hate mail to their maintainer
18:36 <TemptorSent> Rather than a:b, b:a we'd use a:a,b b:b,a
18:37 <skarnet> having to handle connex components in the tool rather than single packages is a choice, but it adds a lot of complexity
18:37 <skarnet> better solve this at packaging time
18:37 <TemptorSent> If possible, yes, but sometimes the complexity of doing so is absurd.
18:38 <skarnet> well if you want to be able to bootstrap all your software, you need to do so anyway
18:38 <TemptorSent> Drivers with both userspace and kernel components that must match for instance.
18:39 <skarnet> wrong example: userspace always depends on kernelspace, never the other way around
18:40 <TemptorSent> Okay, so when you add one, what happens to the other?
18:40 <skarnet> if you add kernelspace, nothing happens and you don't get the functionality. If you add userspace, you pull kernelspace.
18:40 <skarnet> why isn't that obvious?
18:41 <TemptorSent> Yeah, and not terribly helpful when you want to pull in both the kernel module and firmware for it.
18:41 <TemptorSent> You need both for it to work, and neither one makes sense without the other.
18:41 <skarnet> sigh. firmware is different, it's morally kernelspace, it goes with the kernelspace module.
18:42 <skarnet> Again, this should be obvious.
18:42 <TemptorSent> Yeah, too bad it doesn't actually work that way.
18:42 <TemptorSent> It's a messy mixed bag at the boundary of kernelspace/userspace
18:42 <skarnet> well, if we're the packagers, we're the ones who can choose the way to make it work
18:44 <TemptorSent> Maybe, but not necessarily cleanly in some cases.
18:44 <skarnet> and I'm going to leave before you're tempted to splain me how the boundary between userspace and kernelspace works, so I won't have to be unpleasant.
18:44 <skarnet> Have a nice evening!
18:44 skarnet left
18:45 <TemptorSent> *facepalm* Never fear, reality will never bite us in the ass with a true mutual dependency!
18:46 <TemptorSent> And set theory is wrong about what constitutes a NP-complete problem vs. one that can be solved in linear time too, right?
18:47 <TemptorSent> Explicit constraints = bounded time, otherwise, it's NP
18:49 <TemptorSent> Why do I even waste my time trying to solve real problems when handwaving and pretending they never exist works so well?
18:49 <Shiz> i'm totally fine with not catering to mutual dependencies
18:50 <TemptorSent> Shiz: Can you build a near-linear time dep solver that can handle the short-cycle deps we have now?
18:51 <Shiz> i don't see how that relates to me being fine with not catering to mutual dependencies
18:51 <TemptorSent> Because SAT is bloody slow and degrades to exhaustive search of the space precicely because of unbounded cycles.
18:52 <TemptorSent> Currently, there is no semantic difference between a valid loop in the dep chain resulting in all deps being pulled and one in which it should fail.
18:53 <Shiz> clearly if i don't care about mutual deps, no loop is valid
18:53 <TemptorSent> (often seen with some package requiring another package for an optional tool like TeX
18:54 <TemptorSent> Okay, then we've got some serious problems in the current dep handling then I believe.
18:54 <Shiz> i wouldn't be surprised if we did :P
18:54 <TemptorSent> If every package can have its deps described as a DAG, we're good.
18:55 <Shiz> but my opinion is not necessarily those of the apk-tools authors
18:55 <Shiz> or of the other alpine devs
18:55 <TemptorSent> I'm looking at it from the standpoint of mathmatical consistency.
18:56 <TemptorSent> We can make certain guarentees with a DAG that we can't make with the possibility of cycles.
18:57 <Shiz> i believe that dependency management shouldn't have cycles
18:57 <TemptorSent> And we can tightly bound the number of itterations.
18:57 <Shiz> however
18:57 <Shiz> what we can do
18:57 <Shiz> is optional dependencies that may incur cycles
18:57 <Shiz> and are deselected when they do
18:58 <Shiz> for instance:
18:58 <Shiz> clang libc++abi relies on libc++ (without libc++abi support enabled) for whatever reason
18:58 <TemptorSent> That would be a viable solution, and would allow the creation of a complete DAG from the runs.
18:58 <Shiz> libc++ can (and in end-deployments, should) rely on libc++abi
18:59 <Shiz> so libc++abi would be an optional dependency of libc++, allowing both to work
18:59 <TemptorSent> First run creates the DAG with no optional deps, second run roots subtrees at each optional edge source.
18:59 <Shiz> it's probably better to discuss this with fabled/kaniinii btw
19:00 <TemptorSent> Yes, been working on it slowly when I can catch them.
19:00 <Shiz> but the libc++abi may be a different issue entirely since that's about run vs build deps too
19:01 <TemptorSent> Currently, I'm more after the underpinnings for the data structures so we can represent the DAGs as a hedge (set of intergrown trees)
19:02 <TemptorSent> As long as we can differentiate the edges based on the dep type, itterative growth and pruning is a reasonably easy approach for even complex deps.
19:03 <TemptorSent> Goes from linear to O(Nlog2N) IIRC.
19:04 <TemptorSent> I want to build a toolbox that we can use for many tasks rather than a single-purpose.
19:07 <TemptorSent> One is a minimal graph-structured database, another is a dep-solver using such database, another is a hashing/manifesting tool using the same graphdb tool to relate individual files to a given apk/package
19:07 <TemptorSent> Add the pax archiver, url handling, and signature functions, and you have APK
19:08 <TemptorSent> But also many generally useful tools.
19:10 <TemptorSent> Anyway, I need to get out and work in the garden a bit, then get my mining equipment ready for the season since the snow's finally melting off up towards my claims.
19:14 <Shiz> gl
19:32 cyteen joined
19:48 <jirutka> yeah, APK, just with infinity higher complexity… omfg
19:54 blueness joined
20:04 <TemptorSent> jirutka: Higher complexity? Have you read the source for apk?
20:06 <TemptorSent> What became of the unix philosophy to create, small, narrow scope, general purpose tools and use them together to accomplish tasks?
20:07 <TemptorSent> If apk 3 is as hard to follow in the code as apk 2, it's not much of an improvment IMHO
20:23 onox joined
21:04 <nidan_> TemptorSent: Most people doesn't seem to understand the UNIX philosophy, not that part of it anyway. Which is really sad for the rest of us. =/
21:15 <jirutka> nidan_: I actually understand the Unix philosophy quite well
21:33 <mosez> somebody got an idea how i can solve "PHP Notice: iconv(): Wrong charset, conversion from `UTF-8' to `ASCII//TRANSLIT' is not allowed" on alpine?
21:37 <jirutka> mosez: ah, you’re trying to solve my looong list of failing php tests? :)
21:38 <mosez> jirutka: i'm trying to build owncloud api docs on my alpine docker image :D
21:38 <jirutka> eh, aha
21:39 <jirutka> well, then I have bad news, this is one of many problems that fail in tests… https://github.com/alpinelinux/aports/blob/master/community/php7/disabled-tests.list
21:39 <jirutka> I don’t know how to solve it
21:43 <mosez> awesome... looks like i'm forced to use an ubuntu image like the guys before me :(
21:43 <jirutka> or figure out how to fix it ;)
21:44 <mosez> i really would like to, but i need these docs
21:45 <Shiz> mosez: musl iconv does not support //TRANSLIT
21:45 <Shiz> so if your php app uses that, that's the problem
21:45 <Shiz> patch it to not to
21:45 <Shiz> :P
21:54 <mosez> shiz: it's not my app... it's phpdocumentor
21:54 <mosez> god i really hate to work with php
21:54 <Shiz> https://github.com/phpDocumentor/phpDocumentor2/blob/68cf85e30aab12ce27bb8889f765f14705b2f7b9/src/DomainModel/Renderer/Router/Rule.php#L102
21:55 <Shiz> you can choose to not load the php7-iconv package
21:55 <Shiz> avoids that
21:55 <mosez> i'm downloading the phpdocumentor.phar because of no package for it :)
21:56 <mosez> maybe spmething i should try :(
22:13 <mosez> jirutka: just a guess without knowing further details, maybe some locales like https://github.com/rilian-la-te/musl-locales helps on that? idk...
22:13 <jirutka> hm, WDYT Shiz ?
22:14 <Shiz> it doesn't
22:14 <Shiz> this is just musl's iconv() implementation, mostly unrelated to the other locale stuff
22:14 <Shiz> it does not do //TRANSLIT on purpose
22:15 <jirutka> but can it help with other locale issues on musl?
22:18 <Shiz> some minor ones, i think
22:21 <mosez> so building the php ext against gnu-libiconv solves the issues with php? :)
22:48 minimalism joined