IRC Logs for #crux Saturday, 2015-03-14

onoderaonly webkit-gtk2 and firefox fail every single time00:06
onoderaother packages compile just fine00:06
onoderaand firefox also compiled fine on gentoo for me so I don't really know00:06
rmullSame CFLAGS on both systems?00:08
rmulland what processor?00:08
onoderayeag same cflags, I only use -O2 and -march=native00:25
onoderaoh but on gentoo I used -pipe, with crux I build in a tmp filesystem00:26
*** leo-unglaub has joined #crux00:27
*** leo-unglaub has left #crux ()00:27
rmullI would be interested to hear if you come across a solution00:50
onoderaI just tried compiling it a few times with -pipe and not in ram00:56
onoderafailed again ;_:00:56
*** dougl has quit IRC01:03
*** tilman has quit IRC01:04
*** tilman has joined #crux01:05
*** onodera has quit IRC01:38
Romsternwe, "gtk-update-icon-cache /usr/share/icons/Tango "in a post-install file for your tango-icon-theme02:14
Romsteronodera, run memtest86+ for a few hours.02:15
RomsterteK_, yes I am offering to help out with xfce.02:16
*** LMNOP_ has quit IRC02:37
*** LMNOP_ has joined #crux02:37
*** greduan has quit IRC03:24
*** mavrick61 has quit IRC03:36
*** mavrick61 has joined #crux03:37
*** xeirrr has joined #crux03:57
xeirrrRomster: Thanks for the latest chromium build. But I can't start it. This is the error from console03:58
xeirrrbash-4.3$ chromium03:59
xeirrr[0314/] Couldn't mmap v8 natives data file03:59
Romsterweird... i'll rebuild it again and upload it over the old one.04:19
Romsteri built it awhile ago and only now uploaded it04:19
Romsteractaully i'll check it with revdep after a sysup in this container first.04:21
*** xeirrr has quit IRC04:24
Romsteryou could check your system with revdep see if chromium gets reported. while waiting.04:25
*** SiFuh has quit IRC04:29
*** SiFuh has joined #crux04:31
Romsterrevdep says chromium is fine...04:32
Romsterrebuilds anyways04:33] Couldn't mmap v8 natives data file04:43
Romsterrebuilt it still seems broken.04:57
Romstersee a new realse 2 days ago 41.0.2272.89 i'll try building and testing that.04:58
*** ryuo has joined #crux05:43
*** nilp has joined #crux07:15
tilmanRomster: want to update livestreamer? 1.12 is out07:31
cruxbot[contrib.git/3.1]: livestreamer: 1.11.1 -> 1.12.008:11
Romsternp wonder howic an watch github projects for new releases without using the follow all on it.08:14
Romsterconsidering i am using github as well08:14
Romstermaybe staring it is enough08:14
*** namra has joined #crux09:47
*** Feksclaus has joined #crux10:06
*** Pingax has quit IRC10:18
*** Pingax has joined #crux10:19
*** Kevin-Leo has joined #crux10:23
*** Kevin-Leo has quit IRC10:25
*** malya has joined #crux10:29
malyaIs there contributed 3.1 iso for i686 system?10:30
*** xeirrr has joined #crux10:42
xeirrrRomster: Hi, I just test chromium-41.0.2272.89, the problem is still there: [0314/] Couldn't mmap v8 natives data file10:43
xeirrrCan someone else share your chromium build?10:45
xeirrrMine is a netbook, dual core, with cpu 1.65G Hz, so It will take nearly half day to build chromium10:47
RomsterI know i cna't fix it it builds fine10:53
Romsteri don't know the problem10:54
xeirrrRomster: do you haee such issue? can you start it from console to see it?10:56
Romsteri did that10:57
Romster[0314/] Couldn't mmap v8 natives data file10:57
xeirrris it ok?10:57
Romsternot tested it10:58
xeirrrI see Status: Fixed, but we are suffering11:03
tilmani'd try running chromium in "strace -e mmap" to try and see what's failing11:07
Romsterbe nice if they supplied a patch on that bug report11:10
Romsteror maybe this is it
Romsterbu that's 2014 can't be it.11:11
Romsterso a file is missing11:16
*** xeirrr has quit IRC11:21
*** Feksclaus has quit IRC11:24
ryuommap(NULL, 0, PROT_READ, MAP_SHARED, -1, 0) = -1 EBADF (Bad file descriptor)11:24
ryuoit is trying to mmap a bad file descriptor.11:24
ryuoNo shit.11:24
ryuoRomster, you also need to look for a recent OPEN that failed.11:25
ryuothat may tell you what it was trying to mmap.11:25
Romster#if defined(V8_USE_EXTERNAL_STARTUP_DATA)11:25
Romsterin that data block and a single function11:26
ryuoRomster, because to mmap files you first must get a FD with 'open' then use 'mmap'.11:26
RomsterI realize there will be a file descriptor11:26
*** xeirrr has joined #crux11:27
Romsterit'll be something calling this function as the file is part of the function arguments11:27
ryuoRomster, perhaps you can go a strace on the open function too to see what the last file that failed to open was? it sounds like chromium doesn't always check for open failure. :P11:28
Romsterthats an idea11:28
ryuothere's other things that it could be using... but it is likely it used open.11:29
Romsteropen("/usr/lib/chromium/natives_blob.bin", O_RDONLY) = -1 ENOENT (No such file or directory)11:30
Romsterthere we go11:30
Romstermaybe that bug11:31
Romsterlooks like it but it's way too deep for me11:32
ryuomore likely this file is missing for some reason and it needs it.11:33
*** xeirrr has quit IRC11:33
*** xeirrr has joined #crux11:33
ryuoarchlinux has that file.11:34
ryuoi wonder why crux does not?11:34
ryuoi'd say this may be a packaging bug where a required file is not installed.11:34
Romsterchromium-webkit-buffer-overflow.patch that does not solve this issue11:34
Romsteri already tried11:34
ryuoRomster, i didn't say that it did.11:34
Romsterand aditionally it's for hardening11:34
Romsterand newer ICU11:35
ryuobut they are doing SOMETHING right.11:35
Romsteris this a suprise?11:35
ryuoi'm just pointing out that you need to look at the chromium packaging. that's the likely issue.11:35
ryuobut it's not obvious from where i'm sitting.11:36
xeirrrryuo: Do you  have such issue?11:36
ryuoxeirrr, obviously not. i don't use CRUX. i was just trying to help Romster solve it.11:36
Romsteri now 115 worked11:37
Romsterdesktop-file-utils was removed from deps. As is done in firefox, the .desktop11:37
Romsterfile is provided but their use is left to the user's choice.11:37
ryuoRomster, I think i found a potential culprit.11:38
ryuocp out/Release/{*.pak,*.bin,,} \11:38
ryuo    "$pkgdir/usr/lib/chromium/"11:38
ryuofrom the ARCH script.11:38
ryuoNotice how they include *.bin.11:39
ryuoI don't see anything comparable in the CRUX script.11:39
ryuoSo, this is the most likely place to start.11:40
xeirrrMaybe we need to install *.bin to /usr/lib/chromium11:43
Romsterwhy the heck and its got binary blobs in it... why am i not surprised11:46
xeirrrYeah, that's exactly it.11:50
Romsteri don't care if it's for pepperfish or wtf it's called.11:51
Romster-Dclang_use_chrome_plugins=0 <- bet that is it11:51
xeirrrI just download chromium packages, extract it and copy snapshot-blob and natives-blob bins to /usr/lib/chromium. Last I try to start from console. no error!11:52
Romsteruh but then i don't have clang in my build environment...11:52
xeirrrI mean package from arch linux11:53
Romsterthere not even in the source archive... why.11:53
ryuoRomster, they're probably built during the build.11:54
Romsteryou know what install docker go grab a prebuilt chrome11:57
Romsterpos browser.11:57
ryuoRomster, shh. you'll hurt its feelings. :( lol11:58
Romsterxeirrr, can you file a big for sepen since you found it.11:58
Romsterrebuilt it 3 times for nothing -_-11:59
xeirrrRomster: I'll do11:59
Romsterwtf is this right chromium has its own toolchain and glib... that ebuild seems to suggest this12:05
Romster# Needed for system icu - we don't need additional data files.12:06
Romstermyconf+=" -Dicu_use_data_file_flag=0"12:06
Romsteri wonder12:06
Romsterbut that's already there...12:09
Romsterreally browser12:09
Romsteradds -Duse_system_icu=1 and compiles again12:10
Romsteri hate being beaten12:12
Romsteri might of found why ^12:13
xeirrrwhat flsgs did you add to compile chromium again?12:14
Romsteri just added -Duse_system_icu=112:15
Romsteras i see -Dicu_use_data_file_flag=0 is already set12:15
Romsterand i was looking though the ebuild for it12:15
Romsterand seen that bundled icu uses extra binary files.12:15
xeirrrI am wondering this maybe issue with these two blobs12:16
Romsterwe disable those but still used the bundled icu12:16
xeirrrgood luck12:17
ryuoRomster, peak-a-boo icu! :P12:17
Romsterso either adding -Duse_system_icu=1 or removing -Dicu_use_data_file_flag=0 should solve it12:17
RomsterUpdating projects from gyp files...12:18
Romstergyp: Duplicate target definitions for third_party/icu/icu.gyp:icudata#target12:18
Romsterand the first way does not work12:18
Romsterso surprising.12:18
Romstertries second way12:19
ryuoit's always the last solution you try that works.12:21
Romsterthe one least preferred12:26
Romsterwill see if .footprint has them missing files after this.12:27
*** malya has quit IRC12:28
xeirrrRomster: does it work?12:42
Romster[0314/] Couldn't mmap /usr/lib/chromium/icudtl.dat12:49
Romster[0314/] Check failed: base::i18n::InitializeICU().12:49
Romsteri give up12:49
*** onodera has joined #crux12:52
*** xeirrr has quit IRC14:25
*** mhe has joined #crux14:28
*** dougl has joined #crux14:30
*** namra has quit IRC14:50
*** LMNOP__ has joined #crux14:59
*** LMNOP_ has quit IRC15:00
rmullRomster: What program is throwing that error?15:05
rmulla compiler?15:05
*** lnds has joined #crux15:14
*** dougl has quit IRC15:19
rmullHere's a thought experiment: how could might someone verify that a program running on a remote system was the same as the local copy of a binary for which you have the checksum?15:38
rmullor: How might one verify that a binary built on a different platform was definitely built from a set of checksummed sources?15:39
ryuormull, i'm not sure how you would do that. the generated code isn't guaranteed to be identical each time.15:42
ryuormull, it differs depending on gcc version, optimization levels, etc.15:42
ryuoEven if the source is the same.15:42
ryuothe resulting binary can be different.15:43
rmullYes, that's the challenge15:43
*** Pingax has quit IRC15:44
*** Pingax has joined #crux15:45
rmullEven more of a challenge would be accounting for the dynamic links15:45
rmullThe hypothetical scenario is that there is a network formed by machines running some software that depends on the software being built from the verified source code with no known backdoors15:46
rmullThe network fails if someone tweaks the software to say, add eavesdropping, and then joins their node to the network15:46
rmullCan it be prevented?15:47
rmullNot that buidling the modified code should be prevented, but the rest of the nodes should figure out not to trust the modified node15:48
rmullprobably impossible15:49
diverseit sounds like you might want to statically link from the verified source node15:49
rmullIt would seem to me that as long as the malicious node knows the checksum, it'll be able to spoof it when communicating with the other nodes15:50
rmulland knowing the checksum is required in order to validate other nodes in the first place15:51
diverseare all the nodes running the same OS and configured the same way?15:53
*** fengshaun_ has quit IRC15:53
rmullno, not necessarily15:53
rmullbinaries could be different given identical sources15:53
rmullbut maybe something could be achieved with a VM of some sort?15:54
rmullHeh, there's another idea... what about a virtual machine that joins a network and forms a huge address space with all the other VMs and their loaded programs15:55
rmullThen any VM could execute the code on any other VM or something15:55
rmullsort of a cloud OS15:56
diversemore like the cloud OS would be the solution15:58
diversehave one system with all the software on it for other systems to remotely use15:59
diverseand therefore you can checksum check for malicious changes on that one system15:59
rmulli will ponder16:00
rmullthank you for your participation16:00
diverseno problem16:00
rmullThe "real" problem is in how to prevent bitcoin nodes from logging the addressing info of wallets that connect to them in order to relay transactions to the network16:00
rmullIt's sort of leaky, and right now the solution is to use tor16:01
rmullBut I was wondering if there was a better way16:01
rmullThe goal being not to be able to associate your identity (in this case, an IP address) with your financial transaction16:02
rmullAnd the more general problem is how do you verify the trustworthiness of a distributed network of nodes16:03
rmullThere's the "web of trust" model that's been around forever so maybe the solution is somewhere in that16:04
*** dougl has joined #crux16:16
*** hhhhhhhh has quit IRC16:25
*** hhhhhhhh has joined #crux16:31
*** dougl has quit IRC17:22
*** asie has joined #crux18:11
*** dougl has joined #crux18:40
*** fengshaun_ has joined #crux19:04
*** dougl has quit IRC19:26
*** mhe has quit IRC19:29
*** SiFuh has quit IRC19:36
*** asie has quit IRC20:30
*** deus_ex has quit IRC20:34
*** deus_ex has joined #crux20:34
*** pejman has quit IRC20:41
*** pejman has joined #crux20:42
*** pejman has quit IRC20:52
*** pejman has joined #crux20:53
*** pejman has quit IRC20:53
*** pejman has joined #crux20:53
*** pejman has quit IRC20:58
*** pejman has joined #crux20:59
*** pejman has quit IRC21:16
*** pejman has joined #crux21:16
*** pejman has quit IRC21:21
*** tilman has quit IRC21:23
*** pejman has joined #crux21:28
*** pejman has quit IRC21:28
*** pejman has joined #crux21:28
*** tilman has joined #crux21:29
*** onodera has quit IRC21:38
*** pejman has quit IRC21:43
*** pejman has joined #crux21:44
*** pejman has quit IRC21:44
*** pejman has joined #crux21:44
*** kori has quit IRC21:52
*** kori has joined #crux22:05
*** mhe has joined #crux22:06
mheany link for recent i686 binaries for opt, contrib?22:06
*** LMNOP_ has joined #crux22:09
*** LMNOP__ has quit IRC22:11
*** dougl has joined #crux22:20
*** Feksclaus has joined #crux22:29
jaegermhe: I don't think anyone is maintaining binaries for i686 currently22:37
mheno problem, thanks for letting me know22:41
*** dougiel has joined #crux23:02
*** dougl has quit IRC23:03
*** arduo has joined #crux23:26
*** lnds has quit IRC23:28
*** ryuo has quit IRC23:56

Generated by 2.11.0 by Marius Gedminas - find it at!