Gajim - 2015-08-18


  1. tmolitor Link Mauve, Asterix, arune: yes, using the metadata from the head request would be good...and as for the cache cleanup: the answer is yes and no...given that todays harddisks are big enough to cache more images than you would ever receive there should be an option to disable the automatic cache cleaning altogether, but there should be a cache cleaning mechanism for people with stricter space requirements/privacy concerns etc....this cleanup could be time based or space based (or - ideally - both)...
  2. Link Mauve Err, automated caching of very big images doesn’t seem like a good idea without a cache eviction mechanism in any case.
  3. Link Mauve You could take inspiration from browsers’ handling of their cache, if you want.
  4. tmolitor Link Mauve, arune: you could display some settings to whitelist jids for the automatic download if you don't want to automatically download files from all peaople in your roster...that whitelist could support full jids or only the server part of a jid to whitelist people...I think that would be ideal for people with privacy concerns...and all other people could select to not use the whitelist and download files from all contacts in their roster...but I would never include an option to activate automatic downloads for ALL contacts (even the ones NOT in your roster)...that would be something silly people could activate without knowing the consequences....
  5. Link Mauve tmolitor, yeah.
  6. tmolitor Link Mauve, arune: I think it depends, I personally would deactivate the cache cleanup because I would use the cache as file storage, too....so I can go into the cache directory and search for that image file some people send me some month ago (which possibly isn't on the http server anymore, so redownload is not always an option)...
  7. tmolitor the cache cleanup settings should be configurable in the plugin...
  8. tmolitor Link Mauve: I think this whitelist would be the ideal way to go :)
  9. Link Mauve Yeah, alongside with some cache eviction system.
  10. Link Mauve The algorithm isn’t very important, it’s always tweakable.
  11. tmolitor yes, right :)
  12. Link Mauve This could also be used for XEP-0231 without much effort.
  13. tmolitor arune: if you need some hands in implementing this proposal (given that you want to implement this), I could help you :)
  14. tmolitor Link Mauve: hmmm...yes, this would benefit from some caching mechanism also :)
  15. tmolitor I'm going to bed now, good night everybody...
  16. tmolitor Link Mauve, Asterix, arune: yes, using the metadata from the head request would be good...and as for the cache cleanup: the answer is yes and no...given that todays harddisks are big enough to cache more images than you would ever receive there should be an option to disable the automatic cache cleaning altogether, but there should be a cache cleaning mechanism for people with stricter space requirements/privacy concerns etc....this cleanup could be time based or space based (or - ideally - both)...
  17. tmolitor Link Mauve, arune: you could display some settings to whitelist jids for the automatic download if you don't want to automatically download files from all peaople in your roster...that whitelist could support full jids or only the server part of a jid to whitelist people...I think that would be ideal for people with privacy concerns...and all other people could select to not use the whitelist and download files from all contacts in their roster...but I would never include an option to activate automatic downloads for ALL contacts (even the ones NOT in your roster)...that would be something silly people could activate without knowing the consequences....
  18. tmolitor Link Mauve, arune: I think it depends, I personally would deactivate the cache cleanup because I would use the cache as file storage, too....so I can go into the cache directory and search for that image file some people send me some month ago (which possibly isn't on the http server anymore, so redownload is not always an option)...
  19. tmolitor the cache cleanup settings should be configurable in the plugin...
  20. tmolitor Link Mauve: I think this whitelist would be the ideal way to go :)
  21. tmolitor yes, right :)
  22. tmolitor arune: if you need some hands in implementing this proposal (given that you want to implement this), I could help you :)
  23. tmolitor Link Mauve: hmmm...yes, this would benefit from some caching mechanism also :)
  24. tmolitor I'm going to bed now, good night everybody...
  25. tmolitor Link Mauve, Asterix, arune: yes, using the metadata from the head request would be good...and as for the cache cleanup: the answer is yes and no...given that todays harddisks are big enough to cache more images than you would ever receive there should be an option to disable the automatic cache cleaning altogether, but there should be a cache cleaning mechanism for people with stricter space requirements/privacy concerns etc....this cleanup could be time based or space based (or - ideally - both)...
  26. tmolitor Link Mauve, arune: you could display some settings to whitelist jids for the automatic download if you don't want to automatically download files from all peaople in your roster...that whitelist could support full jids or only the server part of a jid to whitelist people...I think that would be ideal for people with privacy concerns...and all other people could select to not use the whitelist and download files from all contacts in their roster...but I would never include an option to activate automatic downloads for ALL contacts (even the ones NOT in your roster)...that would be something silly people could activate without knowing the consequences....
  27. tmolitor Link Mauve, arune: I think it depends, I personally would deactivate the cache cleanup because I would use the cache as file storage, too....so I can go into the cache directory and search for that image file some people send me some month ago (which possibly isn't on the http server anymore, so redownload is not always an option)...
  28. tmolitor the cache cleanup settings should be configurable in the plugin...
  29. tmolitor Link Mauve: I think this whitelist would be the ideal way to go :)
  30. tmolitor yes, right :)
  31. tmolitor arune: if you need some hands in implementing this proposal (given that you want to implement this), I could help you :)
  32. tmolitor Link Mauve: hmmm...yes, this would benefit from some caching mechanism also :)
  33. tmolitor I'm going to bed now, good night everybody...
  34. Link Mauve tmolitor, please don’t spam the room like that.
  35. Link Mauve We’ve read you the first time.
  36. tmolitor Link Mauve, Asterix, arune: yes, using the metadata from the head request would be good...and as for the cache cleanup: the answer is yes and no...given that todays harddisks are big enough to cache more images than you would ever receive there should be an option to disable the automatic cache cleaning altogether, but there should be a cache cleaning mechanism for people with stricter space requirements/privacy concerns etc....this cleanup could be time based or space based (or - ideally - both)...
  37. tmolitor Link Mauve, arune: you could display some settings to whitelist jids for the automatic download if you don't want to automatically download files from all peaople in your roster...that whitelist could support full jids or only the server part of a jid to whitelist people...I think that would be ideal for people with privacy concerns...and all other people could select to not use the whitelist and download files from all contacts in their roster...but I would never include an option to activate automatic downloads for ALL contacts (even the ones NOT in your roster)...that would be something silly people could activate without knowing the consequences....
  38. tmolitor Link Mauve, arune: I think it depends, I personally would deactivate the cache cleanup because I would use the cache as file storage, too....so I can go into the cache directory and search for that image file some people send me some month ago (which possibly isn't on the http server anymore, so redownload is not always an option)...
  39. tmolitor the cache cleanup settings should be configurable in the plugin...
  40. tmolitor Link Mauve: I think this whitelist would be the ideal way to go :)
  41. tmolitor yes, right :)
  42. tmolitor arune: if you need some hands in implementing this proposal (given that you want to implement this), I could help you :)
  43. tmolitor Link Mauve: hmmm...yes, this would benefit from some caching mechanism also :)
  44. tmolitor I'm going to bed now, good night everybody...
  45. Link Mauve Erm…
  46. tmolitor Link Mauve, Asterix, arune: yes, using the metadata from the head request would be good...and as for the cache cleanup: the answer is yes and no...given that todays harddisks are big enough to cache more images than you would ever receive there should be an option to disable the automatic cache cleaning altogether, but there should be a cache cleaning mechanism for people with stricter space requirements/privacy concerns etc....this cleanup could be time based or space based (or - ideally - both)...
  47. tmolitor Link Mauve, arune: you could display some settings to whitelist jids for the automatic download if you don't want to automatically download files from all peaople in your roster...that whitelist could support full jids or only the server part of a jid to whitelist people...I think that would be ideal for people with privacy concerns...and all other people could select to not use the whitelist and download files from all contacts in their roster...but I would never include an option to activate automatic downloads for ALL contacts (even the ones NOT in your roster)...that would be something silly people could activate without knowing the consequences....
  48. tmolitor Link Mauve, arune: I think it depends, I personally would deactivate the cache cleanup because I would use the cache as file storage, too....so I can go into the cache directory and search for that image file some people send me some month ago (which possibly isn't on the http server anymore, so redownload is not always an option)...
  49. tmolitor the cache cleanup settings should be configurable in the plugin...
  50. tmolitor Link Mauve: I think this whitelist would be the ideal way to go :)
  51. tmolitor yes, right :)
  52. tmolitor arune: if you need some hands in implementing this proposal (given that you want to implement this), I could help you :)
  53. tmolitor Link Mauve: hmmm...yes, this would benefit from some caching mechanism also :)
  54. tmolitor I'm going to bed now, good night everybody...
  55. tmolitor Link Mauve, Asterix, arune: yes, using the metadata from the head request would be good...and as for the cache cleanup: the answer is yes and no...given that todays harddisks are big enough to cache more images than you would ever receive there should be an option to disable the automatic cache cleaning altogether, but there should be a cache cleaning mechanism for people with stricter space requirements/privacy concerns etc....this cleanup could be time based or space based (or - ideally - both)...
  56. tmolitor Link Mauve, arune: you could display some settings to whitelist jids for the automatic download if you don't want to automatically download files from all peaople in your roster...that whitelist could support full jids or only the server part of a jid to whitelist people...I think that would be ideal for people with privacy concerns...and all other people could select to not use the whitelist and download files from all contacts in their roster...but I would never include an option to activate automatic downloads for ALL contacts (even the ones NOT in your roster)...that would be something silly people could activate without knowing the consequences....
  57. tmolitor Link Mauve, arune: I think it depends, I personally would deactivate the cache cleanup because I would use the cache as file storage, too....so I can go into the cache directory and search for that image file some people send me some month ago (which possibly isn't on the http server anymore, so redownload is not always an option)...
  58. tmolitor the cache cleanup settings should be configurable in the plugin...
  59. tmolitor Link Mauve: I think this whitelist would be the ideal way to go :)
  60. tmolitor yes, right :)
  61. tmolitor arune: if you need some hands in implementing this proposal (given that you want to implement this), I could help you :)
  62. tmolitor Link Mauve: hmmm...yes, this would benefit from some caching mechanism also :)
  63. tmolitor I'm going to bed now, good night everybody...
  64. tmolitor Link Mauve, Asterix, arune: yes, using the metadata from the head request would be good...and as for the cache cleanup: the answer is yes and no...given that todays harddisks are big enough to cache more images than you would ever receive there should be an option to disable the automatic cache cleaning altogether, but there should be a cache cleaning mechanism for people with stricter space requirements/privacy concerns etc....this cleanup could be time based or space based (or - ideally - both)...
  65. tmolitor Link Mauve, arune: you could display some settings to whitelist jids for the automatic download if you don't want to automatically download files from all peaople in your roster...that whitelist could support full jids or only the server part of a jid to whitelist people...I think that would be ideal for people with privacy concerns...and all other people could select to not use the whitelist and download files from all contacts in their roster...but I would never include an option to activate automatic downloads for ALL contacts (even the ones NOT in your roster)...that would be something silly people could activate without knowing the consequences....
  66. tmolitor Link Mauve, arune: I think it depends, I personally would deactivate the cache cleanup because I would use the cache as file storage, too....so I can go into the cache directory and search for that image file some people send me some month ago (which possibly isn't on the http server anymore, so redownload is not always an option)...
  67. tmolitor the cache cleanup settings should be configurable in the plugin...
  68. tmolitor Link Mauve: I think this whitelist would be the ideal way to go :)
  69. tmolitor yes, right :)
  70. tmolitor arune: if you need some hands in implementing this proposal (given that you want to implement this), I could help you :)
  71. tmolitor Link Mauve: hmmm...yes, this would benefit from some caching mechanism also :)
  72. tmolitor I'm going to bed now, good night everybody...
  73. tmolitor Link Mauve, Asterix, arune: yes, using the metadata from the head request would be good...and as for the cache cleanup: the answer is yes and no...given that todays harddisks are big enough to cache more images than you would ever receive there should be an option to disable the automatic cache cleaning altogether, but there should be a cache cleaning mechanism for people with stricter space requirements/privacy concerns etc....this cleanup could be time based or space based (or - ideally - both)...
  74. tmolitor Link Mauve, arune: you could display some settings to whitelist jids for the automatic download if you don't want to automatically download files from all peaople in your roster...that whitelist could support full jids or only the server part of a jid to whitelist people...I think that would be ideal for people with privacy concerns...and all other people could select to not use the whitelist and download files from all contacts in their roster...but I would never include an option to activate automatic downloads for ALL contacts (even the ones NOT in your roster)...that would be something silly people could activate without knowing the consequences....
  75. tmolitor Link Mauve, arune: I think it depends, I personally would deactivate the cache cleanup because I would use the cache as file storage, too....so I can go into the cache directory and search for that image file some people send me some month ago (which possibly isn't on the http server anymore, so redownload is not always an option)...
  76. tmolitor the cache cleanup settings should be configurable in the plugin...
  77. tmolitor Link Mauve: I think this whitelist would be the ideal way to go :)
  78. tmolitor yes, right :)
  79. tmolitor arune: if you need some hands in implementing this proposal (given that you want to implement this), I could help you :)
  80. tmolitor Link Mauve: hmmm...yes, this would benefit from some caching mechanism also :)
  81. tmolitor I'm going to bed now, good night everybody...
  82. d-ion Hello
  83. d-ion I have a problem with gajim not starting after I've updated openssl libraries. Constantly says 'Gajim needs python-nbxmpp to run. Quiting...' even though it was there all the time.
  84. d-ion tried updating to latest available Gajim(0.16.3) and nbxmpp(0.5.3)
  85. d-ion with no luck
  86. d-ion Can anyone suggest a way to start tackling this issue?
  87. Link Mauve d-ion, what happens in a python2 shell when you run >>> import nbxmpp
  88. d-ion Like... how do I know where Gajim searches for that nbxmpp lib? or why it doesn't like what it finds?
  89. d-ion aha! there's a bunch of messages appears...
  90. d-ion last string being: ... File "/usr/lib/python2.7/ssl.py", line 97, in <module> import _ssl # if we can't import it, let the error propagate ImportError: /usr/lib/python2.7/lib-dynload/_ssl.so: undefined symbol: EC_KEY_new_by_curve_name
  91. mathieui did you fail a system upgrade or something?
  92. Link Mauve This sounds like python2 would need to be rebuilt against this new openssl.
  93. d-ion mathieui: changes in USE-flags
  94. d-ion specifically - 'bindist' flag
  95. d-ion yep, will try rebuilding it right away
  96. d-ion that fixed the problem
  97. d-ion thank you, Link Mauve
  98. Link Mauve :)
  99. d-ion python is alien to me :)
  100. d-ion thanks for your time and have a nice day!
  101. tmolitor Link Mauve, Asterix, arune: yes, using the metadata from the head request would be good...and as for the cache cleanup: the answer is yes and no...given that todays harddisks are big enough to cache more images than you would ever receive there should be an option to disable the automatic cache cleaning altogether, but there should be a cache cleaning mechanism for people with stricter space requirements/privacy concerns etc....this cleanup could be time based or space based (or - ideally - both)...
  102. tmolitor Link Mauve, arune: you could display some settings to whitelist jids for the automatic download if you don't want to automatically download files from all peaople in your roster...that whitelist could support full jids or only the server part of a jid to whitelist people...I think that would be ideal for people with privacy concerns...and all other people could select to not use the whitelist and download files from all contacts in their roster...but I would never include an option to activate automatic downloads for ALL contacts (even the ones NOT in your roster)...that would be something silly people could activate without knowing the consequences....
  103. tmolitor Link Mauve, arune: I think it depends, I personally would deactivate the cache cleanup because I would use the cache as file storage, too....so I can go into the cache directory and search for that image file some people send me some month ago (which possibly isn't on the http server anymore, so redownload is not always an option)...
  104. tmolitor the cache cleanup settings should be configurable in the plugin...
  105. tmolitor Link Mauve: I think this whitelist would be the ideal way to go :)
  106. tmolitor yes, right :)
  107. tmolitor arune: if you need some hands in implementing this proposal (given that you want to implement this), I could help you :)
  108. tmolitor Link Mauve: hmmm...yes, this would benefit from some caching mechanism also :)
  109. tmolitor I'm going to bed now, good night everybody...
  110. Link Mauve tmolitor, please fix your stuff.
  111. tmolitor Link Mauve, Asterix, arune: yes, using the metadata from the head request would be good...and as for the cache cleanup: the answer is yes and no...given that todays harddisks are big enough to cache more images than you would ever receive there should be an option to disable the automatic cache cleaning altogether, but there should be a cache cleaning mechanism for people with stricter space requirements/privacy concerns etc....this cleanup could be time based or space based (or - ideally - both)...
  112. tmolitor Link Mauve, arune: you could display some settings to whitelist jids for the automatic download if you don't want to automatically download files from all peaople in your roster...that whitelist could support full jids or only the server part of a jid to whitelist people...I think that would be ideal for people with privacy concerns...and all other people could select to not use the whitelist and download files from all contacts in their roster...but I would never include an option to activate automatic downloads for ALL contacts (even the ones NOT in your roster)...that would be something silly people could activate without knowing the consequences....
  113. tmolitor Link Mauve, arune: I think it depends, I personally would deactivate the cache cleanup because I would use the cache as file storage, too....so I can go into the cache directory and search for that image file some people send me some month ago (which possibly isn't on the http server anymore, so redownload is not always an option)...
  114. tmolitor the cache cleanup settings should be configurable in the plugin...
  115. tmolitor Link Mauve: I think this whitelist would be the ideal way to go :)
  116. tmolitor yes, right :)
  117. tmolitor arune: if you need some hands in implementing this proposal (given that you want to implement this), I could help you :)
  118. tmolitor Link Mauve: hmmm...yes, this would benefit from some caching mechanism also :)
  119. tmolitor I'm going to bed now, good night everybody...
  120. Link Mauve mathieui, please kick him or something. ^
  121. tmolitor Link Mauve, I did nothing!! that seems to be conversations or gajim or both in combination....I'll disable conversations for this account....I hope this will help...
  122. tmolitor big sorry to everybody!!!
  123. Link Mauve tmolitor, the kick would just have been to prevent you from flooding anymore, it was nothing against you. ^^
  124. tmolitor I know, but I disabled conversations now, and I hope this helps...
  125. tmolitor This error seems to occur every time conversation does reconnect...
  126. Link Mauve Which server are you using?
  127. tmolitor Link Mauve: datenknoten.me
  128. tmolitor Link Mauve: the server is running prosody...but I don't know which version exactly...
  129. Link Mauve It seems I can’t connect through mine, but anyway it would be interesting to see the logs.
  130. Link Mauve From the server end, especially.
  131. tmolitor Link Mauve: you can't connect to what exactly?
  132. tmolitor Link Mauve: yes, but I don't own the server :/
  133. Link Mauve To datenknoten.me
  134. Link Mauve Just ask you administrator to help you debug that then. :)
  135. tmolitor the website? or the xmpp server?
  136. Link Mauve The XMPP server.
  137. tmolitor you have to register an account using this webinterface: https://datenknoten.me/registrieren/
  138. Link Mauve I won’t.
  139. Link Mauve This is something your admin has to fix, probably.
  140. tmolitor Link Mauve yeah, that's ok, I told you only because you tried to connect to the server ;)
  141. tmolitor I don't really need this account on my mobile phone, so deactivating conversations for this account fixes the problem for me....
  142. Link Mauve But not for every other user of this server.
  143. Link Mauve Really, you should ping your admin about that.
  144. Link Mauve You can also redirect him here if you don’t want to handle that by yourself.
  145. tmolitor Link Mauve, it coult be an issue of conversations, too...or the cobination of both...
  146. tmolitor Link Mauve, wait a minute, I'll try to log the xmpp messages on the wire when reconnecting with conversations
  147. Link Mauve Good idea.
  148. tmolitor I hope I'll manage to man in the middle the connection :D
  149. Link Mauve Can’t you just use adb logcat?
  150. tmolitor no, conversations doesn't log enough info for that (for privacy reasons, I think)
  151. tmolitor there are only 4 or 5 lines in the logcat (connecting, connection established etc.)
  152. Link Mauve You should go ask their developers in conversations@conference.siacs.eu
  153. Link Mauve You should go ask their developers in xmpp:conversations@conference.siacs.eu?join
  154. tmolitor No need, It's not my first man in the middle for debugging stuff ;)
  155. tmolitor if it turns out to be a bug in conversations I'll contact the developer of course...
  156. bot RSS: Feeds for Gajim • Ticket #8126 (Gajim saves its config file once per second) created Bug description Gajim is causing a lot of disk activity as (apparently) it saves its config file once per second. strace -e file reports a stream like this: 1439933069.114526 open("/home/franks/.config/gajim/.config", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 21 1439933069.169093 stat("/home/franks/.config/gajim/config", {st_mode=S_IFREG|0600, st_size=25667, …}) = 0 1439933069.169279 rename("/home[…] https://trac.gajim.[…]