[00:30] Hello. I have a snap that installs, but doesn't expose the command. I can see the file for the command in places like stage/usr/bin, but once the snap is installed the command does not exist. Snap here: http://paste.ubuntu.com/23105293/ [00:30] Any guidance appreciated! === chihchun_afk is now known as chihchun [05:48] PR snapd#1772 opened: cmd: enable SNAP_REEXEC only if it is set to SNAP_REEXEC=1 [05:51] Bug #1617890 opened: 2.12 crashes with latest ubuntu-core snap due to re-exec [05:57] PR snapd#1773 opened: firstboot: disable firstboot on classic for now [06:27] PR snapd#1774 opened: tests: add test for current snapd with ubuntu-core/edge interactions [06:37] hey hey [06:38] I have python as plugin in both parts, when building the projects, some files are copying to the same locatiton, resulting conflicts like http://paste.ubuntu.com/23106210/. how can I avoid this issue? [06:43] good morning :) [07:05] liuxg, maybe file a bug report on snapcraft? [07:05] dholbach, yeah, I think so. I will do that, thanks [07:05] thanks [07:13] dholbach, I have reported it at https://bugs.launchpad.net/snapcraft/+bug/1617907 [07:14] Bug #1617907: Two python parts in the same snapcraft.yaml result in not installing the python correctly [07:14] great [07:16] pitti: hi, quick question - we have the netplan config in snapd now, its great. its also static, so I would like to ship it just in the ubuntu-core-config (which is only installed on ubuntu-core devices) package as a static /etc/netplan/00-default.yaml package [07:17] pitti: eh, static file of course. any reason not to do that? [08:03] mvo: what does it contain? [08:03] good morning [08:03] mvo: I'm not a big fan of constant config files in /etc, I must say [08:03] mvo: if we start doing that, I'd rather add support for /lib/netplan/*.yaml [08:16] PR snapd#1769 closed: snap: add export-key --account= option === JanC is now known as Guest45177 === JanC_ is now known as JanC [08:33] mvo: hey, did you have a chance to raise the topic of vendorizing go build deps for snapd? === carlo is now known as Guest67116 [08:50] pitti: support for /lib/netplan/*.yaml sounds great, if its not too much work, I can also look at it if you are too busy [08:50] mvo: already at it [08:50] tvoss: not explicitely, we talked about it in the team recently and the concensus was that we want to do it [08:51] pitti: cool, thanks! for context: https://github.com/snapcore/snapd/pull/1765/files#diff-7c06ac92ab14c8f3ece674037573ceddR14 is the config we want to ship by default [08:51] PR snapd#1765: many: move network initialization to a separate service [08:51] mvo:/url 2 [08:51] mvo: oh - DON'T ever ship that in a package [08:52] mvo: this means that you cannot ever reconfigure any device, as 00-* is always the first match [08:52] mvo: ack, will join your standup today then (if I can make it) [08:53] pitti: ok, so this needs to be 99-ubuntu-core-defaults if we move it to a package? [08:53] mvo: mwhudson discussed that with slangasek and me recently; AFAIR the idea was to only create that file in /run/ if there is no actual config (i. e. before running console-conf), and as soon as there is some /etc/netplan/* then not generate it any more [08:53] pitti: and it would be in a package that is only installed on core systems, is that ok? [08:53] pitti: oh, I see /run - hm [08:54] mvo: actually, the name of the *.yaml is not that relevant [08:54] there is no natural order in the yaml definitions [08:55] other than that later definitions override previous ones [08:55] pitti: hmhm, ok, let me ponder a bit if we only want this in /run under these conditions that changes the picture a little bit [08:55] mvo: I suggest talking to mwhudson, he is also working on this and it seems that there is a lot of overlap and not enough coordination [08:56] pitti: yeah, I started talking to him and he directed me to you :) thanks, I think I know all I need to know for now [09:04] mvo: anyway, suport for /lib/netplan/ committed, it would also be useful for things like lxc (bridge configs) [09:08] pitti: \o/ [09:13] * ogra_ grins about https://github.com/snapcore/snapd/pull/1573 [09:13] PR snapd#1573: asserts/tool,cmd/snap: introduce hidden "snap sign" [09:14] we have a secret handshake ! [09:16] cjwatson, is there any known way for me to find out a revision number for a snap that was auto-uploaded by LP ? [09:17] (would be nice to be able to map a revision to a build number and log) [09:29] i see i get a "manage this package in the store" link after successful upload on the UI page, but i dont see anything in the LP api that would map to this [10:04] ogra_: do you have a 3.4 based kernel around on any device? [10:04] ogra_: manual wifi bringup with wpasupplicant and networkd works fine; now it's a SMOP :) [10:04] ogra_: would you mind doing ls -ld /proc/$$/ns/mnt for me? [10:04] zyga, snappy device ? no, i dont [10:04] ogra_: (and SMOWTC) [10:05] ogra_: no, any device [10:05] ogra_: (phone is good) [10:05] * ogra_ hugs pitti and looks up acronyms :) [10:05] ogra_: I just made it up -- SMO writing test cases :) [10:05] :) [10:06] ogra_: oh, "simple matter of programming" (but that's rather common) [10:06] hah [10:06] it's all doable, it's all software ;) [10:07] zyga, i only have 3.10 :/ [10:08] Hi, I was asked by elopio to move some bits out of my waf integration test belonging to PR 716 to be an external part [10:08] ogra_: that's actually good, is that ubuntu phone? [10:08] yes [10:08] I thought I updated https://wiki.ubuntu.com/snapcraft/parts the right way, but something is missing [10:08] ooh ... [10:08] ogra_: thanks, I was worried that older kernels are still around [10:08] is there any update cycle or anything I have to wait until I can discover a part there? [10:08] * ogra_ just found one machine in his network running 2.6.37 [10:09] i guess its time to upgrade that one [10:09] zyga, they are ... u just dont have any active phone with them anymore [10:09] s/u/i/ [10:09] zyga, only the last two devices had 3.10 [10:10] nexus and the bq phones are all 3.4 [10:10] no matter if the part is already right yet (not sure on that part) I'd have expected that "snapcraft update && snapcraft search wafdemo" gets me something, but it doesn't [10:17] PR snapd#1775 opened: Add thumbnailer interface === hikiko is now known as hikiko|ln [10:59] cjwatson, there is an update on bug 1608432 for you [10:59] mwhudson: around? [10:59] Bug #1608432: snaps with type: os should allow publishing of .manifest files [11:08] PR snapd#1773 closed: firstboot: disable firstboot on classic for now [11:20] morning [11:22] Son_Goku: hey [11:23] hello === hikiko|ln is now known as hikiko [11:33] zyga, so, did you get anywhere on the path relocation? [11:43] Son_Goku: yes, it basically works now, I need to work on selinux support in systemd to let the service start now [11:55] mvo, btw, not sure you have seen https://github.com/snapcore/classic-snap/pull/4 [11:55] PR classic-snap#4: merge recent changes that are in the store, improve bin/classic [11:55] (sorry for the ping in the wrong channel before) [12:05] zyga, you might want to look at the abrt service policy as an example [12:05] https://github.com/fedora-selinux/selinux-policy/tree/rawhide-contrib [12:22] ogra_: checking [12:23] Bug #1618004 opened: Need a classic-bin interface to see classic binaries [12:23] ogra_: thanks, nice one, merge - I assume you alrady pushed it? [12:24] mvo, not yet, doing so now (i didnt know how you wanted to handle the missing bits) [12:25] ogra_: I think its was a forgoten push on my side, sorry for that [12:25] NP [12:42] PR snapd#1683 closed: osutil: fix create-user on classic [12:42] PR snapcraft#763 opened: Include /sbin and usr/sbin in wrappers [12:51] elopio: I see bug 1616157 has been verified, should I tag it 'verification-done'? And mvo is it ready for release into xenial? [12:51] Bug #1616157: [SRU] 2.13 [12:56] PR snapd#1776 opened: image: snap assertions into image [12:57] PR snapd#1723 closed: image: prepare-image: import snap assertions as well [12:57] PR snapd#1777 opened: osutil: tweak the createUserTests a bit and extract common code === dpm is now known as dpm-afk [13:03] arges: I have a look, in a meeting right now [13:03] zyga, hey :) thanks for the review [13:04] zyga, looks like I forgot a commit :) [13:05] hmm, no sergio today ? [13:05] zyga, please ignore the entire PR until I add that commit :) [13:06] zyga, and voila [13:06] zyga, I'm sorry I wasted your time [13:08] zyga, about the snap/implicit.go, is there some documentation of what it means? [13:11] Kaleo: I'll check it after the meeting [13:11] thanks [13:11] Kaleo: look at snap/implicit.go and look what's there, there's no docs but I have a blog post about it on zygoon.pl (the lastest one) [13:11] Kaleo: please check it out [13:12] cheers [13:14] lool, tianon: hey I read lool's status on the docker PR progress. I thought there were still some open questions that needed to be addressed before another review and I got the impression one of you would be working on the kernel modules backend. [13:15] jdstrand: I actually got the impression you would be coming back to the review after a while [13:15] jdstrand: :-) [13:16] well, I planned to come back to the review, but thought people were working on the kernel modules backend [13:16] jdstrand: I'm not sure who if anyone has time to work on the kernel module backend [13:16] if it makes sense for me to do another round of reviews, I can [13:16] hrmm [13:16] I dont know if I can ask tianon to work on this, if he can't I imagined I'd end up doing it [13:17] but I was hoping someone from the core team would come to it first [13:17] lool: this might be a question to have with JamieBennett [13:17] err [13:17] a conversation to have with him [13:17] Yes [13:17] jdstrand: it would be helpful to know how much other things are needed for this to get in [13:18] how many / how much work [13:20] I was assigned some high priority (snappy) work a week and half ago so I've been trying to get through all that while (I thought) the other issues with docker were being worked on. if you're saying you're blocked on me, I can try to get through that review today [13:21] jdstrand: I think we're blocked on your next review + this kernel module feature which isn't docker specific but that docker seems to need first [13:21] jdstrand: I dont know of other work on the snap / interface that was requested in the pull request and wasn't done [13:22] lool: fwiw, that feature is needed by firewall-control for the GA release for a customer requirement. it's also needed by ppp interface [13:22] I guess I'll take a look at that. I'll try to get to that today [13:22] jdstrand: cool; I'm currently debugging other issues with the docker snap on classic (works on core but not on classic with weird errosr) [13:22] jdstrand: before 3.8 /proc/$PID/ns/mnt did not exist [13:24] zyga: sounds like that is a patch to add to the list. I wonder how intrusive it is. I suspect very-- we've said in the past 3.4 kernels can't be used to run lxd/docker [13:25] * jdstrand is recalling from memory. ogasawara would probably have the definitive answer [13:25] I thought 3.10 was needed for systemd anyway? [13:27] jdstrand: we have a few options for that [13:27] jdstrand: one easy one is that this feature is not supported on 3.4 [13:27] jdstrand: a more complex one could usee a zygote process [13:27] jdstrand: and a backport for this patch could be a third approach [13:27] lool: I'm not sure [13:28] lool: if so, then this discussion is moot, I guess this is about defining a baseline kernel for snappy [13:28] Is there a recommended way to get $HOME back to the correct value? [13:28] Tried with getent, but don't have permissions. [13:28] tedg: I don't believe there is [13:28] I believe the oldest we provide for apparmor patches is 3.10 [13:29] Uhg, it makes the open/close dialog in Inkscape mostly unusable :-( [13:29] we probably had older patchsets, but we haven't updated them [13:29] zyga: I really don't like the zygote approach in general. it depends on how it is implemented [13:29] tedg: snappy could easily set a variable like SNAPPY_OLD_HOME [13:29] im trying to get my systemd bridge service working and not able to get an ip assigned to it, https://paste.ubuntu.com/23107318/ [13:29] actually systemd requires >= 3.4 [13:29] jdstrand: I think we agree on this [13:29] lool: apparmor isn't the probelm-- we have patches for 3.4 kernel for touch [13:29] I'm not sure how up to date they are as of this second, but that is certainly possible. [13:30] jdstrand: in the snappy kernel templates, we only offer 3.10 and onwards [13:30] arges: yeah 2.13 looks good, the issues that elopio mentioned with gnome-software is a bug in 2.12, we are working on a fix [13:30] lool: ogasawara maintins a list somewhere [13:30] lool, afaik, newest systemd requires kernel >= 3.14, iirc [13:30] zyga: Sure, but then I'd need a specific version of ubuntu-core, which I can't depend on. [13:30] lool: that may be because other things have made them say that 3.4 is not possible, so we said "well, then we don't have to produce apparmor backports" [13:30] jdstrand: https://docs.google.com/document/d/1LOqrSty2yTsUtQ4nFehaisZc4XmKKsK_E_tz-O1hU-M/edit [13:31] sure, it is a cause and effect thing [13:31] the effect of not supporting snappy on 3.4 is that it causes the security team to not provide backports to 3.4 :) [13:32] jdstrand: yup; I'm just trying to be realistic; I believe the oldest we consider maintainable is 3.10, but of course everything is possible :-) [13:32] tedg, just use /home/$USER ? [13:32] sure. I'm just saying that *apparmor* is not why it isn't maintainable [13:33] jdstrand: sorry it's just the first thing we're missing when we're applying the ubuntu patches [13:33] (over vanilla / bsp kernels) [13:33] tedg: you can, there's a mechanism for that [13:33] ogra_: Yeah, can try that as a work around. Good idea. [13:33] didn't [13:33] didn't mean to pick on these patches specifically [13:33] it's all our ubuntu sauce [13:33] tedg: assume (or somethng like that) you can put this into your snapcraft.yaml [13:33] jdstrand: this was an earlier effort of mine to capture the reqs https://docs.google.com/document/d/1W9TJDTWevnxARYaE3w7fahXeCgjv_9xJ2RTZ6nN0Va4/edit [13:33] tedg: in general it feels like a bug to fix [13:34] which was after internal consultation [13:34] zyga, but rarher in the desktop launcher than in snapcraft [13:34] err [13:34] snapd [13:34] after all it is the launcher wrapper script that forces $HOME [13:35] zyga: Hmm, I see that in the snapcraft schema, but I don't see what the string needs to look like. "ubuntu-core>x.y.z" ? === dpm-afk is now known as dpm [13:43] tedg: it's a list of strings [13:43] tedg: each string is a feature flag you can request from snapd [13:43] tedg: e.g. old-home-env [13:43] tedg: snapd knows which flags it supports [13:44] ogra_: no, that's actually in snapd itself [13:44] zyga: Oh, so it's not requesting a specific version as much as a set of features. [13:44] ogra_: the launcher doesn't change home AFAIR [13:44] tedg: exactly [13:44] ogra_: the wrapper script is made by snapd [13:44] i thought it has HOME="$SNAP_USER_DATA" [13:44] ogra_: and since 2.14 those are gone [13:44] ogra_: so this is all managed internally in snapd [13:44] ogra_: (no more wrappers! [13:45] (talking about the desktop wrapper here) [13:45] ogra_: that's all snapd [13:45] ogra_: snapd can now set environment in the started app processes [13:47] Wait, so how is snapd launching the process? Spawning from its own then? [13:48] zyga, yeah, i just checked, it doesnt touch HOME ... only creates a ton for XDG dirs in SNAP_USER_DATA [13:48] Or is the CLI starting the application. [13:48] s/for/of/ [13:48] tedg: it's complex, the app name, say "foo", is a symlink to snap-run [13:48] tedg: snap-run does some stuff, run snap-confine, which does some more and runs snap-exec which does some more and exec's the command associated with the snap [13:49] zyga: So for starting apps I should be calling that symlink still? Or calling snap-run? [13:49] tedg: nothing changes for the user [13:49] tedg: this is all an internal change [13:49] tedg: and snap-run is not on PATH AFAIK [13:49] zyga: Well, I'm kinda a special user here :-) [13:50] tedg: why? [13:50] tedg: I mean, this should not be visible to anyone in practice [13:50] zyga: Becuase we're setting up the exec in Upstart for desktop apps [13:50] tedg: it's just an optimization that gives us some more control [13:50] tedg: that should just run the command as it in the desktop file [13:51] zyga: Ideally, but the desktop files aren't that useful. [13:51] (the ones generated by snapd) [13:51] tedg: perhaps what you want to do should be managed by snapd itself [13:51] tedg: I'm not sure what this is exactly, feel free to ask for more information if that helps you [13:52] zyga: I am :-) [13:52] * ogra_ thought we are drooping Üpstart this cycle from desktop [13:52] when i install a snap it runs both command and stop-command via oneshot [13:52] https://paste.ubuntu.com/23107384/ [13:52] zyga: Seems like the symlink should work fine for now. [13:52] i just need it to run the start command and then the stop command on uninstall [13:52] ogra_: Trying for Unity7, not for Unity8. [13:52] not at once [13:52] ah [13:52] anyone, what's the glib-way to rm -rf a directory? [13:52] (this is for unit test code) [13:54] stokachu, i would imaggine running stop-command on install is a bug ... but nontheless your script should check if what it wants to stop is actually running [13:54] ogra_, huh? there is nothing running [13:54] the start command runs some ip/iptables commands [13:54] so it should exit gracefully [13:56] hmm, actuall running the stop command makes indeed sense on upgrades [13:56] so iits probably not a bug at all [13:56] it runs the start command then stop-command right after [13:56] running the stop-command before the command makes sense [13:57] stokachu: note, this is all systemd stuff [13:57] stokachu: nothing is done by snapd here [13:57] stokachu: whatever you are experiencing is systemd related [13:57] stokachu: we just start/stop units [13:57] stokachu: (we do stop and start the units on upgrades) [13:57] you call stop-command after the start command? [13:57] zyga, well, you can define stop-command for a daemon [13:58] snapd should make sure what it generates can be run in the desired order [13:58] elopio: are the snapcraft integration tests usually passing? I get an error on snapcraft-parser [13:58] stop-command should be only run on shutdown or uninstall of the package ... or before an upgrade wants to start the daemon newly [13:59] which it's not doing now [13:59] right [14:00] ogra_: snapd just generates a systemd unit file, all the running is done by systemd [14:00] zyga, well, but if snapd allows us to define a stop-command for a daemon it should not "just run" [14:00] only for stopping the daemon [14:01] so imho something is generated wrongly [14:01] probably a Chipaca topic [14:02] ogra_: check the systemd unit, does it look good or bad? [14:02] no idea ... its stokachu's unit :) [14:02] where is that located [14:03] but it is clear that tthe two units run in the wrong oorder on package install [14:06] ogra_, zyga https://paste.ubuntu.com/23107454/ [14:07] so my oneshot daemon runs command, then stop-command directly after [14:07] elopio: well they are passing on travis; not sure why it fails here [14:08] stokachu: looking now [14:08] stokachu: can you pastebin the snap.conjure-up.bridge.service file [14:09] stokachu: it should be easy to find in /etc [14:09] zyga, https://paste.ubuntu.com/23107463/ [14:18] Given I can do both, should I create my daemon simple or forking? [14:18] kyrofa: travis completed on the /sbin branch [14:18] Any advantages of one over the other? [14:18] (successfully) [14:19] zyga, stokachu, hmm, i wonder if it should actually be oneshot if it has a stop command defined [14:19] kyrofa: I couldn't open the autopkgtests links [14:19] zyga, hi, i was following your blog post on writing an interface. i'd like to write one for libvirt, so that snaps can control it on a classic host [14:19] PR snapd#1772 closed: cmd: enable SNAP_REEXEC only if it is set to SNAP_REEXEC=1 [14:19] ogra_, should i just put the tear down of iptables etc in the same start script [14:19] and handle it logically [14:20] zyga, i got the socket part working, but the snap i'm working on wants to see stuff in /var/lib/libvirt, such as dnsmasq [14:20] you could indeed do that ... [14:20] zyga, how would i expose that through the interface? (or is this even a good idea?) [14:20] ogra_, what about snap remove? [14:21] that would call stop [14:21] so maybe just a bridge script that'll accept an argument [14:21] zyga, i tried adding /var/lib/libvirt/** to the aa profile, but the plugged-in snap doesn't seem to see it. is there some mounting that would need to happen? [14:24] a new ubuntu-core stable got just released, it is based on 2.13, please do let me know if you notice any issues [14:24] good morning [14:24] arges: there was some talk about command not found hanlding? do you have some details for me? [14:26] good morning sergiusens [14:26] cmars: if you explore the environment you will see that /var/lib/libvirt just doesn't exist in the core snap [14:26] cmars: as a easy workaround please look at snap-confine and at quirks.c therein (look for lxd quirk) [14:27] cmars: note that this is only for a devmode snap as no interface allows any snap to use /var/lib/lxd [14:27] cmars: I would recommend you to create an interface that bind mounts /var/lib/lxd from the host into a snap-specifc directory [14:28] cmars: I'm not familar with libvirt, does it need just a socket or the whole directory tree [14:29] zyga, the socket, but also parts of the tree, such as /var/lib/libvirt/dnsmasq, if you want to read the IP addresses of VMs for example [14:29] cmars: I would recommend you to also report a bug tagged with snapd-interface and ask jdstrand for advice [14:29] cmars: I see [14:29] zyga, ok, will do [14:30] cmars: we can use the mount backend to bind mount /var/lib/lxd to a directory in the snap (relative to $SNAP_DATA) [14:30] i thought interfaces was a last resort and that we should be packaging every requirement in the same snap [14:30] cmars: then you can patch or config libvirt inside the snap to assume that libvirt is in that directory [14:30] stokachu: interfaces allow to shape the sandbox in which apps execute [14:31] stokachu: if you want to have a snap that talks to something in the classic world or talks to another snap you can use an interface for this [14:31] snaps have no notion of dependencies though [14:31] stokachu: it feels perfectly fine to have a snap with libvirt or libvirt installed on classic and an interface that allows another snap to talk to libvirt (wherever it is) [14:33] how would someone know that libvirt is a requirement for cmars snap? [14:35] stokachu: the snap would declare a plug of type 'libvirt' [14:35] stokachu: we have no syntax for this but plugs will have a way to say "I have to be connected before this snap can be used" [14:36] zyga: is somebody working on adding the content interface details to the existing docs? [14:36] lool: hello. What error are you getting locally? [14:36] stokachu: then however that libvirt is provided (could be from the core snap, could be from another snap) [14:36] i imagine it's a similar situation for snaps that need to plug into mir & x11 [14:36] mhall119: not that I'm aware of, I'll do this after snap-confine features for 1.0.41 are implemented [14:36] cmars: yes [14:36] cmars, read the docs for now? [14:37] cpaelzer: maybe josepht can help you with the wiki entry. I get no parsing errors, but I also don't get the new part. === kirkland` is now known as kirkland [14:39] elopio: ok, thanks for the update [14:39] elopio: that is why I opened the bug on LP to give people some time to really look at it [14:39] elopio: I couldn't reproduce it after rerunning; here's the one I get locally right now: [14:39] elopio: http://paste.ubuntu.com/23107571/ [14:42] zyga, thanks for the advice, snap-confine sources are clearing things up for me :) [14:42] zyga (cc cmars): fyi, a libvirt interface is going to be super-privileged, like docker and lxd [14:42] jdstrand: I agree, note that it seems that it is just the plug-side of libvirt for now [14:42] session:/// wouldn't need to be. but no one uses session:/// [14:44] elopio: python3 -m unittest -b integration_tests.test_parser is passing for me now, sorry; it failed a couple of times even when rerunning manually [14:44] perhaps wiki issue or something [14:44] I think snappy-playpen CI is having infrastructure issues ("No CMAKE_C_COMPILER could be found") on more than one PRs. Does anyone know why it's failing? Is there anyway to re-kick it (without updating the branch)? [14:46] elopio: ah I know what's going on [14:46] elopio: install: error writing '/tmp/tmpe3p0e0r9/simple-rust/parts/simple-rust/rust/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc [14:46] _llvm-39b92f95.so': No space left on device [14:46] elopio: /tmp is in memory, the vm has 2G and that's apparently not enough [14:47] cpaelzer: it looks like it's because your part is named 'waf-project' in your snapcraft.yaml and 'wafdemo' in the wiki. The wiki entry needs to use the part name, not the project name. [14:48] mvo: not sure what you mean exactly [14:48] lool: oh, that makes sense. The tests use tmp a lot, the real build doesn't. [14:48] elopio: yeah [14:48] PR snapcraft#764 opened: add support for snap-build grade parameter in snapcraft.yaml [14:49] elopio: this also explains why it transients (running other things took memory / disk space) [14:49] *was [14:49] arges: sorry, if you don't know about command-not-found that is fine, it was in a google doc and I was referenced [14:49] arges: I will find out, I thought the context was kernel stuff [14:49] arges: in any case 2.13 should be good to go [14:50] mvo: i see it now, it was to ensure /snap/bin is in $PATH, that should probably be filed as a bug if it isn't already [14:50] cpaelzer: fyi, the wiki is processed once an hour. [14:50] Error: Node Sass does not yet support your current environment: Linux Unsupported architecture (arm) with Node.js 4.x [14:50] damn it [14:50]