14:12 < mmilata> rmarko: https://github.com/abrt/satyr/issues/66 - mel by byt duphash z core backtrace byt pro stejny crash stejny jako pro gdb backtrace? bude se to delat ve fafu, takze budou k dispozici vsechny jmena funkci?
14:14 < rmarko> mmilata: no idealne robit hashovanie pre vsetky typy rovnako, teda asi z core backtrace
14:14 < rmarko> nad zvysok sa musim zamysliet este
14:14 < rmarko> zyskom
14:14 < rmarko> ..
14:18 < jfilak> mmilata, je to tam
14:19 < rmarko> vo fafe aktualne hashujeme funcname + path v pripade ze vsetky funkcie maju mena
14:19 < rmarko> pokial je to python crash tak sa pridava offset este
14:19 < rmarko> ak nie su dostupne vsetky mena fcii tak sa hashuje funchash + path
14:19 < rmarko> random
14:21 < mmilata> rmarko: aha, takze ve fafu je na to jiny algoritmus nez co je v btparseru?
14:21 < rmarko> mmilata: no prave
14:22 < rmarko> idealne zobrat to co je univerzalne dostupne medzi roznymi typmi a hashovat to
14:22 < rmarko> path + offset  ?
14:22 < mmilata> rmarko: takze by to melo byt zpetne kompatibilni s fafem? nebo faf pocita pro gdb stejny hash jako btparser?
14:22 < rmarko> no prave zahodit to co je vo fafe a vsade pouzivat satyr na hashovanie
14:23 < rmarko> nech je to jednotne medzi serverom a klientmi
14:23 < mmilata> a nejakou zpetnou kompatibilitu nechceme zachovat?
14:23 < rmarko> dobra otazka :)
14:24  -!- vpodzime <~vpodzime@10.34.102.69> has quit (Quit: Leaving)
14:24 < rmarko> kompatibilita tam skor bude stylom ureport1 vs ureport2
14:24 < rmarko> kde ureport2 nech pouziva nove hashovanie 
14:24 < rmarko> ureport1 po starom
14:32 < mmilata> rmarko: a jakou ma vyhodu hashovat jenom to co je univerzalne dostupne pro vsechny typy framu?
14:33 < rmarko> mmilata: jednoduchost :)
14:34 < mmilata> rmarko: jednoduchost pro koho?:)
14:34 < rmarko> + sa zbavit toho problemu, ze obcas mas ureport s menami funkcii a obcas nie
14:35 < rmarko> mmilata: nemusi to byt nutne tak, kludne nech to hashuje vsetko mozne ale rovnako na oboch stranach
14:35 < mmilata> tady bych pocital s tim ze tam ty jmena nejsou (pokud se kazdy ccpp ureport nebude retracovat)
14:35 < rmarko> jjj
14:35 < rmarko> no ono aj ked sa retracuje tak obcas sa niektore nepodari doplnit
14:35 < rmarko> a momentalne sa retracuje az potom ako sa spocita hash
14:36 < mmilata> nicmene ted kdyby se pro ccpp hashovaly build id tak stejny problem ve dvou ruznych verzich baliku bude mit ruzny hash
14:37 < rmarko> no, nakoniec ti z toho aj tak vypadne ta univerzalne dostupna cast :D
14:39 < mmilata> rmarko: asi bych potreboval vysvetlit k cemu se ty duphashe vlastne pouzivaji
14:39 * mmilata je dneska nejaky tupy
14:39 < rmarko> -//-
14:39 < rmarko> mmilata: k prvotnej deduplikacii, sa spocita duphash a podla toho sa hlada v db
14:40 < rmarko> rovnako ako v bugzille v podstate
14:40 < mmilata> takze klient posila hash jeste predtim nez posle ureport?
14:40 < rmarko> nie, klient posle ureport 
14:40 < rmarko> a ten sa hashne na servri
14:41 < rmarko> ktory podla toho vyhladava v db a odpoveda known/unknown
14:44 < mmilata> takze kdyz mame false negative (known report, ale hash je jiny), rekneme v dusledku toho ze se reportuje jina verze, tak to bude reportovani do bugzilly chtit jenom po prvnim cloveku co to reportuje
14:44 < mmilata> a casem se to zclusteruje k ostatnim existujicim reportum?
14:44 < rmarko> jj, tak
14:45 < rmarko> co si myslim ze sa stava casto je to, ze niektore reporty maju funcnames a niektore nie
14:45 * jfilak \o/
14:45 * rmarko \o/
14:46 < mmilata> a retracovani pro kazdy ureport kde nejsou si nemuzeme dovolit, pripadne by to bylo moc prace napsat?
14:46 < jfilak> mmilata, to musi byt rychle, okamzite, bez cekani
14:46 < rmarko> no ale zbytocne imho
14:46 < rmarko> jj
14:47 < rmarko> a je to nespolahlive, nemusi byt fetchnute debuginfo, nopy, ...
14:47 < mmilata> jasne
14:47 < mmilata> rmarko: a jak se to pouziva v bugzille? tam ten hash pocita klient nebo taky faf?
14:48 < rmarko> mmilata: klient
14:49 < jfilak> mmilata, rmarko jenze na klientovi se pocita hash jen ze 3 hornich normalizovanych framu aby to bylo trosku soft
14:49 < mmilata> a ve fafu ne?
14:49 < rmarko> tam je ine cislo :)
14:49 < rmarko> ~16
14:49 < mmilata> /o\
14:49 < rmarko> no ved toto :D
14:50 < mmilata> a to ze klient i faf pocitaji jine cislo chceme zachovat?
14:51 < mmilata> a kdyz to pocita klient, nema uz tou dobou vsechny jmena funkci?
14:52 < jfilak> mmilata, ano ma
14:52 < jfilak> mmilata, cilem je aby to klient nemusel nikdy pocitat
14:53 < mmilata> jfilak: takze hlavni use-case je ta prvotni deduplikace ve fafu a pocitani u klienta mam ignorovat?
14:54 < jfilak> mmilata, rmarko faf vlastne pocita hash uplne jinak
14:54 < rmarko> :D
14:54 < rmarko> z ineho poctu
14:54 < jfilak> faf ma hash k tomu aby oznacil ureport
14:54 < jfilak> 16 frame se pouziva pro shlukovani
14:55 < rmarko> nie
14:55 < rmarko> 16 aj pri hashovani
14:58 < rmarko> mmilata: chce to pocet framov ako parameter
14:59 < rmarko> nech sa da na servri hashovat s N a v pripade reportovania do bugzilly s M
14:59 < rmarko> ale rovnakou fciou
14:59 < mmilata> to by nemel byt problem
14:59 < rmarko> jo
14:59 < rmarko> napisem ti nejaky pokec do ticketu
14:59 < mmilata> jestli se ti chce