Re: Jami bug source investigation #4
Hi, I sent the patches to the mailing list. They should be soon available here: https://lists.gnu.org/archive/html/guix-patches/2020-07/msg00153.html Jan Wielkiewicz
Re: Jami bug source investigation #4
Nevermind, I've managed to write *I hope good commit messages*. Do not commit the fix yet, I will send all patches tomorrow. Jan Wielkiewcz
Re: Jami bug source investigation #4
Hi, On Sun, 05 Jul 2020 21:29:33 +0100 Christopher Baines wrote: > > So, I tried adding -DNDEBUG to the CFLAGS bit of the > #:configure-flags, and the package built. Testing it out seems to > work, I think I've experienced this issue with assertion failures, so > hopefully this will help. > > modified gnu/packages/jami.scm > @@ -141,7 +141,7 @@ > ;; against pjproject-jami: > ;; relocation R_X86_64_32S against `.rodata' can not > be used when ;; making a shared object; > - "CFLAGS=-fPIC" > + "CFLAGS=-fPIC -DNDEBUG" > "CXXFLAGS=-fPIC") > #:phases > (modify-phases %standard-phases > > Is there more to applying this fix, or will this change alone help? > I'm more than happy to review patches. > > Thanks, > > Chris That's it for the bug, if you want to have it fixed quickly, feel free to commit it. I didn't do it yet, because I'm busy writting commit messages for my refactored and updated package definitions. I'm also trying to catch up with the latest Jami version - they fixed some annoying stuff too. Is there a script for automatically writing commit messages compliant with the GNU coding standards? Jan Wielkiewicz
Re: Jami bug source investigation #4
Jan Wielkiewicz writes: > On Mon, 22 Jun 2020 09:32:50 +0200 > Pierre Neidhardt wrote: > >> Great! Does this fix any other issue? >> Does it warrant a package upgrade in Guix? >> > > This alone didn't fix the problem, but as no other possibility was left > than broken pjproject, I tried to fix it and succeeded. > It is mandatory to pass "-DNDBUG" flag to turn off assertion. > https://trac.pjsip.org/repos/wiki/FAQ#Performance > https://trac.pjsip.org/repos/wiki/FAQ#assert > > "Release mode. Don't forget to set the appropriate compiler > optimization flag, and disable assertion with -DNDEBUG." > > This surely fixes the bug the reason of I was chasing for several > months, where after disconnecting from audio call, the daemon > "crashed" (asserted). > It is also possible this fixes some other issues with SIP, I didn't > test, because I was uninterested. > > I'll prepare my messy code for committing once I have more time. > > I'm not sure whether I should fetch from git or use a tarball after > doing all this work. Fetching from git adds more complexity to the > packages, but it gives me more control over it plus I'm not sure if I > can trust the tarballs anymore, after two cases where some files/folders > were missing. > > Once I'll send the patches, would be cool if someone tested it. So, I tried adding -DNDEBUG to the CFLAGS bit of the #:configure-flags, and the package built. Testing it out seems to work, I think I've experienced this issue with assertion failures, so hopefully this will help. modified gnu/packages/jami.scm @@ -141,7 +141,7 @@ ;; against pjproject-jami: ;; relocation R_X86_64_32S against `.rodata' can not be used when ;; making a shared object; - "CFLAGS=-fPIC" + "CFLAGS=-fPIC -DNDEBUG" "CXXFLAGS=-fPIC") #:phases (modify-phases %standard-phases Is there more to applying this fix, or will this change alone help? I'm more than happy to review patches. Thanks, Chris signature.asc Description: PGP signature
Re: Jami bug source investigation #4
Jan Wielkiewicz writes: > I'm not sure whether I should fetch from git or use a tarball after > doing all this work. Fetching from git adds more complexity to the > packages, but it gives me more control over it plus I'm not sure if I > can trust the tarballs anymore, after two cases where some files/folders > were missing. Then it seems reasonable to fetch from Git. > Once I'll send the patches, would be cool if someone tested it. Will do, thanks again for your work! -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: Jami bug source investigation #4
On Mon, 22 Jun 2020 09:32:50 +0200 Pierre Neidhardt wrote: > Great! Does this fix any other issue? > Does it warrant a package upgrade in Guix? > This alone didn't fix the problem, but as no other possibility was left than broken pjproject, I tried to fix it and succeeded. It is mandatory to pass "-DNDBUG" flag to turn off assertion. https://trac.pjsip.org/repos/wiki/FAQ#Performance https://trac.pjsip.org/repos/wiki/FAQ#assert "Release mode. Don't forget to set the appropriate compiler optimization flag, and disable assertion with -DNDEBUG." This surely fixes the bug the reason of I was chasing for several months, where after disconnecting from audio call, the daemon "crashed" (asserted). It is also possible this fixes some other issues with SIP, I didn't test, because I was uninterested. I'll prepare my messy code for committing once I have more time. I'm not sure whether I should fetch from git or use a tarball after doing all this work. Fetching from git adds more complexity to the packages, but it gives me more control over it plus I'm not sure if I can trust the tarballs anymore, after two cases where some files/folders were missing. Once I'll send the patches, would be cool if someone tested it. Jan Wielkiewicz
Re: Jami bug source investigation #4
Nevermind, I resolved the issue. Jami built from git repository instead of from tarball didn't fix the bug with audio call. Jan Wielkiewicz
Re: Jami bug source investigation #4
Hello, it turns out there is a directory in libringclient package - include/libringclient/web-chatview and it contains the missing files, including the "web.gresource.xml" make and configure complain about. I need to copy the files from include/libringclient/web-chatview of libringclient package to source/web/ of jami package. How do I do this? I tried using modify-phases and just copying the files, but it fails in the same manner, while in the build directory obtained using "--keep-failed", there are only links to the files. Jan Wielkiewicz
Re: Jami: Bug source investigation
On Sun, 03 May 2020 17:26:33 +0200 Pierre Neidhardt wrote: > Jan writes: > > > Calls over WAN are always tricky, I had little luck with that even > > with the official Jami binary packages. With some friends > > everything works 100%, with other nothing works. I guess that's > > because of outdated proprietary router/modem firmware and hostility > > towards p2p. Try disabling firewall on your router (yeah I know, > > sounds bad). > > Sadly I can't do that on my friends routers :( > As long as this issue persists, this makes Jami not so useful as a > communication tool. > You can also set up/use existing TURN server. There was a blog post about it: https://jami.net/establishing-peer-to-peer-connections-with-jami/ Would be cool if someone added to Jami something like GNUnet or Tor support - using peers you can connect to as relays. Eventually you can buy your friends a better router with sane configuration for birthday or burn ISPs to the ground and create user controlled mesh network :) Jan Wielkiewicz
Re: Jami: Bug source investigation
On Sun, 03 May 2020 15:26:33 + Pierre Neidhardt wrote > Jan writes: > > > Calls over WAN are always tricky, I had little luck with that even with > > the official Jami binary packages. With some friends everything works > > 100%, with other nothing works. I guess that's because of outdated > > proprietary router/modem firmware and hostility towards p2p. > > Try disabling firewall on your router (yeah I know, sounds bad). > > Sadly I can't do that on my friends routers :( > As long as this issue persists, this makes Jami not so useful as a > communication tool. Sad :(
Re: Jami: Bug source investigation
Jan writes: > Calls over WAN are always tricky, I had little luck with that even with > the official Jami binary packages. With some friends everything works > 100%, with other nothing works. I guess that's because of outdated > proprietary router/modem firmware and hostility towards p2p. > Try disabling firewall on your router (yeah I know, sounds bad). Sadly I can't do that on my friends routers :( As long as this issue persists, this makes Jami not so useful as a communication tool. -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: Jami: Bug source investigation
On Sun, 03 May 2020 16:17:57 +0200 Pierre Neidhardt wrote: > Jan writes: > > > Placing a call works, disconnecting doesn't. > > Hmm, does not work for me. Have you tried non-locally, over a WAN? > Calls over WAN are always tricky, I had little luck with that even with the official Jami binary packages. With some friends everything works 100%, with other nothing works. I guess that's because of outdated proprietary router/modem firmware and hostility towards p2p. Try disabling firewall on your router (yeah I know, sounds bad). Jan Wielkiewicz
Re: Jami: Bug source investigation
Jan writes: > Placing a call works, disconnecting doesn't. Hmm, does not work for me. Have you tried non-locally, over a WAN? -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: Jami: Bug source investigation
On Sun, 03 May 2020 09:54:34 +0200 Pierre Neidhardt wrote: > I see the new Jami got merged yesterday, thanks a lot for your work, > Jan and Mathieu! > > I just tested it with another client on macOS: > > - I can chat, althought it's very slow and some messages don't arrive > sequentially. This greatly depends on your network setup. If there's NAT or firewall messages can get delayed. In my LAN, sending messages is instant. > - Placing and audio or video call loops for minutes, possibly > endlessly. The red "hang up" button does nothing. That's a known bug. I told Jami developers about recent update and they are going to test it. > Have you had success placing a call? > Placing a call works, disconnecting doesn't. Jan Wielkiewicz
Re: Jami: Bug source investigation
I see the new Jami got merged yesterday, thanks a lot for your work, Jan and Mathieu! I just tested it with another client on macOS: - I can chat, althought it's very slow and some messages don't arrive sequentially. - Placing and audio or video call loops for minutes, possibly endlessly. The red "hang up" button does nothing. Have you had success placing a call? -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: Jami: Bug source investigation
Okay, the patches are there. It should be available soon https://issues.guix.gnu.org/issue/40677 Jan Wielkiewicz
Re: Jami: Bug source investigation
On Thu, 16 Apr 2020 10:16:27 +0200 Pierre Neidhardt wrote: > Hi Jan, > > If I understand correctly, your updated package works better than the > one we've current got in Guix. Chat seems to work, sending recorded audio/video messages works, sending files works, audio/video calls work (ignoring the crash when disconnecting). Works better I guess, last time nothing was working. > What I suggest is that you send the patch set, we review and merge it, > then the Jami developers will be able to reproduce the bug easily by > simply installing Guix on their system. > What do you think? > Seems to be a good idea. The question is if Jami developers will have time to help us, they're not volunteers, but are employed by Savoir-Faire Linux after all. I'll prepare the patches later today, or you can just clone it from here: https://gitlab.com/kromka_chleba/jami-package-and-other-things-for-guix.git My work is on the wip-jami branch. Jan Wielkiewicz
Re: Jami: Bug source investigation
On Wed, 15 Apr 2020 20:31:01 +0200 Marius Bakke wrote: > It looks like this problem was fixed a while back: > > https://trac.pjsip.org/repos/ticket/2240 > https://github.com/pjsip/pjproject/commit/d5a9caf6aac077c157fa6b20c770385c2355973d > > Have you tried updating pjproject to 2.10? Yes, of course. It seems all pjproject errors look like this :P Is there a way to use configure flags from rules.mak file provided by Jami? Currently I use "#:configure-flags" form, but I have to be sure I didn't miss anything important from the file. Jan Wielkiewicz
Re: Jami: Bug source investigation
Jan writes: > Hello, > > so I tested Jami on core-updates and it didn't fix the bug > (https://git.jami.net/savoirfairelinux/jami-packaging/issues/63) > > Here's my work up to now, it is on wip-jami branch: > https://gitlab.com/kromka_chleba/jami-package-and-other-things-for-guix/-/tree/wip-jami > https://gitlab.com/kromka_chleba/jami-package-and-other-things-for-guix.git > > What happens is when making an audio call and then pressing the red > "disconnect" button, Jami daemon (dring) stops with the following > message: > > dring: ../src/pjsip-ua/sip_inv.c:246: pjsip_inv_dec_ref: Assertion `inv > && inv->ref_cnt' failed. It looks like this problem was fixed a while back: https://trac.pjsip.org/repos/ticket/2240 https://github.com/pjsip/pjproject/commit/d5a9caf6aac077c157fa6b20c770385c2355973d Have you tried updating pjproject to 2.10? signature.asc Description: PGP signature
Re: Jami: Bug source investigation (help needed)
I tried some more things: - building everything with gcc-8 (version Debian 10 uses, where Jami works) - using dependency tarballs from pjproject source instead of Guix packages, you can see this mess on my gitlab repo on wip-pjproject-fix branch https://gitlab.com/kromka_chleba/jami-package-and-other-things-for-guix As I said before, I'm out of ideas how to fix the problem. Jan Wielkiewicz
Jami: Bug source investigation
Hello, so I tested Jami on core-updates and it didn't fix the bug (https://git.jami.net/savoirfairelinux/jami-packaging/issues/63) Here's my work up to now, it is on wip-jami branch: https://gitlab.com/kromka_chleba/jami-package-and-other-things-for-guix/-/tree/wip-jami https://gitlab.com/kromka_chleba/jami-package-and-other-things-for-guix.git What happens is when making an audio call and then pressing the red "disconnect" button, Jami daemon (dring) stops with the following message: dring: ../src/pjsip-ua/sip_inv.c:246: pjsip_inv_dec_ref: Assertion `inv && inv->ref_cnt' failed. This issue is related to pjproject (https://www.pjsip.org/) - the library implementing SIP, and patches Jami developers apply to it, which can be found in ring-project/daemon/contrib/src/pjproject/. I need help of someone experienced to investigate what is the difference that makes our package crash, that doesn't occur on other distributions. If we find out, we will hand it to Jami developers so they can fix it. Running daemon in the debugging mode: /lib/ring/dring -pcd Jami is built on debian 10, fedora 31, ubuntu 19.10 using GCC with scripts written in python and bash located in ring-project/make-ring.py and ring-project/scripts. The source packages are available here: https://dl.jami.net/release/tarballs/ And the binaries that don't suffer from the bug are here: https://dl.jami.net/nightly/ Jan Wielkiewicz
