How can I fix this package for watchman?

[Josh Marshall]

I've been trying to package Facebook's watchman, but I keep running into a
number of problems, none of which have been obvious to fix.  Can someone
point out what I'm missing?
diff --git a/gnu/packages/storage.scm b/gnu/packages/storage.scm
index 376a801fe2..84b482088e 100644
--- a/gnu/packages/storage.scm
+++ b/gnu/packages/storage.scm
@@ -19,16 +19,23 @@
 
 (define-module (gnu packages storage)
   #:use-module (guix download)
+  #:use-module (guix git-download)
   #:use-module ((guix licenses) #:prefix license:)
   #:use-module (guix packages)
   #:use-module (guix utils)
+  #:use-module (guix build utils)
+  #:use-module (guix build gnu-build-system)
   #:use-module (guix build-system cmake)
+  #:use-module (guix build-system gnu)
   #:use-module (gnu packages)
   #:use-module (gnu packages admin)
   #:use-module (gnu packages assembly)
   #:use-module (gnu packages authentication)
+  #:use-module (gnu packages autotools)
+  #:use-module (gnu packages base)
   #:use-module (gnu packages bdw-gc)
   #:use-module (gnu packages boost)
+  #:use-module (gnu packages commencement)
   #:use-module (gnu packages compression)
   #:use-module (gnu packages crypto)
   #:use-module (gnu packages cryptsetup)
@@ -247,3 +254,43 @@ storage protocols (S3, NFS, and others) through the RADOS gateway.")
license:cc-by-sa3.0   ;documentation
license:bsd-3 ;isa-l,jerasure,++
license:expat ;civetweb,java bindings
+
+(define-public watchman
+  (package
+(name "watchman")
+(version "4.9.0")
+(source (origin
+  (method git-fetch)
+  (uri (git-reference
+  (url "https://github.com/facebook/watchman.git;)
+  (commit "8e0ba724d85de2c89f48161807e878667b9ed089")))
+  (sha256
+   (base32
+"0fdaj5pmicm6j17d5q7px800m5rmam1a400x3hv1iiifnmhgnkal"
+(build-system gnu-build-system)
+(arguments
+  (modify-phases %standard-phases
+(add-after 'build 'add-python-to-path
+  (lambda* (#:key inputs #:allow-other-keys)
+( setenv "PATH" (string-append (assoc-ref inputs "python") "/bin"))
+(inputs
+  `(("python" ,python)
+("coreutils" ,coreutils)
+("glibc" ,glibc)))
+(native-inputs
+  `(("automake" ,automake)
+("autoconf" ,autoconf)
+("coreutils" ,coreutils)
+("gcc-toolchain" ,gcc-toolchain)
+("glibc" ,glibc)
+("libtool" ,libtool)
+("pkg-config" ,pkg-config)
+("openssl" ,openssl)
+("python" ,python)))
+(propagated-inputs
+  `(("python" ,python)))
+(synopsis "Watches files and records, or triggers actions, when they change")
+(description "Watchman exists to watch files and record when they actually change.
+It can also trigger actions (such as rebuilding assets) when matching files change.")
+(license license:asl2.0)
+(home-page "https://facebook.github.io/watchman/;)))

Re: OpenJFX 14, gradle

[Julien Lepiller]

Le 3 mai 2020 22:00:24 GMT-04:00, Michael Zucchi  a écrit :
>
>Morning,
>
>I'm trying to work on updating some java stuff as guix currently only 
>has java12 which is  a year out of date and javafx8 which is ancient.  
>Apart from openjdk 13 and 14 which is in motion I've started looking at
>
>openjfx 14.
>
>But openjfx needs to be compiled with gradle 6 now - the openjfx8 
>package uses ant but that is no longer an option (there's some netbeans
>
>ant files there but they seem non functional).  guix has no
>build-system 
>gradle and looking at gradle I can't imagine there will ever be a 
>source-bootstrapped package for it - the 6.0 distribution is 215 jar 
>files, mostly external libraries, and it needs gradle to build (because
>
>of course it does).  I'm assuming that guix wouldn't accept using 
>gradle-wrapper here which is the `supported' build mechanism for the 
>openjfx project.
>
>Partly out of curiosity and partly as a potential alternative I spent 
>the weekend creating a single 1000 line gnu makefile to replace the 
> >10kloc of gradle scripts and existing makefiles.  I haven't bothered 
>with javafx.web or javafx-swt but otherwise it's complete and only 
>requires antlr 4.7 at build time.  It uses gnu make features 
>specifically and assumes a gnu environment, but it's 3-4x faster on my 
>machine (amd r9-3900x).
>
>Another alternative could be simple build script that forgoes 
>incremental and parallel compilation support for a smaller script. I
>can 
>possibly get that down to a few dozen lines of bash if i can utilise
>the 
>existing makefiles.
>
>Is either approach worth pursuing or is the whole idea a lost cause?
>
>Regards,
>  Michael

Note that the ant-build-system is able to generate its own build.xml. that's 
going to be tough, so whatever works for you is fine, as long as everything is 
free software and source-bootstrapped.

OpenJFX 14, gradle

[Michael Zucchi]

Morning,

I'm trying to work on updating some java stuff as guix currently only 
has java12 which is  a year out of date and javafx8 which is ancient.  
Apart from openjdk 13 and 14 which is in motion I've started looking at 
openjfx 14.


But openjfx needs to be compiled with gradle 6 now - the openjfx8 
package uses ant but that is no longer an option (there's some netbeans 
ant files there but they seem non functional).  guix has no build-system 
gradle and looking at gradle I can't imagine there will ever be a 
source-bootstrapped package for it - the 6.0 distribution is 215 jar 
files, mostly external libraries, and it needs gradle to build (because 
of course it does).  I'm assuming that guix wouldn't accept using 
gradle-wrapper here which is the `supported' build mechanism for the 
openjfx project.


Partly out of curiosity and partly as a potential alternative I spent 
the weekend creating a single 1000 line gnu makefile to replace the 
>10kloc of gradle scripts and existing makefiles.  I haven't bothered 
with javafx.web or javafx-swt but otherwise it's complete and only 
requires antlr 4.7 at build time.  It uses gnu make features 
specifically and assumes a gnu environment, but it's 3-4x faster on my 
machine (amd r9-3900x).


Another alternative could be simple build script that forgoes 
incremental and parallel compilation support for a smaller script. I can 
possibly get that down to a few dozen lines of bash if i can utilise the 
existing makefiles.


Is either approach worth pursuing or is the whole idea a lost cause?

Regards,
 Michael

Re: 18/36: services: hurd: Add dummy loopback.

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

>> herd: exeception caught while executing 'start' on service 'loopback':
>> Value out of range 0 to 4294967295: -1
>
> Ah see, it’s out of range.
>
> Could you run Guile, load (guix build syscalls), and try to run the code
> of the ‘start’ method that appears in
> ‘static-networking-shepherd-service’ to see which syscall is giving us
> that error?

Yes, that reproduces!

> Could it be ‘ifreq-struct-size’ that’s off on GNU/Hurd, or one of its
> friends?

Something like that: sizeof-ifconf is set to 16 (like on x86_64), but
it's size should be 8.

Not sure how that works!?

Greetings,
janneke

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: Adding a subcommand "load-profile"

[Vagrant Cascadian]

On 2020-05-03, Ludovic Courtès wrote:
> sirgazil  skribis:
>>   On Tue, 28 Apr 2020 22:42:53 + Roel Janssen  wrote 
>> 
>>  > We added a subcommand in the "guixr" script called "load-profile".  It 
>> allows a
>>  > user to do the following:
>>  > 
>> 
>>  > $ guixr package -i ... -p /my/profile
>>  > $ guixr load-profile /my/profile
>>  > [env]$
>>  >   # ... A new shell is spawned here.
>>  >   # Inside this shell only the environment variables in
>>  >   # /my/profile/etc/profile are set ...
>>  > [env]$ exit
>>  >   # Return to the normal shell state 
>>  > 
>> 
>
> [...]
>
>> Personally, I think managing Guix profiles is currently difficult, and I 
>> would like to have commands like this one to make it easier.
>
> I’m interested in your feedback then.
>
> To me, there are already several ways to do that, notably:
>
>   1. guix environment (but it’s slower)
>
>   2. sh
>  . /my/profile/etc/profile.sh
>  exit
>
>   3. sh
>  eval `guix package -p /my/profile --search-paths`
>  exit
>
> Options #2 and #3 are more verbose, and less obvious to someone not
> familiar with the shell.

The only way i understand how to trivially get a precise environment is
"guix environment --pure --ad-hoc package1, package2, ... packageN"

Don't options #2 and #3 also include everything from the default profile
and system profile?

I like the ability to maintain separate profiles and run "guix upgrade
-p my/profile" on each profile, but I haven't figured out how to get
something equivalent to "guix environment --pure --profile my/profile".

I find this useful when updating diffoscope or reprotest packages, which
tend to have a lot of suggested optional packages that aren't really
hard dependencies.

This looks "load-profile" subcommand seems to attempting to meet that
use-case, if I'm reading it correctly?


live well,
  vagrant


signature.asc
Description: PGP signature

Re: 13/36: services: Add hurd-console-service-type.

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

>> (define* (expression->derivation-in-linux-vm name exp
>>  #:key
>>  (system (%current-system)) 
>> target
>>  (linux linux-libre)
>> ...
>>
>> that is called by qemu-image.  So I have been playing with this hack
>
> Ah, so there was a #$ vs. #+ issue we discussed on IRC.  Did that
> help?

Yes; that fixed this aspect.  In fact, fixing this allows me to
introduce guix system build --target=i586-pc-gnu / guix system vm-image
--target=i586-pc-gnu much earlier, and have those working.

So I have reversed some bits, and now don't need to introduce the
hurd-service->shepherd-service intermediate anymore!

I'll reset wip-hurd-vm with those improvements.

> The VM is used just to create the image (it will no longer be necessary
> once Mathieu’s work on image creation has landed).  The fact that it
> runs Linux doesn’t matter.

Yes...

 +   (default-value (hurd-console-configuration
>>>
>>> Please add a ‘description’ too!
>>
>> For the default value?
>
> No, I meant a ‘description’ field.

Ah, I believe, I think it's there.  Someone may have overlooked
something.

Thanks!

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: 18/36: services: hurd: Add dummy loopback.

[Ludovic Courtès]

Hi,

Jan Nieuwenhuizen  skribis:

> Ah, great!  I rewrote this to use ...and it almost
> works already.  I have added
>
> (service static-networking-service-type
>  (list (static-networking (interface "lo")
>   (ip "127.0.0.1")
>   (requirement '())
>   (provision '(loopback)
>
> and the VM builds, only it doesn't start
>
> herd: exeception caught while executing 'start' on service 'loopback':
> Value out of range 0 to 4294967295: -1

Ah see, it’s out of range.

Could you run Guile, load (guix build syscalls), and try to run the code
of the ‘start’ method that appears in
‘static-networking-shepherd-service’ to see which syscall is giving us
that error?

Could it be ‘ifreq-struct-size’ that’s off on GNU/Hurd, or one of its
friends?

Ludo’.

Re: branch master updated: gnu: Add musl-cross.

[Vincent Legoll]

Hello,

On 03/05/2020 22:17, Danny Milosavljevic wrote:

The use case is to be able to build heads in Guix without modification.


I was about to ask you what was the motivation for that commit,
thanks for reading my mind !

I'm obviously interested in the subject. I'd love to explore 
bootstrapping guix with a musl libc.



Also, they are using musl instead of glibc.  I don't think we have a
musl-gcc yet and I've never done a musl gcc before.


We have musl, but are currently disabling the building/installation of 
its musl-gcc wrapper, I'm not sure you're speaking of this one though.


But maybe we can revisit enabling it, I'll put that on my todo list, if
you won't beat me to it.

--
Vincent Legoll

Re: 13/36: services: Add hurd-console-service-type.

[Ludovic Courtès]

Hi,

Jan Nieuwenhuizen  skribis:


[...]

> Now this
>
> guix system build --target=i586-pc-gnu gnu/system/examples/bare-hurd.tmpl
>
> has some cross-build problems, though.  Yesterday I finally managed to
> pin-point the problem.  It lives between
> expression->derivation-in-linux-vm
>
> (define* (expression->derivation-in-linux-vm name exp
>  #:key
>  (system (%current-system)) target
>  (linux linux-libre)
> ...
>
> that is called by qemu-image.  So I have been playing with this hack

Ah, so there was a #$ vs. #+ issue we discussed on IRC.  Did that help?

> Meanwhile there is the vm-image question: can we somehow use
> expression->derivation-in-linux-vm when running "guix system
> ... --target=i586-pc-gnu"?  Or do we want to create a
> expression->derivation-in-hurd-vm?

The VM is used just to create the image (it will no longer be necessary
once Mathieu’s work on image creation has landed).  The fact that it
runs Linux doesn’t matter.

>>> +   (default-value (hurd-console-configuration
>>
>> Please add a ‘description’ too!
>
> For the default value?

No, I meant a ‘description’ field.

Thanks!

Ludo’.

Re: 05/36: vm: Make the device node procedure a parameter.

[Ludovic Courtès]

Hi!

Jan Nieuwenhuizen  skribis:

> We may even want to move this (and "friends") into the qemu-image
> declaration itself; in a much later patch on wip-hurd-vm I have
>
>  (define* qemu-image #:key
> [...]
> - (file-system-type "ext4")
> - (file-system-options '())
> - (device-nodes 'linux)
> + (file-system-type (if (hurd-target?) "ext2" "ext4"))
> + (file-system-options
> +  (if (hurd-target?) '("-o" "hurd") '()))
> + (device-nodes (if (hurd-target?) 'hurd 'linux))
>
> Having linux-specific defaults in a generic function is kind of awkward;
> we would need to change all callers, or ...

Ah yes, we should do something like that.

Ludo’.

Re: Adding a subcommand "load-profile"

[Ludovic Courtès]

Hi,

sirgazil  skribis:

>   On Tue, 28 Apr 2020 22:42:53 + Roel Janssen  wrote 
> 

[...]

>  > We added a subcommand in the "guixr" script called "load-profile".  It 
> allows a
>  > user to do the following:
>  > 
> 
>  > $ guixr package -i ... -p /my/profile
>  > $ guixr load-profile /my/profile
>  > [env]$
>  >   # ... A new shell is spawned here.
>  >   # Inside this shell only the environment variables in
>  >   # /my/profile/etc/profile are set ...
>  > [env]$ exit
>  >   # Return to the normal shell state 
>  > 
> 

[...]

> Personally, I think managing Guix profiles is currently difficult, and I 
> would like to have commands like this one to make it easier.

I’m interested in your feedback then.

To me, there are already several ways to do that, notably:

  1. guix environment (but it’s slower)

  2. sh
 . /my/profile/etc/profile.sh
 exit

  3. sh
 eval `guix package -p /my/profile --search-paths`
 exit

Options #2 and #3 are more verbose, and less obvious to someone not
familiar with the shell.

Still, such commands are targeting shell users, which makes me wonder
how far we should go.  It’s an honest question: I’m torn between the
will to provide a simple CLI, and the need to avoid proliferation of
commands all more or less equivalent.

Thoughts?

Ludo’.

Re: Medium-term road map

[Ludovic Courtès]

Hi,

Jack Hill  skribis:

> * Continued development of guix deploy. Figuring out how to deploy
> secrets to remote machines would be great.

Right.  I think ‘guix deploy’ development will be fueled by people using
it to do things beyond the simple use cases (the build farm,
single-machine deployments) and reporting on what’s missing.

> * Accessibility for the installer. I don't know where we stand
> currently, but it would be great to know and make improvements.

Yup!

> * Sandboxing of applications. What would a Guix System with SELinux
> enforcement look like?

Related to that there were discussions on taking advantage of user
namespaces and ‘call-with-container’:

  https://lists.gnu.org/archive/html/help-guix/2018-01/msg00118.html

I’m sure we could provide a nice answer.

> * GDM and GNOME-Shell Wayland sessions.
>
> * Continued improvements to bootstrapping and GNU Hurd efforts.

+1!

Ludo’.

Re: branch master updated: gnu: Add musl-cross.

[Danny Milosavljevic]

Hi Ludo,

On Sun, 03 May 2020 21:26:23 +0200
Ludovic Courtès  wrote:

> I understand cross-base.scm is becoming messy and we would need an
> abstraction to facilitate its use.  Still, to me it sounds like a better
> option over big monolithic packages.
> 
> WDYT?

In general I'm all for using our cross toolchain mechanism.

However, this is the toolchain used by heads[1]--and they have reproducible
builds.

The use case is to be able to build heads in Guix without modification.

Their attestation of secure boot actually verifies (and asks the user and
documents the correct hashes in their README) whether the output hashes are
correct--so the toolchain doesn't need to be just similar, it needs to make
exactly the same executables.

Also, they are using musl instead of glibc.  I don't think we have a musl-gcc
yet and I've never done a musl gcc before.
Could be easy, could be hard--who knows.

That said, I'm all for it.

However, I need heads for work--and one way or another it has to actually
build the official version :)

[1] https://github.com/osresearch/heads/ , basically a Linux that goes on the
BIOS flash ROM.
[2] https://github.com/osresearch/heads/pull/710


pgptaCq4Qm0XS.pgp
Description: OpenPGP digital signature

Re: Medium-term road map

[Ludovic Courtès]

Hi,

Pierre Neidhardt  skribis:

>>   2. Performance.  
>
> At a higher level, we can work on parallelization of builds and
> downloads (all combinations).
>
> Many improvements were suggested in this thread:
>
>   https://lists.gnu.org/archive/html/guix-devel/2019-10/msg00694.html
>
> Julien sent a patch to enable parallel downloads:
>
>   https://issues.guix.info/issue/39728
>
> This could significantly improve the user experience.

Yes definitely, thanks for the reminder.  I hope Julien will follow up
on the issue above.  :-)

Ludo’.

Re: Medium-term road map

[Ludovic Courtès]

Hi!

Christopher Baines  skribis:

> Ludovic Courtès  writes:
>
>> We released 1.1.0, but what’s coming next?  What would you like to see?
>
> Thanks for starting this thread Ludo, I love this kind of thinking :)

Though I realize now that I have an email problem that introduces a
significant delay in my response time, and I apologize for it!

>>   2. Performance.  There are many things we can improve there, first and
>>  foremost: the “Computing derivation” part of ‘guix pull’, Guile’s
>>  compiler terrible time and space requirements, further optimizing
>>  core operations like ‘package-derivation’, as well as low-level
>>  stuff as described at .
>
> I remember saying that the Guix Data Service times various things, and
> that it could time the "Computing derivation" bit, but it doesn't store
> that data currently. While the performance is dependent on what else is
> going on at the same time, it might be interesting to store the data to
> see if there's a trend going forward.

Yup!

Performance monitoring in general would be nice, and could have been a
subject for GSoC/Outreachy.

> The other things on my mind are:
>
> Patch submission and review, some information in [2]. I at least want to
> do some more work on the Guix Data Service to make the comparisons more
> useful for reviewing patches, as well as seeing if I can get the Guix
> Build Coordinator to build the affected things, and report back. Then
> there are all the issues around submitting packages, like how do I know
> if someone is working on this already, or how do I know this hasn't been
> updated on core-updates, and how can actually submitting patches be made
> easier.
>
> 2: https://lists.gnu.org/archive/html/guix-devel/2020-03/msg00476.html

Would be nice.

> More sophisticated policies on accepting substitutes, this means being
> able to say things like "I trust substitutes if there signed by all
> these keys/entities". While most of the work on reproducible builds has
> been on getting things to build reproducibly, Guix could lead the way on
> doing the user facing side of this. A majority of the substitutes for
> x86_64-linux match between Bayfront and Berlin, so we already have a
> minimially viable "rebuilder" setup to actually make use of this.

+1!

Thanks,
Ludo’.

Re: Medium-term road map

[Ludovic Courtès]

Hey!

Christopher Baines  skribis:

> zimoun  writes:
>
>> 2. Search on all the packages included in Guix since the Big Bang.
>>
>> It is difficult to find the Guix commit where one package goes in and
>> the commit where it goes out. The Guix Data Service (GDS) helps a lot
>> for that! But AFAIK, it is not possible from the CLI and I do not find
>> it handy when I need it (just because I need to open a webbrowser,
>> etc.).
>>
>> IMHO, there is 3 questions:
>>  - how to build such full historical index locally? Even if it is expensive
>>  - how to fetch it from GDS? Or any other substitue?
>
> It's far from "the Big Bang", but the data.guix.gnu.org instance of the
> Guix Data Service has data going back to the start of 2019, with some
> big gaps that are still being filled in. Once that's happened, it'll be
> feasible to start looking at going further back.
>
> On your point about fetching data, the Guix Data Service can return data
> in JSON, and it's been mentioned that there could be something like the
> (guix ci) module, but to access the Guix Data Service. Once the data is
> available, it would at least be feasible to use that for a command line
> interface.

Yup, that’s the most practical approach.

We could write a program to build a database locally (I very much like
the idea of “substitutes” viewed as an optimization compared to local
computation) but that would be expensive, although it could be
incremental.

I suppose we could reuse relevant bits of the Data Service as a library.

Hmm thinking about it, by building the package-cache derivation of each
Guix revision, one already gets a lot of information, and that is
substitutable.  Food for thought!

Ludo’.

Re: core-updates call for testing

[Ludovic Courtès]

Hi,

Marius Bakke  skribis:

> I see a similar failure when tracing the associated mingetty process:
>
> 1003  sendto(4, "<83>Apr 29 14:49:20 login[1003]: PAM unable to 
> dlopen(/gnu/store/44il8dnl5qc6ryb3v0lp5374hg3h7vx5-elogind-243.4/lib/security/pam_elogind.so):
>  /gnu/store/ahqgl4h89xqj695lgqvsaf6zh2nhy
> 4pj-glibc-2.29/lib/libc.so.6: version `GLIBC_2.30' not found (required by 
> /gnu/store/44il8dnl5qc6ryb3v0lp5374hg3h7vx5-elogind-243.4/lib/security/pam_elogind.so)",
>  342, MSG_NOSIGNAL, NULL, 0) = 342
> 1003  getpid()  = 1003
> 1003  sendto(4, "<83>Apr 29 14:49:20 login[1003]: PAM adding faulty module: 
> /gnu/store/44il8dnl5qc6ryb3v0lp5374hg3h7vx5-elogind-243.4/lib/security/pam_elogind.so",
>  144, MSG_NOSIGNAL, NULL, 0) = 144
>
> Again running 'herd restart term-tty1' lets me log in successfully.
>
> I'm not sure what to do about this.  Can we get the Shepherd to
> automatically restart select services on reconfigure?

As discussed on IRC, this issue is tracked here:

  https://issues.guix.gnu.org/issue/32182

I don’t think it’s reasonable to automatically restart services that are
currently running; it should have terrible effects.  Or maybe we could
mark services that are always safe to restart as such.  But then,
‘term-tty1’ or ‘sshd’ are not always safe to restart, so it wouldn’t
help.

The bug report above proposes a relatively simple solution, which is to
not use the global /etc/pam directory to avoid the confusion.

Thanks,
Ludo’.

Re: branch master updated: gnu: Add musl-cross.

[Ludovic Courtès]

Hi Danny,

guix-comm...@gnu.org skribis:

> commit f7228e317703808a8a193f6db8a3cb6ba5380f2f
> Author: Danny Milosavljevic 
> AuthorDate: Sat May 2 14:48:29 2020 +0200
>
> gnu: Add musl-cross.
> 
> * gnu/packages/patches/musl-cross-locate.patch: New file.
> * gnu/packages/heads.scm: New file.
> * gnu/local.mk (dist_patch_DATA): Add one.
> (GNU_SYSTEM_MODULES): Add the other.

[...]

> +(define-public musl-cross
> +  (let ((revision "3")
> +(commit "a8a66490dae7f23a2cf5e256f3a596d1ccfe1a03"))
> +  (package
> +(name "musl-cross")

It’s an unconventional way to provide a cross-toolchain.  What about
expressing along the lines of what cross-base.scm does?

I understand cross-base.scm is becoming messy and we would need an
abstraction to facilitate its use.  Still, to me it sounds like a better
option over big monolithic packages.

WDYT?

Ludo’.

Re: Jami: Bug source investigation

[Jan]

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

[sirgazil]

  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

[Pierre Neidhardt]

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

[Jan]

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

[Pierre Neidhardt]

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

[Jan]

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: TLS certificates for web browsers in guix environment --container

[Pierre Neidhardt]

I've sent a patch: #41041.


signature.asc
Description: PGP signature

Re: Jami: Bug source investigation

[Pierre Neidhardt]

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