<mkg20001>
also by the progress in the cjs issue it seems like cjs with mozjs 78 shipped should be very close now
<mkg20001>
```
<mkg20001>
```
<mkg20001>
error: Package ‘font-bh-lucidatypewriter-100dpi-1.0.3’ in /home/maciej/Projekte/nixpkgsv/pkgs/servers/x11/xorg/default.nix:199 has an unfree license (‘unfree’), refusing to evaluate.
<mkg20001>
it doesn't have any license set at all so seems like a mistake that it's unfree
<mkg20001>
<jtojnar "it should be public domain accor"> generate-tarballs-from-list.pl creates the default.nix without licenses by defaullt for packages
<worldofpeace>
Yeah, the eta for 3.38 is when we decide that what's committed is stable. If we had some (more) automated (actually good) testing it could probably be done a lot faster
<mkg20001>
what I wonder, in general, is if there isn't a way to write a simple abstraction for nixOS testing that would allow writing scripts like "wait until window opens" and "click that button then"
<mkg20001>
with some patches to gtk, etc that could be quite possible - I think there's automation frameworks that do more or less the same already
<mkg20001>
for browsers ofc there's already a multitude of tools where making tests is point-and-click but I suspect it shouldn't be too hard with some patchwork to make the same for gtk. a special environment variable that has a path to a socket where the UI thread will send/recieve events. for test creation that could be used to capture stuff to write a script and then put that script into a nixOS test
<worldofpeace>
mkg20001: yeah, what we need to do so this is possible is to add useful functions into the python driver
<worldofpeace>
I think there's one for wait_for_x, but it's really bad.
<worldofpeace>
an interface for dbus and maybe some gnome specific stuff in there would probably make it pretty good
<mkg20001>
<worldofpeace "mkg20001: yeah, what we need to "> prob that
<mkg20001>
the idea here is that the socket would be useful for writing the tests aswell, since there could be an app that launches some other app with that env variable and records user interactions. then it would be enough to copy and paste that
<worldofpeace>
here's an example test case in fedora https://pagure.io/fedora-qa/os-autoinst-distri-fedora/blob/master/f/tests/desktop_login.pm. stuff like assert_screen, assert_and_click, login_user, switch_user... hmm, I'm not so sure about that. I can't remember the testing library that some of the gnome installed tests use, but I think basically using that might be clearer that that. But I haven't really looked into it at all.
<worldofpeace>
Another issue is the testing lib uses systemctl instead of like using https://github.com/facebookincubator/pystemd (or something else, can't really remember). so wait_for_unit etc are not very accurate because there's only so much information you can poll from the cli
<mkg20001>
assert_and_click looks cool
<mkg20001>
in fedoras tests
<worldofpeace>
I can't remember if those are their functions are just in openQA
<worldofpeace>
I know right. openqa is powerful and probably the main reason fedora has improved so much over the years. our testing framework could really be better
<worldofpeace>
lol, that one screen literally says it all
<jtojnar>
dogtail is the UI testing framework based on ATSPI
<worldofpeace>
Right right. I'm not sure if we could use that somehow Jan Tojnar ?
<worldofpeace>
Also, the GO / NO-GO meeting for 20.09 is on Friday 3:00PM America/New_York. Not sure if you can make it (and I can basically represent GNOME at the same time). Would you agree that GNOME for 20.09 is a NO-GO Jan Tojnar ?
<worldofpeace>
we also have the image being distributed for 20.09 that probably needs some manual verification