Gajim - 2016-08-12

  1. Johannes So this PR has been submitted to my GitHub Gajim mirrors. It has a proper issue from the Gajim bugtracker attached.
  2. Johannes Can somebody please have a look at the PR an tell me if I should merge it?
  3. Johannes @kalkin can you possibly have a look at that
  4. lovetox Johannes, that was me
  5. lovetox probably someone familiar with nbxmpp should review it, maybe even asterix
  6. Johannes lovetox: good, now all relevant people should be highlighted :)
  7. Johannes Just thought someone other than the author should review the code
  8. kalkin Johannes: ok
  9. kalkin Johannes: it might be better if i have a look at the mirroring script you are using
  10. kalkin the repo looks fine
  11. Johannes Good, then I'll merge it. However I'll have to make up some way to be able to merge things and still decently mirror the hg repo
  12. kalkin Johannes, " wait
  13. kalkin Johannes: I misunderstood you
  14. kalkin I will have a look at the PR
  15. kalkin The PR looks good to me
  16. lovetox maybe asterix could do a new version of nbxmpp
  17. lovetox there are rather important fixes in it
  18. lovetox the SLL error bug, and the smacks bug sending messages multiple times
  19. Johannes lovetox, if you want you could bring up multiple PRs for that, after all you can export them as patch sets, so they will not get lost and at least are then present somewhere
  20. lovetox no i meant, they are all fixed
  21. lovetox in the latest commits
  22. lovetox but they were never released in a new verison
  23. Johannes ah, I see. that would then rather end up in the CI business
  24. Johannes I've seen a lot of people on arch linux just running of the hg tip
  25. Johannes Arch Linux has scripts for it. And at least for OSX I actually do the same
  26. Johannes it isn't pretty or comfortable but after all it's a modern xmpp client...
  27. kalkin Johannes: Did you receive my answer?
  28. lovetox of course you could run nightlys but this should not be the recommended way :)
  29. kalkin answered encrypted via OMEMO.
  30. kalkin Dunno if you don't have an OMEMO enabled device with you
  31. kalkin Johannes: also it might be better to have this discussion here publicly
  32. Johannes that did not seem to have worked...
  33. Johannes your jid is also not marked as omemo capable here
  34. Johannes as in your plugin does not see keys of you and conversations does neithre
  35. kalkin I'm online only with gajim currently. But you are offline here
  36. kalkin Nevermind, let us have the discussion here
  37. kalkin I'm not sure what your push agreement (@Johannes) with Asterix is. I mean even if we (the github maintainers) review PRs and even if some one could push it to official hg. I can imagine that Asterix would be not very happy with _all_ the commits
  38. Johannes there is not. I mirror it with acceptance from asterix. I guess he didn't think that there would be any PRs ever via that way, so there is no agreement on that part
  39. kalkin Also I don't think that Asterix would be happy to participate in discussions and reviews at Github, because this will be a second place where the information is stored, and this will confuse every one
  40. Johannes thus, it might end up as patchsets via email/trac. but it would be nicer if it would not
  41. Johannes thus, sync would be nice.
  42. kalkin I don't think syncing issues and PRs is a good idea. First of all it will be PIA, because trac and github data systems vary wildly and second it will still be confusing to new users that there're two places for gajim
  43. kalkin It's already confusing that there are two tracs for one gajim and one for plugins
  44. Johannes Indeed it is. However I guess they will stay the way they are. Nevertheless it would nice if one could accept and take in participation via GitHub.
  45. Johannes another possible way could also be to equip the tracs with OAuth for GitHub
  46. kalkin Johannes: Do what you think is best for you, but don't be surprised if you end up with maintaining a fork.
  47. kalkin Johannes: I think the best at Github is it's interface and not really the authentication. Trac is just very weird and ugly
  48. Johannes and it requires an additional account. and potential knowledge in mercurial which is nice an basically git but just not as popular as git
  49. Johannes kalkin: you mean Psi+ style as in Gajim++? xD
  50. kalkin :). Actually I imagine that maintaining a patchset like Psi+ does, is much harder, because you actually have to be compatible.
  51. lovetox so what for is the github repo?
  52. lovetox issue tracking?
  53. lovetox what was the idea
  54. Holger "I guess he didn't think that there would be any PRs ever via that way" - I'm not sure that's quite correct :-)
  55. Holger <Asterix> That's why I hate ppl do clone on github. It's not maintained and confuse users. I really hate that
  56. kalkin Also relevant:
  57. kalkin I mean if the reason for using Github is to have more people to participate, you might achieve it some other way.
  58. Johannes lovetox: I guess in that case you better take your patch to asterix or the trac or wherever and see what happens...
  59. kalkin Github puts source code very prominently at the first page. I can look into it and see if I'm even capable of fixing an issue. Also it gives you a quick look at issues & PRs to see if there some one already working on some feature or what the general development direction the project goes.
  60. kalkin If i click at View Tickets in trac. I don't see any tieckts I see some project managment page
  61. kalkin I don't want to figure out which are the Tickets I want to see, I just want to see all the open issues sorted by last activity date
  62. kalkin I know this is possible in trac, but this should be possible with one click (at least for unregistered users)
  63. kalkin The Source Code should probably be shown on, or the link should be more prominent. Also it might be nice to have a Big Button Issues, which links to some useful track ticket search query
  64. kalkin The source code should probably be shown on, or the link should be more prominent. Also it might be nice to have a Big Button Issues, which links to some useful track ticket search query
  65. kalkin The source code should probably be shown on, or the link to it should be more prominent. Also it might be nice to have a Big Button Issues, which links to some useful track ticket search query
  66. kalkin I like when projects have a Github Link. Because visiting a github link, always yields good results. I know that i can get some overall view of a project very fast
  67. mathieui I disagree
  68. mathieui I often see projects with github links as the main landing and no obvious way to look at the documentation or anything
  69. Holger Docuwhat?
  70. kalkin mathieui: I mean if you have as a project a proper website and a link to github. If the github wiki is empty and the project website didn't had a link Documentation, than you know this project is probably crap
  71. vorner What is the reason to have distributed VCS and then put everything into the hands of single company anyway?
  72. kalkin And by “visiting a github link, always yields good results” I mean that you know if the project is crap or serious
  73. kalkin vorner: No one is saying we should use Github. I'm just trying to say: instead having a mirror on Github for attracting developers, we might just get by doing some usability changes, to achieve the same what Github UI provides
  74. johannes vorner: well, currently all authoritative gajim repos are in a single place as well....
  75. vorner johannes: Yes, they are. But if that machine/company dies/has network problems, it doesn't affect 99% projects on the Internet.
  76. kalkin actually if we are talking about beeing really distributed, then we need a P2P network, where you can provide your source code and also find any forks of it. (In some ideal world)
  77. mathieui if that company dies, 90% of the world CI and deployment scripts break
  78. johannes The good point with DVCS is that you can actually have multiple synced mirrors...
  79. kalkin this ↑
  80. kalkin How is the gajim website maintained? Is there some source repo for that, or is it just part of the trac wiki just with other CSS?
  81. johannes Also, if no one sees or uses the stuff, all mirrors and whatever are irrelevant. And if it is not conveniently seen or amended, you may lose contribution and thus advancement of the entire thing. And thus to give the nuclear result: The entire thing may fade into oblivion...
  82. johannes However enough of the populism... ;)
  83. de-facto how come all "/me" messages letters always seem to show as empty squares in gajim? is this some kind of font problem on my system or a bug in gajim?
  84. de-facto wonders if its like that on other systems too
  85. de-facto like this ^^
  86. de-facto they show as squares in gajim window, but i can copy and paste them correctly (e.g. copy the "squares" and paste them in a text editor, then it shows the correct letters)
  87. de-facto any ideas what could cause that?
  88. de-facto i am using Gajim 0.16.5-06207bfa2cd8 on ubuntu 16.04 xenial amd64
  89. arune kalkin johannes: I think gajim needs more maintainers of the infrastructure, there are people willing to help with trac etc
  90. johannes That's actually something that is nice with GitHub, Travis and the likes: there is little to no maintenance along with, in case of an open source application, little to no costs. And if one acts wisely, there are little to no lock-in effects or migration costs in case one of the options goes away...
  91. Link Mauve johannes, erm, you should have seen the amount of time some Citra people have put into appveyor and other crap CI systems, just because there is no way to test them easily…
  92. johannes I guess proper maintenance of a Jenkins instance takes quite some time as well...
  93. kalkin Interesting bug. I'm chatting in a private tab opened from some muc with Link Mauve via Gajim. If i send from Conversations a message to this conversation, the Conversations messages arrive in Gajim, as if they were send from Link Mauve.
  94. Link Mauve Probably a MSN failure in Gajim.
  95. Link Mauve An XML dump would be useful.
  96. kalkin is working on that
  97. kalkin <!-- Out Fri 12 Aug 2016 08:42:21 PM CEST --> <message xmlns="jabber:client" to=" Mauve" type="chat" id="a7dc72e5-bc33-49d7-9eb0-526e1aac8598"> <active xmlns="" /> <thread>ptiVpvRFnuSXfjDychGFXqUDHuOYKnZx</thread> </message> <!-- Out Fri 12 Aug 2016 08:42:21 PM CEST --> <a xmlns="urn:xmpp:sm:2" h="548" /> <!-- In Fri 12 Aug 2016 08:42:21 PM CEST --> <message to='' from=' Mauve' id='d3baad5b-46f1-483a-9603-7694738ccd94-8795E' xml:lang='fr'> <received id='f6ccc3a4-d28a-4ae1-8188-d347b10f3e08' xmlns='urn:xmpp:receipts'/> </message> <r xmlns='urn:xmpp:sm:2'/> <!-- Out Fri 12 Aug 2016 08:42:21 PM CEST --> <a xmlns="urn:xmpp:sm:2" h="549" />
  98. Link Mauve That doesn’t include the message.
  99. kalkin <!-- In Fri 12 Aug 2016 08:45:03 PM CEST --> <message type='chat' to='' from=''> <sent xmlns='urn:xmpp:carbons:2'> <forwarded xmlns='urn:xmpp:forward:0'> <message type='chat' to=' Mauve' from='' id='a7d8d851-1fb2-4976-8b4b-2ba4245a26a4' xmlns='jabber:client'> <body>One More time</body> <request xmlns='urn:xmpp:receipts'/> </message> </forwarded> </sent> </message> <r xmlns='urn:xmpp:sm:2'/> <!-- In Fri 12 Aug 2016 08:45:03 PM CEST --> <message to='' from=' Mauve' id='d3baad5b-46f1-483a-9603-7694738ccd94-87973' xml:lang='fr'> <received id='a7d8d851-1fb2-4976-8b4b-2ba4245a26a4' xmlns='urn:xmpp:receipts'/> </message> <r xmlns='urn:xmpp:sm:2'/>
  100. Link Mauve Err, private MUC messages shouldn’t get carboned…
  101. Link Mauve Ah right, it’s currently a Prosody extension to 280, maybe you should ask Ejabberd people to implement it too, and ask Prosody people to publish the newer revision of the XEP.
  102. arune johannes: github might be less work yes, but now gajim team / asterix don't want the project that way so either we follow how he wants it or we fork. We can't have both github and trac, that's even worse
  103. Holger Link Mauve: The <x/> tag to mark MUC PMs is non-standard, so it's not a simple update to 0280.
  104. Holger ejabberd adds that tag as well though.
  105. Holger And yes I was thinking about suppressing carbons for incoming MUC PMs. You usually don't want them, except when you want them.
  106. Holger But either way that won't help with outgoing PMs (unless the client tags them as such), which is what kalkin was seeing, no? And isn't he using Prosody?
  107. kalkin yes I'm using prosody beta something
  108. kalkin I could update it so and try again
  109. Holger And you were seeing an outgoing PM of your in another client, right?
  110. kalkin Right, but it was shown as beeing send not by me, but my partner
  111. Holger Yes, so that would be a Gajim issue indeed.
  112. Holger Or an XMPP issue. MUC PMs just don't play well with Carbons.
  113. kalkin Holger: inputmice said the same. He did know that the bug exists
  114. kalkin (Gajim issue)
  115. kalkin Hmm I just noticed that the copr mirror I was using isn't up to date anymore *sigh*
  116. kalkin Holger: is using ejaberrd right?
  117. Holger kalkin: Yup.
  118. kalkin Holger: build from source or do you use OS packages? If OS, what kind of os are using?
  119. Holger Personally I build from source because I apply patches and want to be able hot-upgrade the code and whatnot. But we're using Debian stable and the jessie-backports package is up-to-date and well-maintained.
  120. Link Mauve Holger, to 45?
  121. Holger Link Mauve: I mean you'd need to update both 0045 and 0280.
  122. kalkin Holger: I see thanks for the info.
  123. Link Mauve Yeah.
  124. Holger And to me the desired behavior isn't completely obvious.