Gajim - 2017-01-27


  1. lovetox_ i have 40% finished GMenu for Gajim here https://dev.gajim.org/lovetox/gajim/commits/appmenu
  2. lovetox_ Link Mauve if you are interested
  3. aszlig good morning
  4. aszlig According to the comment "Unit tests tests will be run on each commit." in test/runtests.py it seems that you run some kind of CI system that continuously runs tests.
  5. aszlig Are the logs/results public somewhere?
  6. aszlig Also, did you run tests prior to releasing 0.16.6? Because unless I have missed something this seems highly unlikely:
  7. aszlig Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/tmp/nix-build-gajim-0.16.6.drv-0/gajim-gajim-0.16.6-f4ec0c003c11c5a1d94bd8f7bcfbc7025039d4a3/test/unit/test_protocol_caps.py", line 13, in <module> from common.connection_handlers import ConnectionHandlers File "/tmp/nix-build-gajim-0.16.6.drv-0/gajim-gajim-0.16.6-f4ec0c003c11c5a1d94bd8f7bcfbc7025039d4a3/test/lib/../../src/common/connection_handlers.py", line 80, in <module> from common.jingle import ConnectionJingle File "/tmp/nix-build-gajim-0.16.6.drv-0/gajim-gajim-0.16.6-f4ec0c003c11c5a1d94bd8f7bcfbc7025039d4a3/test/lib/../../src/common/jingle.py", line 35, in <module> from jingle_session import JingleSession, JingleStates File "/tmp/nix-build-gajim-0.16.6.drv-0/gajim-gajim-0.16.6-f4ec0c003c11c5a1d94bd8f7bcfbc7025039d4a3/test/lib/../../src/common/jingle_session.py", line 41, in <module> from jingle_ft import STATE_TRANSPORT_REPLACE File "/tmp/nix-build-gajim-0.16.6.drv-0/gajim-gajim-0.16.6-f4ec0c003c11c5a1d94bd8f7bcfbc7025039d4a3/test/lib/../../src/common/jingle_ft.py", line 28, in <module> from common.jingle_ftstates import StateCandReceived, JingleTransportSocks5, \ ImportError: cannot import name JingleTransportSocks5
  8. aszlig In the current master version this seems to be fixed already, because jingle_ftstates.py imports all attributes from the jingle_transport module, while in 0.16.6 it only imports "TransportType" and thus "JingleTransportSocks5" cannot be re-imported from jingle_ft.
  9. aszlig Btw. I'm not able to fork the gajim repository, how am I supposed to submit merge requests?
  10. aszlig I could use a Git repos hosted elsewhere but I haven't found a way to submit a merge request with an external repos.
  11. aszlig So if I'm trying to fork I'm getting the error message "Limit reached Personal project creation is not allowed. Please contact your administrator with questions"
  12. mrDoctorWho git help request-pull
  13. aszlig mrDoctorWho: that won't work with gitlab
  14. mrDoctorWho why?
  15. aszlig mrDoctorWho: because first of all, i need to still push it to a self-hosted repository and second, this is if i want to format the pull request message for example if i'll email that to a mailing list
  16. mrDoctorWho talking about mailing lists, you could have submit a patch
  17. aszlig mrDoctorWho: why do you have gitlab then? O_o
  18. aszlig i mean, for ml-based development, cgit should be more than enough... people can send in their patches using format-patch/send-email and do PRs via request-pull.
  19. mrDoctorWho for issues, for wiki, for the project overview, for the diffs and so on. Although I'd prefer gogs which is much easier to install and easier on resources
  20. aszlig well, anyway, there _are_ merge requests already, so i suppose that error i'm getting is probably because of the transition from trac i assume
  21. aszlig mrDoctorWho: mhm, i also find gogs way better in terms of the ui
  22. mrDoctorWho agreed
  23. mrDoctorWho and it looks more like github
  24. aszlig mrDoctorWho: which is probably why i prefer it being used to work with GH on an everyday basis
  25. aszlig but anyway, need to head to sleep, it's 05:50 AM here...
  26. mrDoctorWho have nice dreams
  27. aszlig thanks and c'ya later
  28. lovetox aszlig, you cant fork because you logged in with github account
  29. lovetox for these people the admin has to explicitly allow forking
  30. lovetox i will do this when im home in the evening
  31. lovetox PR are very welcome
  32. Link Mauve lovetox, is there a way to allow any user to clone a repository there?
  33. lovetox you mixing up cloneing and forking
  34. lovetox everybody can clone, even not registered people
  35. Link Mauve What you call forking is just a clone on the same machine.
  36. lovetox no there is not, external users cant fork
  37. lovetox atleast in the current gitlab version
  38. lovetox rights management is not very big in gitlab
  39. Link Mauve It sounds to me like the ACL are misconfigured.
  40. lovetox no it is not google it
  41. Link Mauve I don’t use google. :p
  42. lovetox you would thin gitlab implements a rights management for all the different user roles, but it does not have one
  43. lovetox there are 5 fixed user rolls, you cant modify even one access right
  44. lovetox though i saw issues are open about it, obviously many companys wish for better rights management
  45. lovetox also it kind of makes sense to ristrict external users
  46. lovetox because you have no control over the registration process on an external platform
  47. lovetox you dont want to grant them automatically to clone repos on your server
  48. Link Mauve It isn’t harder or easier than for local users, tbh.
  49. lovetox it is because we control the registration process
  50. Link Mauve How do you control it?
  51. Link Mauve My server has IBR enabled, I know I can delete accounts that look spammy, but some will always go through any such mechanism.
  52. lovetox i can use various anti spam technologys or even set the registration to only allow registration after a admin did a manual inspection of the registration wish
  53. lovetox im talking hypotetical here, why such a feature can make sense, in our case and github it does not make much
  54. lovetox but someone who uses gitlab maybe doesnt have such a easy registration barrier as github
  55. lovetox so it would make not much sense to grant github users the same rights as his own users
  56. linus FWIW I recently had quite a bit of difficulty getting some new github accounts included in an organisation, because the (newly registered) accounts were blocked by github
  57. linus so they seem to err on the side of caution
  58. linus Plus you don't exactly see many viagra adverts on github issues and such, so I think they've got spam control sussed out pretty well
  59. lovetox__ aszlig, you are now upgraded
  60. allo hi
  61. allo I have a feature request. Sadly the gitlab rejected it as spam, so please have a look (and possibly add it to the bugtracker) here: https://pastebin.ca/3760979
  62. lovetox__ hi allo,
  63. lovetox__ this is already implemented
  64. lovetox__ altough not very obvious
  65. allo I did not find the option in the debian stretch version
  66. lovetox__ go to preference
  67. lovetox__ advanced
  68. lovetox__ then open the advanced config editor
  69. lovetox__ there set restore_lines to whatever you like
  70. lovetox__ and restore_timeout to like 10000
  71. lovetox__ also there is no thing like unread MAM messages
  72. allo Ah, thank you this works fine!
  73. lovetox__ if someone sends you a message while you are offline, and you start gajim you will see the message symbol on the contact
  74. allo Yeah, i was just missing the context lines in the chat window.
  75. aszlig lovetox__: thanks :-)
  76. lovetox__ aszlig
  77. lovetox__ the problem you described
  78. lovetox__ is already fixed in both branches
  79. aszlig lovetox__: ah, so it's going to be fixed in 0.16.7, right?
  80. lovetox__ https://dev.gajim.org/gajim/gajim/commit/491d32a2ec13ed3a482e151e0b403eda7b4151b8
  81. lovetox__ yes
  82. lovetox__ or you use nightly
  83. aszlig lovetox__: well, i'm maintaining gajim for nixos, so i'm targeting the latest upstream stable
  84. lovetox__ ah ok :)
  85. lovetox__ yeah i hope we do the release in the next days
  86. aszlig so do you have a public CI where one can inspect test logs?
  87. lovetox__ it ready
  88. lovetox__ no sadly not :)
  89. aszlig i could provide one, but that would be running on nixos
  90. lovetox__ we could have, but asterix didnt have time until now to do it with gitlab
  91. lovetox__ i dont think that is necessary, either we swtich to gitlab ci or let it like it is
  92. aszlig this for example would be the test run from 0.16.6: https://headcounter.org/hydra/log/i0s6b6n3rzk6pzlsf2l73f9zbn2smycw-gajim-0.16.6.drv
  93. aszlig i've skipped the test_receive_1nocontrol and test_receive_2already_has_control session tests, because they seem to have wrong mocks
  94. aszlig lovetox__: i think it's necessary if you want to avoid regressing too much
  95. aszlig also it would help downstream distributors to verify if it's working correctly
  96. aszlig for example the commit you posted about JingleTransportSocks5 is something that is an upstream issue
  97. aszlig and as a downstream maintainer the best way to assure that things work correctly is comparing your test results with those of the upstream project
  98. lovetox__ its not a problem to put the logs online form the builds if thats what you want
  99. lovetox__ im not in charge of the linux release, i will tell asterix to look at the tests and maybe we can have a more transparent build process
  100. bot Philipp Hörist pushed 2 commits to branch _refs/heads/gajim_0.16_ of _gajim_ <https://dev.gajim.org/gajim/gajim>: *46a19733* <https://dev.gajim.org/gajim/gajim/commit/46a19733d208fbd2404cbaeedd8c203d0b6557a4> tests: Don't mock received_message_hashes This fixes the following two test cases from TestChatControlSession in test/unit/test_sessions.py: * test_receive_1nocontrol * test_receive_2already_has_control The MockConnection object already defines various attributes from the real Connection object to their corresponding types so that calling code is able to for example iterate on dicts or lists. Since 40a3f80aa1afc0cde885d23da28e5c2330f3583c, there exists a new received_message_hashes attribute, which is expected to be a list but the default Mock object doesn't define an __iter__ method. So this leads to the following exception: Traceback (most recent call last): File ".../share/gajim/src/common/ged.py", line 93, in raise_event if handler(*args, **kwargs): File ".../share/gajim/src/common/connection_handlers.py", line 1137, in _nec_message_received conn=self, msg_obj=obj)) File ".../share/gajim/src/common/nec.py", line 74, in push_incoming_event if event_object.generate(): File ".../share/gajim/src/common/connection_handlers_events.py", line 1468, in generate if self.msghash in self.conn.received_message_hashes: TypeError: argument of type 'instance' is not iterable Defining received_message_hashes to be a list fixes this. Signed-off-by: aszlig <aszlig@redmoonstudios.org> *ab3b363e* <https://dev.gajim.org/gajim/gajim/commit/ab3b363ec473bf6a4aecb9749d4532e6129ef3f7> Merge branch 'fix-connection-mock' into 'gajim_0.16' tests: Don't mock received_message_hashes See merge request !47