Cc @bkchr @jerith666 @worldofpeace

@GrahamcOfBorg test plasma5

Success on aarch64-linux (full log)

Attempted: tests.plasma5

machine: exit status 1
syncing
machine: running command: sync
machine: exit status 0
test script finished in 206.04s
cleaning up
killing machine (pid 631)
vde_switch: EOF on stdin, cleaning up and exiting
vde_switch: Could not remove ctl dir '/build/vde1.ctl': Directory not empty
/nix/store/3ida9v6kdif14k14y5pzphrnpaqgqmpi-vm-test-run-plasma5

Success on x86_64-linux (full log)

Attempted: tests.plasma5

machine: exit status 1
syncing
machine: running command: sync
machine: exit status 0
test script finished in 92.64s
cleaning up
killing machine (pid 600)
vde_switch: EOF on stdin, cleaning up and exiting
vde_switch: Could not remove ctl dir '/build/vde1.ctl': Directory not empty
/nix/store/qc5sx74c1v6y0vpxnvbbg1wl85wrs9b1-vm-test-run-plasma5

Should we add a test for this?

Should we add a test for this?

We definitely should - any good ideas?

This might be useful for things like home-manager/nixup !

Can we maybe encrypt the home directory and enable auto login?

Hmmm, it almost works, but it looks like the activation scripts are always "one build behind" here. (In addition to needing to at least systemctl --user restart nixos-activation.path, not sure if the systemctl --user daemon-reload was necessary too.) ^{(See update)}

Here's my test setup:

On top of 7f70ebf, applied the user-activation commit (e0e8874a8d0a55588d509641cf01c3c3d86ada65).

My configuration is as such:

{
  system.userActivationScripts.annoy = ''
    ${pkgs.libnotify}/bin/notify-send -a nixos -t 5000 -u critical "AAA"
  '';
}

Before doing time sudo nixos-rebuild test, I change the message to something (BBB, CCC, DDD...) when test finishes activating, I always see the previously expected message (so with the system having BBB, I see AAA).

I'm rebuilding without the patch, rebooting and checking what it takes so it works at the first switch adding that activation service.

Update:

.../nixos/nixpkgs ⬤  systemctl --user status nixos-activation.path
Unit nixos-activation.path could not be found.

.../nixos/nixpkgs 4 ⬤  sudo nixos-rebuild test
[...]

.../nixos/nixpkgs ⬤  systemctl --user status nixos-activation.path
● nixos-activation.path - Trigger user specific NixOS activation on /run/user/1000/.nixos-activate
   Loaded: loaded (/nix/store/bcmrl7v0vc5iraz6vvdmc95ga29lfw75-unit-nixos-activation.path/nixos-activation.>
   Active: inactive (dead)

.../nixos/nixpkgs ⬤  systemctl --user restart nixos-activation

.../nixos/nixpkgs ⬤  systemctl --user status nixos-activation
● nixos-activation.service - Run user specific NixOS activation
   Loaded: loaded (/nix/store/xd7205bfwqdchz5b6ff6rm5j8liq3vj0-unit-nixos-activation.service/nixos-activati>
   Active: inactive (dead) since Thu 2018-10-04 21:48:27 EDT; 1s ago
  Process: 10692 ExecStart=/nix/store/wws8a9lzkqhbvny1p1inpvx2jybkg007-unit-script-nixos-activation-start (>
 Main PID: 10692 (code=exited, status=0/SUCCESS)

Oct 04 21:48:26 ralphwiggum systemd[2414]: Starting Run user specific NixOS activation...
Oct 04 21:48:27 ralphwiggum systemd[2414]: Started Run user specific NixOS activation.

I don't know what it takes to make it "Active: active (waiting)", as even after a restart of the .path it still was inactive, after restarting both the service and the path it started working :/.

Though, once it is active, it will solidly activate with the previous generation's script!

After a reboot, the service doesn't need any kind of massaging, but still seems to lag behind one generation.

Yeah, probably because systemctl --user daemon-reload hasn't run yet. A slight variation of this, is instead of touching the file, that we simply activate nixos-activation.service in switch-to-configuration.pl after running daemon-reload.

I just pushed some untested commits (I'll try them out now) that uses switch-to-configuration.pl instead.

Quick update, before more in-depth testing it doesn't lag behind one generation anymore!

Now testing a fresh boot without the change, if the the first switch works.

And confirming that the changes (1353ba2 and 8118d6e) on 18.09 does activate right on first activation.

Seems fine as far as I can tell (and can now annoy myself with notifications on rebuilds!)

That feature is 👍 imho.

So this is good to go despite the lack of tests? We really should have some (although I think the encryptfs test isn't relevant in this case) but it's of course your call if it's more important to ship 18.09 assuming this is the last pending blocker.

I would prefer having tests for the feature; though I don't know how the testing infrastructure can be used to make this work since it seems to need a user session to be active (though I'm sure there's already good material in there).

Do you have any idea on how to proceed with a test and the time to implement it at short notice? (DO NOT feel pressured!) Otherwise I feel like I have tested it right, and with the latest changes seems solid. With another pair of eyes looking at it and testing it I would be okay to merge without tests, hoping to later see tests pop into existence. (Which I would gladly adopt into backporting.)

Do you have any idea on how to proceed with a test and the time to implement it at short notice? (DO NOT feel pressured!)

One way to do it would be to have the plasma test see if the .cache/ksycoca5_bla_bla_bla file is created but I will need to look at this later. Will a promise to implement that soonish be enough?

It's also working fine for me in the last iteration. I'll open a separate PR for 18.09.

Tests popping into existence: #113241