[01:03] sergiusens: take a poke https://code.launchpad.net/~chipaca/snappy/delayed-service-start/+merge/266166 when you have a bit plz [01:03] rsalveti: ^ that's my take on the fix/workaround for bug 1466672 [01:03] bug 1466672 in Snappy trunk "webdm failed to start / Failed to listen 224.0.0.251:5353" [Undecided,In progress] https://launchpad.net/bugs/1466672 [03:22] omg, system-image import takes forever, impossible to get the lock [03:58] Chipaca: add an [Install] section to it with WantedBy= [03:58] Chipaca: or just ship the symlink in the deb, as you wish [04:51] Can anyone help me get git installed in ubuntu-15.04-snappy-armhf-rpi2? [04:51] I was able to install wget and I’ve been pulling my hair out trying to get dependencies built with dpkg for git [04:53] aaand nobody gaf >_> === chihchun_afk is now known as chihchun === guest42345 is now known as oniix [07:03] good morning [07:10] good morning === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [09:11] Good morning all; happy Rain Day! 😃 [09:51] zyga: finally got round to adding tests and pushing https://code.launchpad.net/~chipaca/snappy/dynamicExclusion/+merge/266199 [09:51] oh, drat, forgot the prereqs [09:51] 1 sec [09:52] Chipaca: hi [09:52] Chipaca: looking [09:52] zyga: https://code.launchpad.net/~chipaca/snappy/dynamicExclusion/+merge/266200 [09:52] ohhh [09:52] nice [09:52] one tip/request [09:52] shoot [09:52] please get into the habit of writing manual pages [09:53] it makes software far far better to discover [09:53] we suck at that, don't we [09:53] I'll start using .snapignore right away [09:53] systemd puts us to shame [09:53] hehe [09:53] yes [09:53] zyga: it's not on trunk yet! [09:53] systemd is really good about this [09:53] Chipaca: we started doing this for plainbox [09:53] Chipaca: and it's really easy actually [09:54] Chipaca: just requires discipline and merge request reviewers to spot [09:54] Chipaca: feel free to copy the sphinx integration bits [09:54] http://bazaar.launchpad.net/~checkbox-dev/checkbox/trunk/files/head:/plainbox/docs/manpages/ [09:55] Chipaca: that and the conf.py file for sphinx is all we need [09:55] Chipaca: it's a world of difference for our users [09:58] Chipaca: one more suggestiong [09:58] *on [09:58] Chipaca: perhaps remove the built-in list and create the .snapingore file with that list if missing [09:58] Chipaca: it's better than having two, one secred that nobody knows of, and one in the file [09:59] hmm [09:59] i see your point [10:00] can you make that comment on the merge? [10:00] i think it needs sergio or mvo to comment [10:00] sure [10:01] zyga: also: http://paste.ubuntu.com/11958678/ [10:01] btw, we have some code that automates that :) [10:02] missing quite a bit of work still, but that might be a good place to start [10:02] so we get the manual page for plainbox commands (all dozens of them) auto-synchronized with sphinx [10:02] zyga: that's produced by "snappy man" [10:02] ah [10:02] ... which is not a thing on trunk yet either [10:02] Chipaca: random man page from plainbox [10:02] http://bazaar.launchpad.net/~checkbox-dev/checkbox/trunk/view/head:/plainbox/docs/manpages/plainbox-dev-list.rst [10:02] the ..argparse part is also a plainbox feature though I'm moving that to python-guacamole for anyone to use [10:04] (that example was poor) http://plainbox.readthedocs.org/en/latest/manpages/plainbox-run.html and http://bazaar.launchpad.net/~checkbox-dev/checkbox/trunk/view/head:/plainbox/docs/manpages/plainbox-run.rst [10:06] zyga: and this is the code that adds "snappy man": https://code.launchpad.net/~chipaca/snappy/snappy-man/+merge/266203 [10:06] looking [10:06] ah, but that's go, I thought this part is written in python [10:07] Chipaca: so it's a feature of the argument parser that go provides [10:07] well, of the one we use :) [10:07] right [10:07] it also produces bash completion things [10:07] which we aren't using (why not? :) ) [10:07] nice, it's somewhat similar, we have a sphinx plugin that looks at the parser object [10:08] ogra_: why don't we ship bash completion in core? [10:09] Chipaca: bash is not in the core ;-) [10:09] * zyga ducks [10:10] if it weren't, i'd be happy [10:10] but as it is, we might as well use it :) [10:10] hehe [10:10] yeah, I was kidding [10:10] me, i'd strip core down so much it would make peoples eyes water [10:10] but it's not (yet) my fight [10:10] Chipaca: the 1995 boot floppy! [10:11] exactly! [10:11] Chipaca, we should just drop bash [10:11] dhcp in the kernel baby! [10:11] iirc the completion db isnt actually small ... and it refers to aps [10:11] *apt [10:11] also the kdrive x server, man that thing was sweet [10:11] ! [10:11] i loved that [10:15] ogra_: wrt bash completion, we ship random things in /etc/bash_completion.d, which we should probably look at (wrt apt, etc) and nuke, but we don't ship /etc/bash_completion so even if we ship snappy's completion thing, it won't be picked up [10:17] also shipped: 400k in /usr/share/bash-completion/completions [10:17] hm i thought it was more in the megabytes [10:18] ogra_: it can be :) [10:18] but perhaps i shouldnt justdge by desktop standards ;) [10:18] 2.4M on my notebook [10:18] ogra_: we should start measure snappy core image sizes in terms of 720 floppies [10:18] yeah, thats more like i remember [10:18] ogra_: this will let us see how big we are ;-) [10:18] +1 [10:18] we are to big ... for sure [10:18] right! swapping libc to musl in 3... [10:18] lol [10:19] lib modules as squashfs image ! [10:19] err [10:19] /lib/modules [10:19] initrd is whole root system! [10:20] go works fine linking with musl, fwiw :) [10:20] http://dominik.honnef.co/posts/2015/06/statically_compiled_go_programs__always__even_with_cgo__using_musl/ [10:20] how abouot klibc ? [10:20] (that is actually well maintained in ubuntu) [10:20] http://www.etalabs.net/compare_libcs.html [10:21] ah, does not include klibc [10:21] ogra_: wasn't klibc kernel-only or something? [10:21] * Chipaca reads [10:21] no,. its a cut down glibc iirc [10:21] i don't think systemd will work with that [10:22] in fact i think the only one there are patches for systemd to work with is uclibc [10:22] good ! [10:22] upstart will ;) [10:22] ogra_: so you're going to implement socket activation for upstart? [10:22] we just need to change everything back [10:22] \o/ [10:23] we kind of have socket activation in use on the phone ;) (via hacked upstart jobs) [10:23] remember when you searched for two words in google, and the first result actually included both words you looked for? [10:23] ogra_: replace socket activation with dip switches [10:23] ;) [10:23] google "klibc systemd", first result has no systemd in it :( [10:24] yeah, dip switzches definitely dont get the attention they deserve anymore ... [10:24] nor second, nor third, nor ... [10:24] jumpers killed the dip switch ! [10:26] there's a rather dark joke hiding in that statement, but i'm unable to wiggle it out === JamesTai1 is now known as JamesTait [10:37] Chipaca, http://lists.freedesktop.org/archives/systemd-commits/2012-June/002047.html is what i hit when searching for klibc and systemd ... [10:37] but that seems to only refer to udev [10:38] (and is years old) [10:39] hi guys, i see someone (seems lool) is working on porting snappy onto edison but i'm not sure where it is. could anyone let me know if there is a workable image already? [10:39] * ogra_ doesnt think there is, but i could be wrong [10:40] lool would know, though [10:40] yeah [10:55] how bad would it be if, on installing a snap, all installed snap services restarted? [11:15] Chipaca, pretty bad i'd say === rickspencer3_ is now known as rickspencer3 === dpm_ is now known as dpm [11:36] unfortunately the documentation is unclear on whether that will happen, meaning i need to implement this before knowing [11:54] well, rolling is expected to break ;) === bigcat_ is now known as bigcat [12:08] Chipaca, uuuh ... implementing a "phone home" service to check if the network is up ? [12:10] Chipaca, how about instead checking if a default route exists ? [12:15] morning === chihchun is now known as chihchun_afk [12:26] ogra_: it's the standard "do you have internets" thing that's used in at least two other places [12:27] hmm [12:27] ogra_: but, um, looking for a default route would work, also :) [12:27] ogra_: comment on the mp? [12:27] just did :) [12:27] sergiusens: mo'in! [12:27] ogra_: ta [12:27] Chipaca: I hink he has [12:27] think* [12:36] sergiusens: any comment on zyga's comment in the dynamicExclude branch? [12:37] on the one hand, putting a file in the user's thing is Not What We Do [12:37] on the other hand i see his point about it being magic and obscure and stuff [12:38] @activereviews [12:38] sergiusens: No such command! [12:38] @activereview [12:38] sergiusens: No such command! [12:38] @help [12:38] "list" To see the available commands ; "help cmd" for specific command help [12:38] @list [12:38] The available commands are: ['bug', 'critical', 'help', 'last', 'list', 'more', 'ping', 'reviewlist', 'seen'] [12:38] @reviewlist [12:38] https://code.launchpad.net/~fgimenez/snappy/config-for-remote-testbeds/+merge/266214 | No reviews (less than a day old) [12:38] https://code.launchpad.net/~chipaca/snappy/snappy-man/+merge/266203 | Needs Information: 1 (less than a day old) [12:38] https://code.launchpad.net/~chipaca/snappy/dynamicExclusion/+merge/266200 | Needs Fixing: 1 (less than a day old) [12:38] https://code.launchpad.net/~fgimenez/snappy/generalize-build-tests-across-versions/+merge/266191 | No reviews (less than a day old) [12:39] https://code.launchpad.net/~chipaca/snappy/delayed-service-start/+merge/266166 | Needs Information: 2 (less than a day old) [12:39] Chipaca: we should have an alias, it's called activereviews in lp :-P [12:39] agreed [12:39] Chipaca: and help should just list :) [12:39] sergiusens: https://code.launchpad.net/~verterok/lalita [12:39] thanks [13:12] Morning folks! [13:21] ooh, look at that, it *doesn't* restart everything \o/ [13:29] hello, good morning. === elopio_ is now known as elopio [13:32] mterry: I did a shortcut to get this merged: https://code.launchpad.net/~elopio/snapcraft/fix1476452-python_log/+merge/265354 [13:32] next, if you give me the specs for the logging that you want I can configure the loggers. [13:33] elopio, OK. [13:33] elopio, so was the point of that MP to use loggers or to get rid of common.log? Because you could have kept common.log and automatically had it add the bold to the message just like before and just done sed s/print/logger.info/ [13:34] mterry: the problem with keeping the old common.log is that you can't handle the messages differently depending on their origin and type. [13:34] so I still like this one as a fist step towards using fancier logging. [13:36] ogra_: parlez vous ip(8)? [13:36] elopio, that's what arguments to a method are for :) but ok [13:36] it handles differently info, error and warning, which we didn't have before. And opens the option to do bold depending on the origin. It's just that current bold rules are not consistent. [13:36] elopio, or even common.info :) [13:37] elopio, not consistent? We use them for step declarations and error messages [13:38] rsalveti: where is the "user button" on the bbb? I feel silly... [13:38] mterry: well, you can disapprove if you don't like it or don't find it useful. I won't feel bad :) [13:38] mterry: isn't this a step: print("Installing required packages on the host system: " + ", ".join(newPackages)) ? [13:39] elopio, eh, that's an action inside a step. we don't bold commands that plugins run [13:39] jdstrand: near the sd card [13:39] there is only one button [13:39] Chipaca, "ip -4 route list 0/0" [13:39] ogra_: and if they're ipv6-only? [13:39] :) [13:39] Chipaca, thnen you omit -4 [13:39] jdstrand: https://learn.adafruit.com/system/assets/assets/000/008/680/medium800/beaglebone_BeagleBoneBlack.jpeg [13:39] ogra_: nice about 0/0 [13:39] mterry: what about snapcraft.common.log(stage + " " + self.part_names[0] + hint) ? Isn't that a command a plugin runs? [13:39] elopio, I'm fine with the idea of loggers in general. And I don't hugely care how it's implemented. It just seems like you went out of your way to dismantle central message handling and then bemoan the lack of features that central message handling gives you :) [13:40] elopio, no that's the 'step declaration' [13:40] ogra_: sad that it doesn't error if there's no route to it :) [13:40] elopio, or stage declaration more accurately [13:40] Chipaca, yeah, it even returns 0 [13:41] you need to check for stdout [13:41] mhmm [13:41] worse things have come to pass ;) [13:41] mterry: it's more like I got rid of all the things I haven't understood yet, so I could make a transparent change first. [13:42] with these answers you are giving me, I can configure the logging to get rid of the prints. I dislike the central messages because they replace the origin with the common module. [13:42] so maybe if you want, you can wait for me to propose the next couple of branches. [13:42] elopio, makes sense, I'm on board with your changes [13:43] elopio, I'll look at your new branch this morning [13:44] rsalveti: boy, not sure I'm coordinated enough to do this (I have mine in the case and turn it on/off by pulling the plug). here goes nothing... [13:45] jdstrand: you could as well just erase the internal u-boot (in emmc) [13:45] and reboot, that will force it to load the u-boot from the sdcard [13:46] rsalveti: it wasn't clear it was possible to do that from my laptop [13:46] no, you need do call it on a running system, so under bbb [13:46] ie, I thought I might have to actually get into snappy, then erase it [13:46] right [13:46] hence the being coordinated part :) [13:46] so yeah, you'd need to press the user button at least once [13:46] anyhoo, I'll figure it out [13:47] keep it pressed and then add power to it [13:47] reset is not enough [13:47] any news on flashing the emmc? [13:47] not yet [13:48] elopio, you left fatal in place, which is fine. But there's a separate bug about snapcraft having too many exit points, and that maybe those fatal calls should be an exception that bubbles up to main() and gets logged there with a sys.exit call there. Does that ruin your origin info too, or would the exception keeping track of the origin be usable when logging it? (you don't need to do the exception thing in your branch, just thinking of future ch [13:48] anges) [13:49] rsalveti: so, I'm running a 4.2 kernel now (on vivid). I noticed that when I put the sd card in it showed up as /dev/mmcblk0 instead of /dev/sdX [13:49] rsalveti: so I just specified /dev/mmcblk0 instead to the dd command. is this something you've seen or think it might be a problem? [13:50] rsalveti: I'm talking about the dd to the sd card after creating an image with udf [13:50] mterry: the traces have origin information, but anyway we don't want them to be visible to the user. [13:50] jdstrand, mmc devices never show up as sdX unless you use a USB reader [13:50] jdstrand: yeah, depends on your host [13:50] jdstrand: fwiw, my trusty laptop has always had mmcblk nodes [13:50] if it's native, it shows up as mmcblk0 [13:50] ok good to know [13:50] depends on how it's connected [13:50] mterry: so the approach I think we should have is replace all those fatal calls by raise. But keep the logging on the module that generates the message. [13:50] if under a usb bus, then it shows as /dev/sdX [13:50] not sure why it would change though [13:50] right [13:50] before I flashed with a reader in another host. this time I have a slot for the sd card [13:51] elopio, so log the message then raise an error that doesn't include a message (or includes a duplicate, unused message)? [13:51] gotcha. I was thinking that was the case but wasn't sure [13:51] ogra_: a sw upgrade bringing in a hw upgrade :-P [13:51] hah [13:51] * sergiusens wants his 8 gig of ram sw upgraded to 16! [13:51] just add zram :P [13:52] jdstrand: ah, that explains it [13:54] ogra_: better like this? [13:54] ogra_: (talking about https://code.launchpad.net/~chipaca/snappy/delayed-service-start/+merge/266166 ) [13:55] Chipaca, beauty ! [13:55] * Chipaca knows he is [13:56] :D [13:56] one improvement could be to specify /sbin/ip instead of just ip [13:56] not sure if i should care :) [13:56] mterry: we can instantiate the exception first, and then use https://docs.python.org/3/library/logging.html#logging.Logger.exception [13:57] we can choose if we want to log immediately after the exception was instantiated, or in a handler in one of the callers. [13:59] ogra_: can i say your 'check for default route' insight solved all the ugly/iffy problems in the branch? hence why i say it was brilliant [13:59] heh, thanks :) [14:00] sergiusens: webdm is where the bug is pointed at, but everybody wanting to do multicast will have the same problem [14:00] sergiusens: which can be fixed per service by a single setsockopt call before you listen [14:00] sergiusens: but golang doesn't let you setsockopt [14:00] sergiusens: especially not before listening for multicast udp [14:00] sergiusens: youd'd have to rewrite a buuunch of net/ [14:01] sergiusens: IP_FREEBIND is the sockopt fwiw [14:01] Chipaca: yeah, I read the bug report [14:02] Chipaca: btw; do we need a separate go bin, or on a different subject, does this need to be a go exec? [14:06] sergiusens: webdm -> mdns's openSocket (private) -> net.ListenMulticastUDP[6] -> net.listenIPv{4,6}MulticastUDP (private) -> net.joinIPv{4,6}Group (private) [14:07] * Chipaca suddenly feels lagged to the universe === greyback__ is now known as greyback [14:08] sergiusens: i'm not sure which "this" you mean wrt go exec [14:08] sergiusens: you mean, does wait4network have to be go? no [14:08] sergiusens: does it need to be separate? well, given it's potentially long lived, i'd rather it weren't all of snappy :) [14:09] sergiusens: i could write it in C [14:09] sergiusens: it could be sh, also [14:11] Chipaca: long lived? doh, didn't see any exit; it's fine as is [14:11] sergiusens: I could also stuff it as sh into ExecStart [14:11] ExecStart=while ! ip route show 0/0 | grep -q .; do sleep 5; done [14:12] dunno what sh systemd uses; if it has builtin [, i could use [ instead of grep for moar cheap [14:12] e.g. while [ -z "$(ip route show 0/0)" ]; do sleep 5; done [14:13] but that's asking a lot of a random sh [14:14] * Chipaca does perf testing of that [14:17] mterry: in this case: [14:17] 133 + logger.info('Wrote the following as snapcraft.yaml.') [14:17] 134 print() [14:17] 135 print(yaml) [14:17] what you want is the first line to be bold, and the rest to be normal? Is that a rule we can apply to all the messages? [14:17] rsalveti: sorry for being a pain. are there any known issues with 15.04/edge r132 and bbb? I flashed the sd card and booted holding the button and for sure the emmc didn't load, but neither did snappy [14:18] I have udf 0.27-0ubuntu1 [14:18] jdstrand: hm, did it even boot into u-boot? [14:19] U-Boot SPL 2015.07-dirty (Jul 17 2015 - 11:40:49) [14:19] that is the boot loader that we are now using [14:19] rsalveti: I don't know-- I only ever ssh in. I think I need a cable I don't have [14:19] :\ [14:20] oh, ok, you don't have serial [14:20] how did you generate the image? [14:20] sudo ubuntu-device-flash core --channel=edge --oem=beagleblack --enable-ssh --output=15.04-edge.bbb 15.04 [14:20] sudo dd if=15.04-edge.bbb.r132 of=/dev/mmcblk0 bs=32M && sync [14:21] elopio, that case is a little different than the others, a different flow (it's not iterating over parts or whatnot). So I felt like the 'wrote' message was Snapcraft's top-level "here is what I'm doing" and the yaml was the content (plus it would be too intense if all the yaml was bold) [14:21] (I had a mv 15.04-edge.bbb 15.04-edge.bbb.r132 in between) [14:21] elopio, I'm happy to change some of these bold/not-bold decisions. I just didn't want to block your python logger branch on hashing them out [14:21] jdstrand: let me flash it from scratch and see [14:21] * mterry is testing your branch right now [14:22] mterry: ok, so what we need is two arguments, a message and a content. Or something like that. [14:22] elopio, except usually the content comes much later (like when running a plugin's step, which has subcommands and all that) [14:23] I'm excited to use the snappy-- I think I was affected by the fatwrite stuff cause every once in a while it would upgrade and never come back [14:23] mterry: no, that's alright. We need to figure out a way to make it easier for all the cases. Which is not easy :) [14:24] there are many ways to do this, with filters, handlers, format and namespaces. [14:24] I'm just trying to figure out which would be clearer. [14:29] jdstrand: hm, worked fine in here, got ssh running and was able to get in just fine [14:29] took a minute to boot, because of cloud-init, but it was fine [14:29] jdstrand: did you put power while pressing the button? [14:31] jdstrand: can you also give http://releases.ubuntu.com/15.04/ubuntu-15.04-snappy-armhf+bbb.img.xz a try? [14:31] rsalveti: I'll try the whole thing again [14:31] this is latest stable [14:31] has webdm and ssh by default [14:31] I'll try with edge, if that doesn't work, I'll try with stable [14:32] thanks [14:32] cool [14:32] it sucks not having serial easily [14:32] and, yes, I held the button down while applying power [14:32] jdstrand: can you see blinking leds? [14:32] it was difficult, but I mustered the dexterity :) [14:33] and the ethernet led as well [14:33] just to know if the system booted or not [14:33] yeah, all that is illuminated [14:33] but it never asked for an ip address [14:33] right, so it should be up [14:34] actually, there are no blinking leds [14:34] there is a solid blue, and then the green for the ethernet [14:34] the green is blinking sporadically [14:34] anyway, let me try it from scratch [14:34] right, the ethernet led is already enabled by u-boot [14:35] just the blue leds are the one that actually shows if the kernel booted or not [14:35] if it doesn't work, guess you can mount at your host and look for the syslog [14:35] rsalveti, btw, do we have any docs how we generate that releases.u.c image ? [14:35] see if booted in any way [14:38] https://trello.com/c/PUpWXouz/89-stable-release-checkpoints [14:38] (i.e. any ready made scripts or anything) [14:38] ogra_: ^ [14:38] ah, k [14:38] :) [14:39] elopio, you have a conflict on https://code.launchpad.net/~elopio/snapcraft/fix1477638-format_strings-2/+merge/265717 [14:43] ogra_: sergiusens: http://pastebin.ubuntu.com/11959990/ [14:43] ogra_: sergiusens: C wins every time :) but sh and go are tied [14:44] and they're tied if you're generous towards go ;) [14:44] heh [14:44] go is the only one that made the cpu think [14:44] yeah [14:45] C manages to do it without context major pagefaults \o/ [14:45] Chipaca: do shell I guess [14:45] Chipaca: try python for the kicks :-P [14:45] lol [14:45] i love python, but this is not a dick contest it'd win, ever [14:46] especially not on arm :) [14:46] micropython, however .... :-p [14:46] hahaha [14:50] rsalveti: ok, I have a solid blue led then a couple of rapidly blinking blue leds over the usb port [14:50] they are now solid [14:50] hm, kernel booted then [14:50] yeah [14:50] and now it is pingable [14:50] ok, good! [14:51] dholbach: how to change https://developer.ubuntu.com/en/snappy/start/ ? [14:51] I get "You do not have permission to edit this plugin" [14:51] * jdstrand guesses something went wrong with the initial dd [14:51] it's working now though [14:52] rsalveti, you logged in using /openid/login and all the boxes were ticked? [14:52] dholbach: yeah [14:52] rsalveti, which part of the page are you trying to edit? [14:53] dholbach: Getting started with a Beaglebone Black === chihchun_afk is now known as chihchun [14:53] to add the instruction about the sdcard booting process [14:54] let me see if I can change it [14:55] strange, it works for me [14:55] hm, let me try to login again [14:55] mhall119, do you have any idea why rsalveti might get "You do not have permission to edit this plugin" when trying to edit the "Getting started with a Beaglebone Black" section on https://developer.ubuntu.com/en/snappy/start/? [14:56] still, even after doing a clean login on another browser [14:56] and I was in the developerportal-editors group [14:57] dholbach: because rsalveti is a suspicious character with questionable motives? [14:57] that might be true [14:57] :P [14:57] or because he didn't tell SSO to pass along his team membership? [14:58] I did [14:58] or his session cookie has expired [14:59] mhall119: dholbach: so I can change the top part of that page [14:59] but not the bbb piece [14:59] maybe that is a different page [14:59] not a different page, but a different content plugin within the page [14:59] if I double click at "Getting started with a Beaglebone Black", I get not enough permission [15:00] I can change the rpi2 part [15:00] hmmmm, I can save it (I made no changes) [15:00] but not the bbb [15:00] the vagrant part is also fine [15:02] weird... [15:03] rsalveti: have a call right now,but I'll keep investigating [15:08] mhall119: np === carlo_ is now known as Guest97320 [15:33] pitti: a first pass at moving our services to a generator shows that generators are run before the local fs is mounted [15:33] Chipaca: correct [15:34] they run as pretty much the first thing, as they could (and often do) create early-boot units [15:34] pitti: and yet they purport to be for converting one config to systemd services [15:34] like fstab :) [15:34] pitti: which is hard to do without a filesystem [15:34] Chipaca: why? the generated units are in /run/ [15:34] tmpfs ftw [15:34] pitti: how do you read the config you're trying to convert? [15:34] a generator should *only* create units, it shoudln't actually run logic [15:35] Chipaca: well, you have a r/o root, you can read it? [15:35] oh, unless you need mounts from fstab [15:35]