IRC Logs for #crux-devel Wednesday, 2018-11-21

*** heroux has joined #crux-devel03:47
frinnstsignature error on .footprint for perl09:49
juethx, fixed now09:53
*** frinnst has joined #crux-devel13:44
frinnstthoughts about defaulting to python3 for 3.5?14:26
pedjawill python still be shipped, but as python2?14:32
juewell, if I look at the arch's dependency list for python2 I have my doubts14:34
pedja2/3 of that are python modules, iirc14:34
juepedja: oc, going without python2 is impossible IMO14:34
jue2/3 of 1187 is still too much ;)14:35
pedjaheh. agreed14:35
jaegerI've got no objection to defaulting to 3 but 2 needs to be available, yeah14:35
pedjajaeger, OT, one of your mate ports seems to be broken by some port name changes. mozo, iirc14:41
frinnsteverything i've tested without python 2 has "worked" - just had to do some minor modifications.14:41
frinnstbut point taken. I dont have that many ports on my systems so not *that* much to test with14:42
jaegeryeah, I saw that, will check them14:45
jueif we have to ship both versions I don't see the big point in renaming python to python2 and python3 to python14:46
juebut I might missed something ;) at all I'm with jaeger, if it makes sense I have no objections14:47
jaegerI think the main point is to switch to 3 by default before the 2 EoL happens in 1 year14:47
jueI don't believe that this EoL will happen actually ;)14:48
jaegerTo be honest, it won't surprise me if that gets pushed back14:49
jaegerpython 2 is tenacious like windows xp :D14:49
pedjacalibre author said he will maintain it :)14:49
juebut we will see, currently you cannot build e.g. samba and friends with python314:50
pedjathat's on the roadmap for 4.10, I think (spring 2019)14:53
pedjabut will it happen is anyone's guess14:54
pedjaimho, python3 as the default, and python2 for special snowflakes makes sense14:57
pedjaany thoughts on fs#1684?14:59
pedjaapparently, shipping the pem bundle is 'legacy' these days :)15:01
frinnsthavent seen that ticket before15:05
pedjacommands there need a little change (s/pem-bundle/pem-direcory), but they do make gnutls-cli work15:11
pedjaopensuse, afaict, ships both the bundle and extracted certificates, to cover the legacy and 'modern' use cases, I guess15:19
*** jue has joined #crux-devel16:28
*** onodera has joined #crux-devel18:08
jaegerpackage management related programming question - what data structure do you think would be the best for a simple package DB like we use in crux? For my C pkgutils futzing, I've played with binary search trees, hash tables, dynamic arrays, and linked lists so far. Seems to me that linked lists might be the best choice for in-memory storage of the package db but I'm open to opinions on the matter19:40
jaegerbinary search trees work fine but since the input (the package db) is already sorted, the BST layout is not ideal19:40
jaegerdon't really have much to say about hash tables at the moment.19:41
jaegerdynamic arrays work fine but you do waste some memory when growing the array size19:41
jaegerlinked lists would keep the size from ballooning but incur a hit on pointers and rearranging links19:42
jaegerNot that any of these differences are particularly visible to a user19:42
jaegerIf I remember correctly from looking at the pkgutils c++ code a while back, it uses vectors (dynamic arrays) for this19:46
*** onodera has quit IRC21:27

Generated by 2.14.0 by Marius Gedminas - find it at!