=== oSoMoN_ is now known as oSoMoN === oSoMoN__ is now known as oSoMoN [13:23] pitti: is --system in systemd the equivalent of upstart's --global ? [13:24] elopio: systemctl --system is the same as initctl --system, i. e. talk to pid1, not the session init [13:24] (not sure what --global is) [13:27] pitti: I used global to set some environment variables. [13:27] Like initctl set-env --global ENV=value [13:27] will set the variable in a differen environment than [13:27] initctl set-env ENV1=value === vrruiz is now known as rvr [13:49] elopio: ah, so systemctl set-environment does that [13:49] pitti: yes, I can do systemctl set-enviroment --user ENV=value, which seems to work just as when I didn't pass the --global. [13:50] but systemctl set-environment or systemct set-environment --system gives me permissions errors. [13:50] elopio: hm, not sure that --user will be useful -- we don't really use the session systemd init [13:50] everything is being started from the session upstart [13:50] so you only want this for system-wide environment variables (i. e. pid 1) [13:51] right, obviously that needs to happen as root :0 [14:13] pitti: this is for getting our tests ready for when systemd will be the session manager. [14:13] for now we will keep setting the upstart env variables. [14:14] elopio: ah, understood; so you'll poke them into both [14:14] so it seems we need to go and check that everything we used to do with initctl --global can work now with systemctl --user. [14:14] elopio: then set-environment --user sounds like the right thing [14:15] pitti: thanks. [14:15] The ETA for ubuntu-app-launch with systemd is ~july, so we have time. I will probably be back with more questions. [14:49] pitti: can you give me a hand when you have some time? I'm trying adt-run on snappy, but get two errors: [14:49] the required argument `Release` was not provided [14:49] Timed out on waiting for ssh connection [14:49] http://paste.ubuntu.com/11246001/ [14:52] elopio: argh, so they changed the ubuntu-device-flash syntax again :/ [14:52] elopio: TBH I don't know what the syntax du jour is; you can create an image manually, and run --- ssh -s snappy -- -i /path/to/your/image [14:55] pitti: I tried that and got only the ssh error. [14:56] elopio: hm, if you boot the image in kvm, do you actually get ssh running? [14:56] maybe that's disabled by default now, and needs to be enabled somehow? [14:57] sorry, /me is stuck in security work, only half a brain cell left [14:57] pitti: let me retry. Maybe I had my vm running, and the second one failed to start. [15:01] hi elfy, you available for a quick chat ? === oSoMoN__ is now known as oSoMoN [15:49] ki7mt: off and on - just got in from work [15:50] elfy, Can I send you a quick pm to ask you a couple things? [15:50] yep === chihchun is now known as chihchun_afk === oSoMoN_ is now known as oSoMoN === chihchun_afk is now known as chihchun [17:12] hmm I got a fail with May 19th dialy for lubuntu alternate then tried to see if the problem also was with server but it failed at a different spot so not sure if I need to open a new bug or not [17:13] bug 1456838 is the one I reported yesterday for lubuntu alternate [17:13] bug 1456838 in debian-installer (Ubuntu) "debian installer fails to chroot on lubuntu amd 64 in kvm" [Undecided,New] https://launchpad.net/bugs/1456838 [17:33] ianorlyn: if you're not sure, then file a new bug. you can reference the potential other bug in there if you want, though that sort of behavior is apparently not recommended by launchpad. i disagree, personally. [17:36] ianorlyn: if bdmurray yells at you about it, tell him it's all my fault ;) === chihchun is now known as chihchun_afk [17:42] although I think the best way of getting logs from another machine on network when debian-installer fails is to wget -r the ip address on the lan. [21:22] rhuddie: https://code.launchpad.net/~josharenson/unity8/settings_wizard_tests/+merge/259537 [21:23] rhuddie: could you take care of it? [21:23] elopio, yes, I'll take a look. thanks. [21:23] thanks to you.