Gajim - 2019-12-22


  1. nichts is there an option to show the certificate information of a connection? Like this little lock-sign in a browser left to the address line
  2. Link Mauve nichts, in the roster, on the line with your account, you should see a lock sign. Right-click on it, select View Server Info, in the new window there is a Connection tab which has this information.
  3. Link Mauve Where would you expect to find this information?
  4. nichts this is, where I would expect it to find. But it is not there
  5. Link Mauve What do you get instead?
  6. nichts the menu which I get when I right click somewhere else on this line.
  7. Link Mauve It’s actually the same menu.
  8. Link Mauve You don’t have a View Server Info there?
  9. nichts have german localization, but nothing close to „server information“.
  10. Link Mauve lovetox, I got this error when starting Gajim: https://conference.gajim.org:5281/pastebin/c8f40d33-4fce-4a76-9558-ca360ec75bd9
  11. Link Mauve Am I doing anything wrong?
  12. Link Mauve Multiple times.
  13. Link Mauve nichts, hmm, maybe it’s only in master then, which version are you running?
  14. lovetox Link Mauve, cert info is only in master
  15. Link Mauve Ah, that’d be why.
  16. Link Mauve Sorry.
  17. lovetox Link Mauve, update gajim
  18. lovetox this is not in the current codebase
  19. nichts so I should build from the git in order to get this?
  20. lovetox depends what operationg system do you use nichts?
  21. lovetox depends what operating system do you use nichts?
  22. nichts Linux, Arch – which is known not to have the most outdated versions :)
  23. lovetox i think there is even a package that always uses the latest git
  24. lovetox what was that again Link Mauve ?
  25. nichts maybe in AUR. Will check this, thanks
  26. lovetox https://aur.archlinux.org/packages/gajim-git/
  27. lovetox Link Mauve, why is gtk not listed as dependency?
  28. Link Mauve Good question, it should!
  29. lovetox and also we have now a new dependency
  30. lovetox libsoup
  31. Link Mauve lovetox, there fixed, thanks for the notice.
  32. lovetox great thanks
  33. Link Mauve You should do something for the tags btw.
  34. Link Mauve Or say you aren’t using them anymore and we can switch to another versioning scheme.
  35. lovetox hm why? we use them for releases
  36. lovetox are suggesting to also use them everytime we incremement in a dev cycle?
  37. Link Mauve Yeah.
  38. lovetox hm yeah i can do this, but how does that help you?
  39. lovetox the tag points to one commit, and on the next day i make a new one
  40. lovetox for your gajim-git package you always want latest git
  41. lovetox or is it just so that the version matches
  42. lovetox gajim-git 1.0.0.beta1.r1944.g9497dce25-1
  43. Link Mauve Many people reported that saying 1.0.0-beta1-number-of-commits-since-beta1 doesn’t help, as it feels older than current master.
  44. lovetox yeah that version seems wrong on all levels
  45. Link Mauve It’s using that one because it’s the latest tag you’ve put on master.
  46. lovetox ok but cant you just make it so that it uses no tag?
  47. Link Mauve I can do that.
  48. lovetox i can also add tags from now on, just want to have the best solution
  49. Link Mauve r17041.9497dce25 is better?
  50. lovetox not really
  51. lovetox why does it need to have a hash in it?
  52. lovetox why cant it just read, gajim-dev
  53. lovetox or gajim-git
  54. lovetox ah you need a version so people get update notifications?
  55. Link Mauve I can choose not to include the git commit, but then you have no way to know which actual commit it refers to.
  56. lovetox but how would people now know?
  57. lovetox the commit does not update everyday or?
  58. Link Mauve And it needs a version that is monotonely increasing to compare it, yes.
  59. Link Mauve So how it works is, someone runs makepkg, it pulls from the repository, generates this version number, then if it’s higher than the current installed one it builds and installs Gajim.
  60. lovetox k then lets do it like that r17041.9497dce25
  61. Link Mauve Ok.
  62. Link Mauve There, changed.
  63. Link Mauve https://aur.archlinux.org/cgit/aur.git/commit/?h=gajim-git&id=e66226d99aa8689e63b557b9c83d6dfe5686c0b6
  64. Link Mauve Ah hmm, an issue is with plugins, for instance xorg-server-git/src/build
  65. Link Mauve Ah hmm, an issue is with plugins, for instance https://aur.archlinux.org/packages/gajim-plugin-omemo/
  66. Link Mauve They currently require a specific Gajim version, which is now completely opaque.
  67. Link Mauve Oh, are you aware of this fork? https://gitlab.com/a/gajimbo
  68. Link Mauve Hmm, doesn’t seem very active.
  69. Link Mauve Meh, useless.
  70. Link Mauve Why is it even in AUR?
  71. lovetox Link Mauve,
  72. lovetox plugin packages from AUR should depend on the git package
  73. lovetox and no plugins are linked to major gajim versions
  74. lovetox thats why we have a gajim1.1 plugin branch
  75. lovetox and a master plugin branch
  76. lovetox so all plugins from master will always work with master
  77. Link Mauve Ok, so all plugins should stop hardcoding the version they depend on, since starting one hour ago that won’t work anymore.
  78. lovetox and we dont test for minor versions
  79. lovetox Link Mauve, you mean the plugin packages in AUR?
  80. lovetox because plugins depend on a gajim version, but this works regardless of if you put a version in the package or not
  81. lovetox only because your git package does not have a version, does not mean gajim does not have a version
  82. Link Mauve Yes.
  83. lovetox yeah you mean the AUR plugin packages
  84. lovetox yes they should not depend on a version