IRC Logs for #crux-devel Monday, 2015-03-23

*** Claus_ has quit IRC00:26
*** Claus_ has joined #crux-devel00:26
*** Claus_ has quit IRC01:09
*** ryuo has quit IRC03:04
*** ryuo has joined #crux-devel03:04
*** jue_ has joined #crux-devel03:24
*** mavrick61 has quit IRC03:30
*** mavrick61 has joined #crux-devel03:31
*** ryuo has quit IRC05:01
*** ryuo has joined #crux-devel05:03
*** nilp has joined #crux-devel06:39
*** nilp has quit IRC08:34
*** nilp has joined #crux-devel08:34
*** heroux has joined #crux-devel13:04
frinnstjue: are you planning on rolling a new prt-utils release soonish?17:03
juethe only change I have so far is the arm support for revdep17:06
jaegerI'm guessing that's why he's asking :D17:06
jueif that's important I can do a new release :)17:07
jueprobably tomorrow evening17:08
ryuojue, i have pondered adding a parallel (like make jobs) to the new revdep. do you think anyone would want that?17:09
ryuoparallel option*17:10
frinnstyes indeed thats why :)17:10
ryuoin my early draft of it, it was a noticeable improvement for 2 jobs.17:12
ryuobut it depends on the system.17:12
ryuoit can improve the total time taken, but i don't know if anyone cares. the single threaded optimization already has done a lot.17:13
jaegerIf it doesn't break anything, I don't object. The single-thread version is already way faster than the shell version17:13
ryuoi doubt it will, but i do need to write some code to handle jobs in a generic manner or else the code will become less manageable.17:14
ryuothis will be my first real time writing concurrently, but i have a sound mathematical approach.17:15
ryuodistribute n ports among k jobs.17:15
ryuoeach one will get n / k ports.17:16
ryuoone special port will get an extra n % k ports.17:16
ryuowhen k = 1, nothing should change.17:16
ryuowhen k > 1, the only thing i expect to change is the order of text output.17:17
pitillojue: can you check prt-utils dependencies... there is libz overthere17:41
ryuopitillo, the new revdep uses it.17:53
*** ryuo has quit IRC18:01
pitilloif it's used, then it should be added somewhere (not found in ports currently)19:52
jaegerah, good point, should be "zlib", not "libz"19:59
*** nilp has quit IRC20:03
*** Feksclaus has joined #crux-devel20:13
rmullzlib shouldn't be added because it's already in core20:19
rmullIsn't that the policy?20:19
jaegeris it a build-time requirement or run-time?21:13
RomsterUsage: revdep [-h] [-v|-vv|-vvv|-vvvv] [package...]21:50
Romsteris missing [-i package1[,package2,...]]21:50
Romsterwhen -i got added the usage never got updated21:51
Romsterrmull, it links to it but the static verson doens't depend on zlib in core so really i guess it's a build time dep now and should not be listed.21:52
Romsteron another note i found either prtsweep or prtwash depends on python and that is not listed as a dependency21:52
Romsteri know prtverify is ruby thta is also not listed21:53
*** nilp has joined #crux-devel21:57
*** nilp has quit IRC22:26
jueRomster: neither prtsweep nor prtwash are python programs, both are bash22:32
jueRomster: prtverify is written in bash/gawk22:32
juebut right, revdep has a build-time dep to elfutils, which should and is listed because it is a opt port22:36
juewhile libz is a) wrong, should be zlib and b) not necessary because it's a build-time-only dependency22:38
juenote: revdep is not a dynamic executable22:39
juepitillo: libz is a bogus dep for prt-utils, will remove it22:41
Worksterok one of them two compalined that python was not installed when i ran it in a docker container, i did not investigate as to why23:37
Worksteralso they nearly both do the same task. think prtwash and prtsweep need a overhaul into one prtclean program.23:38
Worksteryeah revdep you made static so zlib does not get listed23:38
Worksteri'm going to look at rewiting a prtclean script. if your keen one tool that does what prtwash and prtsweep do now.23:40

Generated by 2.11.0 by Marius Gedminas - find it at!